Announcement

Collapse
No announcement yet.

Wine 1.5.28 Improves PostScript Driver, Mac Driver

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wine 1.5.28 Improves PostScript Driver, Mac Driver

    Phoronix: Wine 1.5.28 Improves PostScript Driver, Mac Driver

    It's time for another bi-weekly development release of Wine...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Why have PostScript support at all, is it better in some cases than PDF? I read yesterday cups 1.6 makes PDF the default format.

    Comment


    • #3
      Originally posted by mark45 View Post
      Why have PostScript support at all, is it better in some cases than PDF? I read yesterday cups 1.6 makes PDF the default format.
      There aren't many printers supporting RAW PDF streams as imput, but there are A LOT of printers supporting RAW PostScript, specially laser and high end printers. For those printers, PostScript is better and faster, with less processing for the PC/Server.

      The change to PDF is mostly because Apple OWNS CUPS and OSX primary 2D text and graphics rendering library uses PDF internally for composition, so it's easier for them to support only PDF than PDF and PostScript, allowing easier postprocessing and higher color depth. And for those printers not supporting PostScript (needing data translation anyway) a simpler printing pipeline.

      But this isn't the only important change. They are removing everything not usefull for them.

      The currently used, supported and tried network printer discovery method? Gone and replaced by their preferred method, even if it causes interoperability problems: http://cyberelk.net/tim/2012/02/06/c...changes-ahead/

      Printing filters they don't use? Out with them: http://www.cups.org/str.php?L3930

      There has even been talk about posibly forking cups in a not so distant future due to this kind of changes centered in what Apple wants/needs.

      Comment


      • #4
        Originally posted by Tundra View Post
        The currently used, supported and tried network printer discovery method? Gone and replaced by their preferred method, even if it causes interoperability problems: http://cyberelk.net/tim/2012/02/06/c...changes-ahead/
        Well...yeah o.O The "Currently used, supported, and tried" method is cludgey, power inefficient, and non-standard. Do you know how it works? It works by occasionally flooding the network with data that 99% of computers wont understand because the only one who understands it is an associated cups server / client.

        It wakes the computer (CPU and network adapter) from idle everytime it does it.

        And its not standardized. Bring on mDNS (whether it be Bonjour-- Mac, or Avahi-- linux, Windows uses Bonjour until MS stops trying to shove WINS down everyones throat)

        Printing filters they don't use? Out with them: http://www.cups.org/str.php?L3930
        Filters are trivial to add back in. Arch even has a nice package called 'cups-filters' that adds in any filter that isnt shipped by default.

        There has even been talk about posibly forking cups in a not so distant future due to this kind of changes centered in what Apple wants/needs.
        It wouldnt surprise me, Apple knows what it wants. As long as they implement the standard as well (eg they dont fork Zeroconf / mDNS) as their implementation / protocol, I dont really care.
        All opinions are my own not those of my employer if you know who they are.

        Comment


        • #5
          Originally posted by Ericg View Post
          Well...yeah o.O The "Currently used, supported, and tried" method is cludgey, power inefficient, and non-standard. Do you know how it works? It works by occasionally flooding the network with data that 99% of computers wont understand because the only one who understands it is an associated cups server / client.

          It wakes the computer (CPU and network adapter) from idle everytime it does it.

          And its not standardized. Bring on mDNS (whether it be Bonjour-- Mac, or Avahi-- linux, Windows uses Bonjour until MS stops trying to shove WINS down everyones throat)
          It's true, the current method is a mess and needs to be changed, but it shouldn't be removed until the new one is working as the default for a time, because if you find a problem you need a fallback. I'm not against using mDNS as default, but against removing the current default as son as a new one is chosen.


          Originally posted by Ericg View Post
          Filters are trivial to add back in. Arch even has a nice package called 'cups-filters' that adds in any filter that isnt shipped by default.
          Easy to fix as this is, it's another signal of the current trend to remove everything they don't use/want/need, and to hell everybody else.

          Comment


          • #6
            Originally posted by Tundra View Post
            It's true, the current method is a mess and needs to be changed, but it shouldn't be removed until the new one is working as the default for a time, because if you find a problem you need a fallback. I'm not against using mDNS as default, but against removing the current default as son as a new one is chosen.
            I agree with you there about not removing it 'as soon as the new one has been chosen' but mDNS isn't a really 'new' technology. I remember configuring it on Arch at least 2 years ago, maybe even 3. So far there hasn't been any major problems with it, and Apple has been using 'zeroconf' / 'bonjour' since before mDNS was standarized. The only thing 'new' about mDNS is related to cups-- its a new development that cups directly supports mDNS but the technology itself isnt new.


            Easy to fix as this is, it's another signal of the current trend to remove everything they don't use/want/need, and to hell everybody else.
            True, but see my post about "As long as they dont break the standard, who cares?" Thats the point of the standards. we can have different implementations (eg: they fork cups) but the standards ensure interoperability when necessary.
            All opinions are my own not those of my employer if you know who they are.

            Comment


            • #7
              Originally posted by Ericg View Post
              I agree with you there about not removing it 'as soon as the new one has been chosen' but mDNS isn't a really 'new' technology. I remember configuring it on Arch at least 2 years ago, maybe even 3. So far there hasn't been any major problems with it, and Apple has been using 'zeroconf' / 'bonjour' since before mDNS was standarized. The only thing 'new' about mDNS is related to cups-- its a new development that cups directly supports mDNS but the technology itself isnt new.
              Even if it were as tested as the "old way" (and it's not because many people uses default settings), it's a BIG change that involves security policies change. To support it on Linux you need avahi or some other equivalent daemon, and most Linux distributions block it in their firewalls by default. Many don't even install/launch the daemon unless manually tweaked.

              And where this is most useful, big companies and offices, it may require a security policy review/change that can take a long time, forcing them to keep an old CUPS or to rush an untested change. What's more, without support for the old standard, you can't implement a mixed environment for a progressive change. They would need additional servers (to do both things at the same time) or a full printing infrastructure replacement in one go. So directly removing the previous default is just WRONG.

              As I've said before, I'm think this will be a good thing sometime in the future, and have no doubt about that, but what makes me angry is that it's been done the WRONG way, and for the WRONG reasons.

              As for not caring about a fork... I do care, because that means a lot of work will be duplicated and that's a shame.

              Comment


              • #8
                Originally posted by Tundra View Post
                Even if it were as tested as the "old way" (and it's not because many people uses default settings), it's a BIG change that involves security policies change. To support it on Linux you need avahi or some other equivalent daemon, and most Linux distributions block it in their firewalls by default. Many don't even install/launch the daemon unless manually tweaked.

                And where this is most useful, big companies and offices, it may require a security policy review/change that can take a long time, forcing them to keep an old CUPS or to rush an untested change. What's more, without support for the old standard, you can't implement a mixed environment for a progressive change. They would need additional servers (to do both things at the same time) or a full printing infrastructure replacement in one go. So directly removing the previous default is just WRONG.
                Fedora 19 is enabling Avahi with an open port in the firewall by default. If RH rebases directly off F18 for RHEL 7, that would 7.1 (F19) would be the earliest to have Avahi by default in corporations, but it may get pulled into 7.0 instead if the devs feel like it.

                Whats my point? Corporations are gonna have a lot of warning that this is coming, it isnt gonna get shoved down their throats randomly, they have time to test and figure out if they are gonna have issues and do a gradual change and rollout. It isn't even really a security issue because you can edit what Avahi announces on the network and what it doesn't. So if you dont want your entire network knowing that your file server web server and ssh server are all broadcasting off the same IP...you just disable those broadcasts. Its not an all or nothing thing.
                All opinions are my own not those of my employer if you know who they are.

                Comment

                Working...
                X