Menu
▾
▴
gimp-print-devel
|
From: Gary A. <Gar...@Ci...> - 2018-02-07 16:19:16
|
Dear Gutenprint team, Are you able to develop commercial grade Mac and Linux drivers for businesses? I head the photo business at CITIZEN Europe. Gutenprint already supports my printers with basic drivers (Citizen branded and OEM). Looking forward to your reply. Regards, Gary Andrews EMEA Business Manager, Photo Printers Mobile: +44 (0) 7740 959067 www.citizen.photo<http://www.citizen.photo/> [cid:image001.png@01D3A02C.FC8CAFC0] <https://www.facebook.com/CitizenPhotoPrint/> [cid:image002.png@01D3A02C.FC8CAFC0] <https://www.linkedin.com/company-beta/11115734/> [cid:image003.png@01D3A02C.FC8CAFC0] <https://twitter.com/CitizenPhotoPr> [cid:image004.jpg@01D3A02C.FC8CAFC0] |
|
From: Solomon P. <pi...@sh...> - 2018-02-11 18:10:16
Attachments:
signature.asc
|
On Wed, Feb 07, 2018 at 04:02:00PM +0000, Gary Andrews wrote: > Are you able to develop commercial grade Mac and Linux drivers for > businesses? I head the photo business at CITIZEN Europe. Gutenprint > already supports my printers with basic drivers (Citizen branded and > OEM). Looking forward to your reply. Gary, Gutenprint has solid support for nearly all current (and legacy) Citizen dye-sublimation models, and those drivers (along with the rest of Gutenprint) are provided free of charge under the terms of the GNU GPL to anyone who wishes to use them (including for commercial purposes) as long as the license terms are respected. Can you provide some specifics to what you mean by "commercial grade"? Gutenprint is already widely used for commercial purposes (such as photo kiosks) and it is not clear how Gutenprint may be lacking in this regard. Are you perhaps interested in using Gutenprint as the basis of an application SDK, or looking to replace your current OSX drivers? Cheers, - Solomon -- Solomon Peachy pizza at shaftnet dot org Coconut Creek, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |
|
From: Solomon P. <pi...@sh...> - 2018-02-15 23:02:57
Attachments:
signature.asc
|
On Sun, Feb 11, 2018 at 01:09:50PM -0500, Solomon Peachy wrote: > Can you provide some specifics to what you mean by "commercial grade"? > Gutenprint is already widely used for commercial purposes (such as photo > kiosks) and it is not clear how Gutenprint may be lacking in this > regard. Are you perhaps interested in using Gutenprint as the basis of > an application SDK, or looking to replace your current OSX drivers? Gary and I have done a few rounds of off-list discussion, but he's going to be out of the office for a few days so it seemed like time to bring it back into the open to see what everyone else thinks. Essentially, Citizen is considering using Gutenprint as the basis of their future OSX drivers. Thanks to customer demand, they are also interested in providing official Linux support too. From our discussions, it appears as if the core printer support is already essentially complete and fairly well tested, so I expect there will only be a little bit of work to be done on the hardware enablement front (essentially fixing any bugs uncovered by a proper QA cycle with real hardware, and possibly tuning the output or creating an ICC profile to match what their existing drivers generate) So while that is all good and beneficial for all involved, I believe they're really looking for a one-stop vendor relationship that can, for appropriate consideration, produce an installable driver package for them, and provide ongoing maintainence and feature releases as bugfixes, hardware, and new OS releases warrant. They would handle end-user support. That's a reasonable wish, but what's unclear is the level of polish they're after -- eg are they okay with a generic Gutenprint driver package not unlike we already supply today, or would they want some sort of unique-to-citizen release? Would they want unique-to-OSX features, like a spiffier control panel or status monitor? And (rather importantly) are the terms of the GPL acceptible? On the Linux front, exising Linux distro channels are probably okay if they are recent enough, but for older/enterprise/LTS-type distros it would be highly advantagous if we could provide more up-to-date OS packages. That would tie nicely into the CI system we've been talking about for a while. Personally, I don't think Gutenprint as a project is in a position to provide much more than we already do, mostly due to our very limited resources and expertise with respect to OSX. Of our current-ish contributors, only Steve has the ability to even generate OSX builds, and we're entirely reliant upon him to test those builds. I'm also not terribly fond of Apple, but if improving things for OSX gains us additional resources to make Gutenprint better for Linux and other Free Software platforms.. it's worth considering. Thoughts? - Solomon -- Solomon Peachy pizza at shaftnet dot org Coconut Creek, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |
|
From: Alex G. <mr....@gm...> - 2018-02-17 06:34:45
|
On 02/15/2018 11:59 AM, Solomon Peachy wrote: > On Sun, Feb 11, 2018 at 01:09:50PM -0500, Solomon Peachy wrote: >> Can you provide some specifics to what you mean by "commercial grade"? >> Gutenprint is already widely used for commercial purposes (such as photo >> kiosks) and it is not clear how Gutenprint may be lacking in this >> regard. Are you perhaps interested in using Gutenprint as the basis of >> an application SDK, or looking to replace your current OSX drivers? > > Gary and I have done a few rounds of off-list discussion, but he's going > to be out of the office for a few days so it seemed like time to bring > it back into the open to see what everyone else thinks. > > Essentially, Citizen is considering using Gutenprint as the basis of > their future OSX drivers. Thanks to customer demand, they are also > interested in providing official Linux support too. > > From our discussions, it appears as if the core printer support is > already essentially complete and fairly well tested, so I expect there > will only be a little bit of work to be done on the hardware enablement > front (essentially fixing any bugs uncovered by a proper QA cycle with > real hardware, and possibly tuning the output or creating an ICC profile > to match what their existing drivers generate) > > So while that is all good and beneficial for all involved, I believe > they're really looking for a one-stop vendor relationship that can, for > appropriate consideration, produce an installable driver package for > them, and provide ongoing maintainence and feature releases as bugfixes, > hardware, and new OS releases warrant. They would handle end-user > support. > > That's a reasonable wish, but what's unclear is the level of polish > they're after -- eg are they okay with a generic Gutenprint driver > package not unlike we already supply today, or would they want some sort > of unique-to-citizen release? Would they want unique-to-OSX features, > like a spiffier control panel or status monitor? And (rather > importantly) are the terms of the GPL acceptible? > > On the Linux front, exising Linux distro channels are probably okay if > they are recent enough, but for older/enterprise/LTS-type distros it > would be highly advantagous if we could provide more up-to-date OS > packages. That would tie nicely into the CI system we've been talking > about for a while. > > Personally, I don't think Gutenprint as a project is in a position to > provide much more than we already do, mostly due to our very limited > resources and expertise with respect to OSX. Of our current-ish > contributors, only Steve has the ability to even generate OSX builds, > and we're entirely reliant upon him to test those builds. > > I'm also not terribly fond of Apple, but if improving things for OSX > gains us additional resources to make Gutenprint better for Linux and > other Free Software platforms.. it's worth considering. > > Thoughts? I think it's of great value to have a vendor's support, and of even greater value for the vendor to use Gutenprint as its official solution. From the user's perspective, a consistent experience across OSes is a huge benefit. I can vouch my frustrations with Epson's drivers and inconsistent results between their windows and escpr (linux) drivers. I think the consistent user experience is a great case for avoiding OS-specific features, unless the customers really request them. As far as OSX support itself is concerned, it is a very popular OS, and investing the upfront cost to ensure proper support is worthwhile. Every CITIZEN user on OSX is automatically a Gutenprint user. Financially motivated improvements for OSX users trickle down to Linux users, essentially for free. On the matter of CITIZEN providing its own packages, did they mention whether they want a compile time option to only enable drivers for CITIZEN products? Or are they okay with the generic Gutenprint package? I am certain CITIZEN wants an efficient way to fix bugs and push updates. If they have a good understanding of the code quality requirements for upstream Gutenprint.The key here is to work upstream directly. For that to happen, expectations should be set as clear as possible, and a reasonable release process exist, even if that release means "vendor solved a bunch of pressing issues for their hardware". I have seen Google fork coreboot, and the immense effort they had to put in to upstream their changes after years of independent development. That's a situation to avoid. It creates more work than necessary for every party involved. On the issue of ancient distros, such as RedHat, the key is not depend on newer libraries than those shipped with such distros. Sometimes this can be problematic for upstream, but if maintainers can normally compile on such distros, then they should be able to ship newer releases. DISCLAIMER: I am a Fedora package maintainer. Then there is the organizational issue of how much control CITIZEN wants to have. I imagine that they want a lot of say in tuning the hardware-specific bits applicable to their products, and that they would expect some flexibility in the generic parts for adding relevant features. There's also the question of whether autotools is the right tool to aid in all of the above. It can handle everything, but can it handle it effortlessly and painlessly such that developers won't want to throw themselves off the roof of the CITIZEN HQ on to the pavement below? I hope I've been able to clarify some of the organizational questions that I think would have to be clarified. I have very positive thoughts about this, and would love to see a fruitful relationship develop with hardware vendors. Alex |
|
From: Solomon P. <pi...@sh...> - 2018-02-17 12:15:57
Attachments:
signature.asc
|
On Fri, Feb 16, 2018 at 10:34:42PM -0800, Alex G. wrote: > I think it's of great value to have a vendor's support, and of even greater > value for the vendor to use Gutenprint as its official solution. Aye, but it's not all upsides. :) > From the user's perspective, a consistent experience across OSes is a huge > benefit. I can vouch my frustrations with Epson's drivers and inconsistent > results between their windows and escpr (linux) drivers. I think the > consistent user experience is a great case for avoiding OS-specific > features, unless the customers really request them. Yes, I've already made this point. > As far as OSX support itself is concerned, it is a very popular OS, and > investing the upfront cost to ensure proper support is worthwhile. Every > CITIZEN user on OSX is automatically a Gutenprint user. Financially > motivated improvements for OSX users trickle down to Linux users, > essentially for free. Gutenprint arguably already has "good enough" OSX support. The question is if Citizen agrees, and if not, what changes would be necessary. Unfortunately, in this specific case [1], the areas I suspect would need improvement would all be OSX-specific polish and thus not really lead to any trickle down to Linux.. (Due to Gutenprint's excellent support for OEM versions of the Citizen printers, I expect that all that's needed for hadware enablement would be a couple of minor bugfixes..) > On the matter of CITIZEN providing its own packages, did they mention > whether they want a compile time option to only enable drivers for CITIZEN > products? Or are they okay with the generic Gutenprint package? I am certain > CITIZEN wants an efficient way to fix bugs and push updates. This is an open question, and it raises the question of the need to have mutiple gutenprint[-derived] "packages" installed. I'd really prefer to avoid this. I think, at minimum, we would need to generate more frequent (point) releases for bugfixes. I already do this for other commercial players I support, only for specific Linux targets. > If they have a good understanding of the code quality requirements for > upstream Gutenprint.The key here is to work upstream directly. For > that to happen, expectations should be set as clear as possible, and a > reasonable release process exist, even if that release means "vendor > solved a bunch of pressing issues for their hardware". I don't think Citizen (or at least the folks engaging with us) has the technical capability to work directly with us as a direct contributor. But behind the scenes, Robert has put in a great deal of effort to improve our ability to spin (and QA) new releases rapidly, and I'm working towards setting up a CI system to run everything through nightly. OSX packages aren't part of that yet, unfortunately. > On the issue of ancient distros, such as RedHat, the key is not depend on > newer libraries than those shipped with such distros. Sometimes this can be > problematic for upstream, but if maintainers can normally compile on such > distros, then they should be able to ship newer releases. DISCLAIMER: I am a > Fedora package maintainer. If we go the package-generation route, it would be using the appropriate distro's tools to generate native packages, so no newer stuff will ever get pulled in. (My main frustration with distros has been with Ubuntu. They shipped a buggy pre-release snapshot with one LTS release, and refused to update it. I still get bug reports about that. Bah.) > Then there is the organizational issue of how much control CITIZEN wants to > have. I imagine that they want a lot of say in tuning the hardware-specific > bits applicable to their products, and that they would expect some > flexibility in the generic parts for adding relevant features. Gutenprint already has excellent mechanisms for tuning parameters on a per-device basis, but we don't envision a situation where core/generic changes would be necessary. In any case, there'd be little point in having those tweaks live solely on a Citizen-specific release branch. > There's also the question of whether autotools is the right tool to aid in > all of the above. It can handle everything, but can it handle it > effortlessly and painlessly such that developers won't want to throw > themselves off the roof of the CITIZEN HQ on to the pavement below? I get the feeling they don't want to (if not outright incapable of) getting their hands dirty here, instead wanting us to deal with all of that. So in that sense autotools is fine. (I've wanted to junk autotools in favor of something less migrane-inducing, most likely cmake, but gutenprint's build is actually pretty complicated, even by autotools' standards...) > I hope I've been able to clarify some of the organizational questions that I > think would have to be clarified. I have very positive thoughts about this, > and would love to see a fruitful relationship develop with hardware vendors. As I mentioned earlier, I'm not concerned about the core bits and the actual "driver" itself. We already know that's solid, even under OSX. Instead, I worry about our ability to meaningfully provide OSX-specific expertise and polish that I believe necessary to satisfy Citizen's needs. Of Gutenprint's active contributors, only one of us even has access to an OSX-capable system. Even if Citizen tosses a pile of money our way so we can purchase the appropriate hardware, it's still going to take time to ramp up, and we all have dayjobs and families that come first. :) - Solomon -- Solomon Peachy pizza at shaftnet dot org Coconut Creek, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |
|
From: Johannes M. <js...@su...> - 2018-02-16 09:48:53
|
Hello, On Feb 15 14:59 Solomon Peachy wrote (excerpt): > Essentially, Citizen is considering using Gutenprint as the basis of > their future OSX drivers. Thanks to customer demand, they are also > interested in providing official Linux support too. ... > ... but what's unclear is the level of polish > they're after -- eg are they okay with a generic Gutenprint driver > package not unlike we already supply today, or would they want some sort > of unique-to-citizen release? Would they want unique-to-OSX features, > like a spiffier control panel or status monitor? And (rather > importantly) are the terms of the GPL acceptible? I strongly recommend to "Keep Separated Issues Separated" (i.e. "KSIS" cf. KISS and RFC 1925 item 5 ;-) which means here: In any case keep the plain printer driver (i.e. the software that produces the final printer data) separated from any optional other printing related software (like special user frontends or any printer specific tools). The plain printer driver and only the plain printer driver should be in Gutenprint under its license but anthing else must be separated software in whatever form (as the makers of that separated software like it). Mixing up the plain printer driver together with any software that does not strictly belong to the plain printer driver results in nothing else but an endless sequence of various annoyances for anybody: The software developers, the (re)-distributors of such software (e.g. Linux distributions), those who must maintain such bloatware (e.g. support people), and finally and most important the end-users (who suffer first and foremost from each single issue in such "messware"). Perhaps the most severe problem of "all in one software" is when license issues cannot be solved (One license to rule them all, one license to find them, One license to bring them all and in the darkness bind them, In the land of legal issues where the Shadows lie ;-) But basically each and every printer manufacturer that makes "printing software" intends to provide to his users his "one and only fully complete ultimate right final solution". No surprise when things end up in an unsupportable nightmare in particular for those pitful end-users who have various different printers from various different manufacturers. Think about admins who maintain central print servers for hundreds of printers from various manufacturers. Not any kind of user GUI makes sense on a print server nor is an admin interested in any printer specific tools. Only plain generic software makes sense on a print server and only software that is "scriptable" i.e. where the admin can automate his daily tasks by (bash) scripts (i.e. only generic programs that run on plain command line are useful, not any kind of graphical stuff on server machines), cf. the section "Command-line Tools" in https://en.opensuse.org/SDB:CUPS_in_a_Nutshell ("If you are not sure which graphical tool is best suited for certain special configurations or print queue maintenance actions, use command-line tools instead.") See the section "Conditions" in https://en.opensuse.org/SDB:Information_for_Printer_Manufacturers_Regarding_Linux_Support The technical parts in that article are somewhat outdated but the generic information therein should be still right. Also have a look at the section "User expectations" in https://en.opensuse.org/Concepts_printing Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) |
|
From: Solomon P. <pi...@sh...> - 2018-02-16 12:43:10
Attachments:
signature.asc
|
On Fri, Feb 16, 2018 at 10:48:51AM +0100, Johannes Meixner wrote: > In any case keep the plain printer driver > (i.e. the software that produces the final printer data) > separated from any optional other printing related software > (like special user frontends or any printer specific tools). I'd rather not even create any special stuff if at all possible; it's nearly always an affront to sanity. :) > The plain printer driver and only the plain printer driver > should be in Gutenprint under its license but anthing else > must be separated software in whatever form (as the makers > of that separated software like it). Amen, but the necessary USB backend does blur that line a little bit. (It's already used as the data source for status UIs, but there are some hiccups with respect to multiple models using the same backend due to the need to attach and query serial numbers via non-standard means..) > See the section "Conditions" in > https://en.opensuse.org/SDB:Information_for_Printer_Manufacturers_Regarding_Linux_Support > The technical parts in that article are somewhat outdated > but the generic information therein should be still right. > Also have a look at the section "User expectations" in > https://en.opensuse.org/Concepts_printing Especially "Printing should work without attracting attention" I personally don't care about supporting proprietary OSes, and wouldn't lose any sleep if we completely dropped OSX tomorrow. I'd rather put that effort into a CI system that can generate up-to-date Linux distro packages automatically. (And OSX too, but I can't justify spending money on the hardware to enable that, or the time to figure out how to automate it, to say nothing of keeping up with Apple's whims..) Meanwhile, I'm hoping that Citizen can be persuaded that keeping things simple but functional is the best approach to take. - Solomon -- Solomon Peachy pizza at shaftnet dot org Coconut Creek, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |
|
From: <fo...@wa...> - 2018-02-16 16:59:09
Attachments:
signature.asc
|
I have successfully built an OS X driver .bundle of Gutenprint using a modified version of Steve’s install bash script + the packaging app called Packages (http://s.sudre.free.fr/Software/Packages/about.html) There were some hiccups in getting all the binaries signed properly in High Sierra but that has been accomplished. It’s rather straight forward and I would be happy to make a write-up if you all want to update the documentation on this. (Current documentation for OS X packaging is not up to date). The only stumble that I have found to making vendor specific OS X variants is this: I have found NO way to have multiple variants of gutenprint in /usr/libexec/cups/driver. This is the part of the system that populates the list of available “gutenprint printer drivers” when you go to sys prefs and then hit the + button and then calls the appropriate binary to make the ppd and install the printer. The only way to distribute a Gutenprint-derived independant driver is to pre-build the PPDs and place in >Library>Printers>PPDs>Contents>Resources>. That’s the only sticking point that I see to this. Another thing that could use work related to making vendor spec versions would be the ability to build more specific PPDs (like the ability to only generate simple PPDs or to more eloquently customize the simple PPD options). The other thing that I think is do-able (OS X specific) is the ability to have ColorSync select an output ICC based on the Mediatype chosen. That said, none of that programming has been done in genppd.c There is only the generics (sRGB, etc) that have been defined for OS X. Best, Walker > On Feb 15, 2018, at 2:59 PM, Solomon Peachy <pi...@sh...> wrote: > > On Sun, Feb 11, 2018 at 01:09:50PM -0500, Solomon Peachy wrote: >> Can you provide some specifics to what you mean by "commercial grade"? >> Gutenprint is already widely used for commercial purposes (such as photo >> kiosks) and it is not clear how Gutenprint may be lacking in this >> regard. Are you perhaps interested in using Gutenprint as the basis of >> an application SDK, or looking to replace your current OSX drivers? > > Gary and I have done a few rounds of off-list discussion, but he's going > to be out of the office for a few days so it seemed like time to bring > it back into the open to see what everyone else thinks. > > Essentially, Citizen is considering using Gutenprint as the basis of > their future OSX drivers. Thanks to customer demand, they are also > interested in providing official Linux support too. > > From our discussions, it appears as if the core printer support is > already essentially complete and fairly well tested, so I expect there > will only be a little bit of work to be done on the hardware enablement > front (essentially fixing any bugs uncovered by a proper QA cycle with > real hardware, and possibly tuning the output or creating an ICC profile > to match what their existing drivers generate) > > So while that is all good and beneficial for all involved, I believe > they're really looking for a one-stop vendor relationship that can, for > appropriate consideration, produce an installable driver package for > them, and provide ongoing maintainence and feature releases as bugfixes, > hardware, and new OS releases warrant. They would handle end-user > support. > > That's a reasonable wish, but what's unclear is the level of polish > they're after -- eg are they okay with a generic Gutenprint driver > package not unlike we already supply today, or would they want some sort > of unique-to-citizen release? Would they want unique-to-OSX features, > like a spiffier control panel or status monitor? And (rather > importantly) are the terms of the GPL acceptible? > > On the Linux front, exising Linux distro channels are probably okay if > they are recent enough, but for older/enterprise/LTS-type distros it > would be highly advantagous if we could provide more up-to-date OS > packages. That would tie nicely into the CI system we've been talking > about for a while. > > Personally, I don't think Gutenprint as a project is in a position to > provide much more than we already do, mostly due to our very limited > resources and expertise with respect to OSX. Of our current-ish > contributors, only Steve has the ability to even generate OSX builds, > and we're entirely reliant upon him to test those builds. > > I'm also not terribly fond of Apple, but if improving things for OSX > gains us additional resources to make Gutenprint better for Linux and > other Free Software platforms.. it's worth considering. > > Thoughts? > > - Solomon > -- > Solomon Peachy pizza at shaftnet dot org > Coconut Creek, FL ^^ (email/xmpp) ^^ > Quidquid latine dictum sit, altum videtur. > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > Gimp-print-devel mailing list > Gim...@li... > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
From: Robert K. <rl...@al...> - 2018-02-18 19:32:00
|
On Fri, 16 Feb 2018 10:48:51 +0100 (CET), Johannes Meixner wrote: > > Hello, > > On Feb 15 14:59 Solomon Peachy wrote (excerpt): >> Essentially, Citizen is considering using Gutenprint as the basis of >> their future OSX drivers. Thanks to customer demand, they are also >> interested in providing official Linux support too. > ... >> ... but what's unclear is the level of polish >> they're after -- eg are they okay with a generic Gutenprint driver >> package not unlike we already supply today, or would they want some sort >> of unique-to-citizen release? Would they want unique-to-OSX features, >> like a spiffier control panel or status monitor? And (rather >> importantly) are the terms of the GPL acceptible? > > I strongly recommend to "Keep Separated Issues Separated" > (i.e. "KSIS" cf. KISS and RFC 1925 item 5 ;-) > which means here: > > In any case keep the plain printer driver > (i.e. the software that produces the final printer data) > separated from any optional other printing related software > (like special user frontends or any printer specific tools). I don't completely agree with this. We've never kept front ends and printer-specific tools separate in a packaging sense (individual distributions are as always free to do so). Gutenprint started as the Print plugin for GIMP, then someone took much of it and wrote a Ghostscript driver around it, which drove separating the GUI from the core. When CUPS and IJS came along, we again focused on separating the core library from the front ends. And we do have some printer specific tools; escputil is one such, but the dyesub backend is also printer-specific (albeit necessary). I don't object to such things necessarily, just want to make sure that we really understand what we're releasing and layer things proper. > The plain printer driver and only the plain printer driver > should be in Gutenprint under its license but anthing else > must be separated software in whatever form (as the makers > of that separated software like it). So what's the "plain printer driver"? Is it libgutenprint? Is it libgutenprint+CUPS? After all, the CUPS driver is layered on top of the core library. What about the GIMP plugin? This is always a judgment call. Having everything be separate, on its own release timeline, imposes costs as well. It makes changing the lower levels very difficult, as more coordination needs to be performed. I already laid out my thoughts in my previous message. > Mixing up the plain printer driver together with any software > that does not strictly belong to the plain printer driver > results in nothing else but an endless sequence > of various annoyances for anybody: The software developers, > the (re)-distributors of such software (e.g. Linux distributions), > those who must maintain such bloatware (e.g. support people), > and finally and most important the end-users (who suffer > first and foremost from each single issue in such "messware"). > > Perhaps the most severe problem of "all in one software" > is when license issues cannot be solved > (One license to rule them all, one license to find them, > One license to bring them all and in the darkness bind them, > In the land of legal issues where the Shadows lie ;-) That's why everything in Gutenprint needs to be licensed under a common license -- GPL2+ (GPL2, GPL3, or GPL3+ aren't satisfactory). I'd be willing to accept something layered under a strictly more permissive license (MIT, for instance), but not the other way around. > But basically each and every printer manufacturer that makes > "printing software" intends to provide to his users his > "one and only fully complete ultimate right final solution". Again, see my comments in the message I just sent. If a printer manufacturer wants to donate an extensible GUI that could be useful for all printer users, but only fill in the details for their printers, I don't see any harm in it. Yes, it means those who support other families have more work to do if they want the GUI support, but that's not intrinsically a bad thing. Distributing that kind of GUI separately means that either it has to use the PPD interface to CUPS without anything else (since we don't promise anything more, even though we have additional interfaces we use internally) or that it has to be kept up to date with libgutenprint. If that package really is specific to one make of printer it's a different matter, but that's again a judgment call. > Think about admins who maintain central print servers > for hundreds of printers from various manufacturers. > Not any kind of user GUI makes sense on a print server > nor is an admin interested in any printer specific tools. Again, not necessarily so. A common status monitor would be of value, and a user GUI might be useful to the organization's users. > Only plain generic software makes sense on a print server > and only software that is "scriptable" i.e. where the admin > can automate his daily tasks by (bash) scripts (i.e. only > generic programs that run on plain command line are useful, > not any kind of graphical stuff on server machines), > cf. the section "Command-line Tools" in > https://en.opensuse.org/SDB:CUPS_in_a_Nutshell > ("If you are not sure which graphical tool is best suited for > certain special configurations or print queue maintenance > actions, use command-line tools instead.") > > See the section "Conditions" in > https://en.opensuse.org/SDB:Information_for_Printer_Manufacturers_Regarding_Linux_Support > The technical parts in that article are somewhat outdated > but the generic information therein should be still right. > > Also have a look at the section "User expectations" in > https://en.opensuse.org/Concepts_printing I'm getting more than a bit tired of "Linux printing must be mediated through PPD files and PPD files only", if truth be told. It results in a very inflexible and limiting UI. There's no good way of expressing dependencies, selectively making functionality available, iconography such as "this is a diagram of the input slot you've specified", and such. We've been frozen in this rut for too long. I don't want to take in a GUI that's specific to a particular printer vendor, but if it's extensible and can be made general, it may be exactly what's needed. -- Robert Krawitz <rl...@al...> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: <fo...@wa...> - 2018-02-18 20:04:13
Attachments:
signature.asc
|
> On Feb 18, 2018, at 2:25 PM, Robert Krawitz <rl...@al...> wrote: > > I don't want to take in a GUI that's specific to a particular printer > vendor, but if it's extensible and can be made general, it may be > exactly what's needed. PPDs do feel like a dead-end, and PPD interface extensions in Mac are not compatible with any other OS really. The API for them is also painful. Maybe it’s time to work on a general Win/Lin/Mac GUI (like an actual app) wrapped around core libgutenprint with IPP capability? This would be essentially taking the GIMP plugin and making it standalone and modern cross/compatible (and re-designed). I think a lot of interface devs (from many different places out there) could get behind something like this . . . . . and it would allow for a change in development paradigm too . . . Thoughts? Best, Walker |
|
From: Robert K. <rl...@al...> - 2018-02-18 19:48:10
|
Sorry for the delay; I wanted to think before I wrote. On Thu, 15 Feb 2018 14:59:36 -0500, Solomon Peachy wrote: > On Sun, Feb 11, 2018 at 01:09:50PM -0500, Solomon Peachy wrote: >> Can you provide some specifics to what you mean by "commercial grade"? >> Gutenprint is already widely used for commercial purposes (such as photo >> kiosks) and it is not clear how Gutenprint may be lacking in this >> regard. Are you perhaps interested in using Gutenprint as the basis of >> an application SDK, or looking to replace your current OSX drivers? > > Gary and I have done a few rounds of off-list discussion, but he's going > to be out of the office for a few days so it seemed like time to bring > it back into the open to see what everyone else thinks. Thanks for taking point on this. > Essentially, Citizen is considering using Gutenprint as the basis of > their future OSX drivers. Thanks to customer demand, they are also > interested in providing official Linux support too. > > =46rom our discussions, it appears as if the core printer support is > already essentially complete and fairly well tested, so I expect there > will only be a little bit of work to be done on the hardware enablement > front (essentially fixing any bugs uncovered by a proper QA cycle with > real hardware, and possibly tuning the output or creating an ICC profile > to match what their existing drivers generate) > > So while that is all good and beneficial for all involved, I believe > they're really looking for a one-stop vendor relationship that can, for > appropriate consideration, produce an installable driver package for > them, and provide ongoing maintainence and feature releases as bugfixes, > hardware, and new OS releases warrant. They would handle end-user > support. We're not a corporate entity that can contract with outside parties for something like this. If someone wants to contract with them to do this, that's their business, but I'm not going to be that person and I'm not going to commit to a particular release cycle for this purpose. My personal preference -- and again, I'm speaking my own opinion here, although it's a little hard to separate from my role as Gutenprint project lead -- would be for an engagement model similar to Datamax O'Neill, where Steve is seconded to the project and participates actively, with commit privileges and all that. That engagement doesn't have to take the form of an employee in the legal sense; a consultant/contractor could do this perfectly well. I'm more comfortable with that because things aren't going to simply get thrown over the fence at us. If someone in that position wants a release to align with their needs, I'm a lot more receptive to doing it, since the person making the request has skin in our game too. > That's a reasonable wish, but what's unclear is the level of polish > they're after -- eg are they okay with a generic Gutenprint driver > package not unlike we already supply today, or would they want some sort > of unique-to-citizen release? Would they want unique-to-OSX features, > like a spiffier control panel or status monitor? And (rather > importantly) are the terms of the GPL acceptible? GPL needs to be a given. There are ways of layering something proprietary on top of Gutenprint without violating the GPL, and while that's legal, it's not something I want to distribute in Gutenprint. And I really want the license terms to be fully GPL2+ compliant, not "GPL2-only" or "GPL3-only" or "GPL3+". A variety of license terms can lead to all manner of problems, some of which might not be anticipated up front. If someone wants to license something layered (using the libgutenprint API) as MIT, I think that's OK because the MIT terms are compliant with the GPL. But nothing that's more restrictive in any way than GPL2+ is OK (remember, copyright is held by individuals, so basically anyone who has contributed to the core can effectively veto any change, so I'm not claiming any particular privilege here). I'm not entirely averse to distributing components that are by their nature specific to a particular make or model. We already have a few of those, escputil and the dyesub backend. A nice control panel or status monitor would be a useful contribution, as long as it's not gratuitously tied to a particular make or requires use of components that are not themselves GPL2+-compliant. But if they wanted to donate a control panel or status monitor with a reasonable and extensible architecture, and instantiate only Citizen printers in it, that's perfectly fine. It's not their job to support other printers; if we want to support other printers in it, it's reasonable for them to tell us that we have to do the heavy lifting. And if they want to do a really good job with Citizen printers, supporting capabilities and quality that we don't support elsewhere, that's also perfectly good. If it means that we have to make some architectural changes to support those capabilities, I'm all ears, especially given where we are with 3.0. > On the Linux front, exising Linux distro channels are probably okay if > they are recent enough, but for older/enterprise/LTS-type distros it > would be highly advantagous if we could provide more up-to-date OS > packages. That would tie nicely into the CI system we've been talking > about for a while. True, although then we have the problem of which distributions we support and having the infrastructure to support them. We've done pretty well (and I don't think it's an accident) at avoiding hidden dependencies and assumptions, and I'm reasonably confident that if we were, say, to build a RHEL 5 package it would work. But we'd still need to maintain all that. > Personally, I don't think Gutenprint as a project is in a position to > provide much more than we already do, mostly due to our very limited > resources and expertise with respect to OSX. Of our current-ish > contributors, only Steve has the ability to even generate OSX builds, > and we're entirely reliant upon him to test those builds. ...which, of course, is our big exception to the "no distribution-specific bits". OS X isn't a distribution in the traditional Linux sense; it's a huge, essentially undifferentiated blob, and add-ons are only distributed through the store, which doesn't allow GPL anyway. > I'm also not terribly fond of Apple, but if improving things for OSX > gains us additional resources to make Gutenprint better for Linux and > other Free Software platforms.. it's worth considering. My general take is that portability is a good thing. It helps weed out hidden bugs and dependencies that could go from the latent to the real at any time. It also increases the user base, which also helps catch problems and push improvements. -- Robert Krawitz <rl...@al...> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Solomon P. <pi...@sh...> - 2018-02-23 15:44:43
Attachments:
signature.asc
|
On Sun, Feb 18, 2018 at 01:59:32PM -0500, Robert Krawitz wrote:
> We're not a corporate entity that can contract with outside parties
> for something like this.
Out of curiousity, have you ever given any thought to joining the SFC
or similar group that could provide a legal umbrella for Gutenprint?
> My personal preference -- and again, I'm speaking my own opinion here,
> although it's a little hard to separate from my role as Gutenprint
> project lead -- would be for an engagement model similar to Datamax
> O'Neill, where Steve is seconded to the project and participates
> actively, with commit privileges and all that.
I've expressed this desire to Citizen, but unfortunatley they lack the
[appropriately-skilled] resources to directly engage in this way. In
time, this may change though, especially if this endeavor comes to
fruition and is ultimately successful.
> GPL needs to be a given. There are ways of layering something
> proprietary on top of Gutenprint without violating the GPL, and while
> that's legal, it's not something I want to distribute in Gutenprint.
That was one of my main concerns, and I'm glad to say that they seem to
be completely on board with the GPL's terms -- in particular the source
code requirements and the lack of restrictions on field-of-use.
> I'm not entirely averse to distributing components that are by their
> nature specific to a particular make or model. We already have a few
> of those, escputil and the dyesub backend. A nice control panel or
> status monitor would be a useful contribution, as long as it's not
> gratuitously tied to a particular make or requires use of components
> that are not themselves GPL2+-compliant. But if they wanted to donate
> a control panel or status monitor with a reasonable and extensible
> architecture, and instantiate only Citizen printers in it, that's
> perfectly fine. It's not their job to support other printers; if we
> want to support other printers in it, it's reasonable for them to tell
> us that we have to do the heavy lifting.
For now, they don't seem to seek anything special layered on top, and
have already expressed a strong desire to not fund work that (directly)
benefits non-Citizen models.
I believe I've accurately conveyed (and agree with) your position.
* * * * * *
Meanwhile, here's where things more or less stand:
* Citizen acknowledges that Gutenprint is only provided under "open
source" (specifically, GNU GPL) terms so there can be no expectation
of secrets in anything released.
* Citizen is happy with telling OSX (and Linux) users to download
a Gutenprint-branded driver package that also supports non-Citizen
printers. Citizen would prefer to host downloads, at least for
OSX releases.
* Citizen does not currently need any new features (especially
OSX-specific ones), but would like a rough roadmap of our current
plans and may want to fund those and/or other features they deem
important. All developments would become part of Gutenprint proper.
* Citizen will likely need out-of-band binary release packages
generated (eg bugfixes or features, new OS releases, new printer
models)
* Initial focus is on OSX, Linux is sort of coming along for the ride.
Citizen's main interest on Linux is ARM platforms like the Raspberry
Pi, so there's a strong desire to provide updated distro packages there.
* Citizen is very pleased with the output quality of Gutenprint, which
is better out-of-the-box than their current OSX drivers. (Yay us!)
* So far, the only specific bugs/quirks brought up have been minor in
nature; all of their current models work out-of-the-box with (nearly)
full feature coverage. It's likely a formal QA cycle will identify
issues that will need addressing.
* We're working on an NDA to continue discussions and provide access
to documentation. They will also make available a technical contact.
* We are negotiating details about scope of support; I anticipate being
able to provide everything they are asking for, although some
equipment will need to be purchased -- eg a spectrophotometer to
generate ICC profiles, and a Mac to generate OSX builds.
* We(I) would perform first-pass QA on releases, but Citizen would
handle more comprehensive QA, and provide first/second-tier OSX
support. For Linux support, status quo for the time being.
So, at this point, there's very little new development scoped out; this
discussion is mostly a matter of setting expectations and getting the
ducks neatly lined up so if there is a problem they (and I) are
comfortable with our/my ability to support them.
There was one other thing that came up. I'll just post it verbatim:
I’m a marketing/sales guy and I’m still scratching my head about how
I will promote this? “Citizen announces it will use Gutenprint
drivers for all Mac users”. Please think about this as my PR agency
has a global reach (Petapixel, DP review etc.). We need to align
both the techie and marketing components.
My response was that I'd see what everyone else thought about this, but
that IMO Gutenprint has no particular need or want for publicity, unless
it leads to more contributions.
(I think we'll be happy if they properly comply with the GPL and
it's made clear to their customers that they should contact Citizen for
support rather than us..)
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Coconut Creek, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
|
|
From: Johannes M. <js...@su...> - 2018-02-19 21:02:35
|
Hello, On Feb 18 14:25 Robert Krawitz wrote (excerpt): > On Fri, 16 Feb 2018 10:48:51 +0100 (CET), Johannes Meixner wrote: >> On Feb 15 14:59 Solomon Peachy wrote (excerpt): >>> Essentially, Citizen is considering using Gutenprint as the basis of >>> their future OSX drivers. Thanks to customer demand, they are also >>> interested in providing official Linux support too. >> ... >>> ... but what's unclear is the level of polish >>> they're after -- eg are they okay with a generic Gutenprint driver >>> package not unlike we already supply today, or would they want some sort >>> of unique-to-citizen release? Would they want unique-to-OSX features, >>> like a spiffier control panel or status monitor? And (rather >>> importantly) are the terms of the GPL acceptible? >> >> I strongly recommend to "Keep Separated Issues Separated" >> (i.e. "KSIS" cf. KISS and RFC 1925 item 5 ;-) >> which means here: >> >> In any case keep the plain printer driver >> (i.e. the software that produces the final printer data) >> separated from any optional other printing related software >> (like special user frontends or any printer specific tools). > > I don't completely agree with this. > > We've never kept front ends and printer-specific tools separate in a > packaging sense (individual distributions are as always free to do > so). Gutenprint started as the Print plugin for GIMP, then someone > took much of it and wrote a Ghostscript driver around it, which drove > separating the GUI from the core. When CUPS and IJS came along, we > again focused on separating the core library from the front ends. > > And we do have some printer specific tools; escputil is one such, but > the dyesub backend is also printer-specific (albeit necessary). I > don't object to such things necessarily, just want to make sure that > we really understand what we're releasing and layer things proper. I am sorry - I was not sufficiently clear. Of course as long as "additional software" is under the same license as the "plain printer driver", it is no legal problem to also have the "additional software" inside the Gutenprint sources. But even then the "additional software" needs to be sufficiently separated so that the "plain printer driver" still can be compiled and still can work even without the "additional software". Remember what I wrote in the "5.2.14-pre2" mail tread about how much I am impressed how well Gutenprint can be "just built" and how well the "plain printer driver" still works even on Linux systems that could be considered to be "ancient" (SLES10 in my case) and what you had replied https://sourceforge.net/p/gimp-print/mailman/gimp-print-devel/thread/20180105154804.GA4982%40shaftnet.org/#msg36179243 excerpt: --------------------------------------------------------------------- From: Robert Krawitz <rlk@al...> - 2018-01-05 15:26:32 There's no good reason for an infrastructure project of this kind not to build on older platforms. Printers are the kind of things that people like to hook up to who knows what; there's nothing Gutenprint does that inherently requires the latest and greatest anything. Support for old CUPS versions isn't problematic either. --------------------------------------------------------------------- What you wrote is the goal behind why I think it is important to keep the plain printer driver separated from any additional software. Simply put: Please try to keep Gutenprint an infrastructure project. It does not matter when newer things like the dyesub backend require newer generic libraries like libusb-1.0. This does not break the idea of an infrastructure project because it is still a generic (low level) requirement. I don't mind if newer printers that need a special new backend cannot work on "ancient" Linux systems. But I would mind if newer Gutenprint could no longer be built or could no longer work at all on "ancient" Linux systems only because of a new backend for some newer printers. My reason behind is that from the past I know that >> ... basically each and every printer manufacturer that makes >> "printing software" intends to provide to his users his >> "one and only fully complete ultimate right final solution". Usually this means that printer manufacturers tend to tightly combine their "plain printer driver" together with their special "additional pieces" where the latter usually require whatever further additional stuff like special libraries or special scripting languages and so on until all gets mixed up and comes to a bad end in one huge "interdepedency monstrosity". I fear when the "plain printer driver" and "additional software" is in one same source archive, it will happen that deveolpers at printer manufacturers assume they can "just combine" all that arbitrarily as they like. I fear over time they may no longer keep separated parts separated because it is "just so easy" to "simply call" whatever additional "nice to have" functionality from inside the "plain printer driver". E.g. just a nice GUI popup dialog written in whatever scripting language in case of "out of paper" or "paper jam" because that "just works so nicely" with a USB printer connected to the deveolper's local workstation. In contrast when the "plain printer driver" sources are kept strictly separated from any "additional software" it ensures that separated parts are kept separated. Of course as long as developers do keep separated parts separated all sources could be in one same source archive but that would increase likelihood things could get messed up. > Again, see my comments in the message I just sent. If a printer > manufacturer wants to donate an extensible GUI that could be useful > for all printer users, but only fill in the details for their > printers, I don't see any harm in it. Yes, it means those who support > other families have more work to do if they want the GUI support, but > that's not intrinsically a bad thing. Distributing that kind of GUI > separately means that either it has to use the PPD interface to CUPS > without anything else (since we don't promise anything more, even > though we have additional interfaces we use internally) or that it has > to be kept up to date with libgutenprint. I fear distributing the GUI in Gutenprint will over time make the plain printer driver somehow depend on that GUI. Distributing that GUI outside of Gutenprint ensures the GUI will also work on a separated client machine (using operating system version N with Gutenprint version n) when the Gutenprint printer driver is on a server machine (using operating system version M with Gutenprint version m) and then that GUI may even work with any other printer driver because "outside of Gutenprint" means it must wrork generically with CUPS and not be a Gutenprint-specific GUI. Imagine the confusing end-user-experience when each driver would have its own driver-specific GUI. > A common status monitor would be of value, > and a user GUI might be useful to the organization's users. Yes - but "common" is the crucial word here. A generically working "common printing fronted" called "Common Printing Dialog" is the goal, cf. https://wiki.linuxfoundation.org/openprinting/commonprintingdialog https://wiki.linuxfoundation.org/openprinting/plan-completion-common-printing-dialog https://github.com/dracarys09/gcp-backend/wiki/1.-Google-Summer-of-Code-2017-|-Common-Printing-Dialog The printer manufactuers should contribute to that. There their contributions and cooperation would be needed and acually helpful and much appreciated. > I'm getting more than a bit tired of "Linux printing must be mediated > through PPD files and PPD files only", if truth be told. As far as I know PPD files are declared "deprecated" at CUPS upstream (but PPD files will still be supported by CUPS for a longer time) and current CUPS provides newer APIs for that functionality. But I assume those newer CUPS APIs confilct with that --------------------------------------------------------------------- ... there's nothing Gutenprint does that inherently requires the latest and greatest anything. Support for old CUPS versions isn't problematic either. --------------------------------------------------------------------- I think such issue would have to be discussed with CUPS upstream. E.g. what the "officially recommended right way" is how to implement things so that the new way is used if available and the old PPD way as fallback to be backward compatible. Think about a server and two client systems where each of the three runs a substantially different CUPS version (like old CUPS 1.5 versus newer CUPS 1.7 versus newest CUPS 2.3) in any combination. > I don't want to take in a GUI that's specific to a particular printer > vendor, but if it's extensible and can be made general, it may be > exactly what's needed. I think another precondition should be that the GUI is not specific to a driver software like Gutenprint and then I think such a GUI is really generic and therefore its sources could and should be separated from the Gutenprint sources so that this GUI could be compiled and distributed also without Gutenprint. E.g. think about a user with a modern PostScript+PDF+(PWG-Raster) printer that does not need any driver software. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) |
|
From: Solomon P. <pi...@sh...> - 2018-02-19 22:24:46
Attachments:
signature.asc
|
On Mon, Feb 19, 2018 at 11:37:23AM +0100, Johannes Meixner wrote: > As far as I know PPD files are declared "deprecated" at CUPS upstream > (but PPD files will still be supported by CUPS for a longer time) > and current CUPS provides newer APIs for that functionality. > But I assume those newer CUPS APIs confilct with that Unfortuntely, those "newer APIs" appear to only be suitable for printing *clients*. For those like Gutenprint who are trying to write printing *drivers*, the PPD APIs are all we have to work with. - Solomon -- Solomon Peachy pizza at shaftnet dot org Coconut Creek, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |
|
From: Robert K. <rl...@al...> - 2018-02-19 22:27:06
|
On Mon, 19 Feb 2018 11:37:23 +0100 (CET), Johannes Meixner wrote: > I am sorry - I was not sufficiently clear. > > Of course as long as "additional software" is under the same license > as the "plain printer driver", it is no legal problem to also have > the "additional software" inside the Gutenprint sources. > > But even then the "additional software" needs to be sufficiently > separated so that the "plain printer driver" still can be compiled > and still can work even without the "additional software". > > Remember what I wrote in the "5.2.14-pre2" mail tread > about how much I am impressed how well Gutenprint can be "just built" > and how well the "plain printer driver" still works even on Linux > systems that could be considered to be "ancient" (SLES10 in my case) > and what you had replied Yes, I do remember that and take pride in it. > https://sourceforge.net/p/gimp-print/mailman/gimp-print-devel/thread/20180105154804.GA4982%40shaftnet.org/#msg36179243 > > excerpt: > --------------------------------------------------------------------- > From: Robert Krawitz <rlk@al...> - 2018-01-05 15:26:32 > > There's no good reason for an infrastructure project of this kind not > to build on older platforms. Printers are the kind of things that > people like to hook up to who knows what; there's nothing Gutenprint > does that inherently requires the latest and greatest anything. > Support for old CUPS versions isn't problematic either. > --------------------------------------------------------------------- > > What you wrote is the goal behind why I think it is important to > keep the plain printer driver separated from any additional software. > > Simply put: > Please try to keep Gutenprint an infrastructure project. The Gutenprint core (and, yes, the CUPS driver and dyesub backend) are things I firmly believe in keeping this kind of commitment about. Of course, if CUPS or libusb were to change incompatibly (and in a way that we couldn't work around) we'd have a problem, but that's largely beyond our control. (Note that internally the CUPS driver is actually layered on the core -- libgutenprint -- and we've not allowed direct CUPS dependencies into it. If CUPS were to change radically or something were to replace it, we should still be able to maintain back compatibility with legacy CUPS. I want to be careful not to break that layering.) But we have made changes; we long ago removed the gdevstp driver and the IJS driver/Foomatic data after considerable discussion in which I believe you participated. So things still can evolve there. But... > It does not matter when newer things like the dyesub backend > require newer generic libraries like libusb-1.0. > This does not break the idea of an infrastructure project > because it is still a generic (low level) requirement. > > I don't mind if newer printers that need a special new backend > cannot work on "ancient" Linux systems. > But I would mind if newer Gutenprint could no longer be built > or could no longer work at all on "ancient" Linux systems > only because of a new backend for some newer printers. This does not preclude optional layered packages. For example, I would have no objection to providing a GUI, even though it would add dependencies, as long as it did not break the core package. And we've distributed a (now alternative) GIMP plugin all along, without causing distributors any problems. If you don't want to distribute it, or a future GUI required a special toolkit, it simply wouldn't be built. We've even separated the GIMP-specific parts from the GTK2-based UI. Actually, the libgutenprint interface as a whole owes more to the GIMP plugin than to CUPS. The dynamic option system makes sense in a UI, but it doesn't in a PPD-based world. We had to implement a special workaround for ensuring that we can enumerate all options, which is needed to construct PPD files. I'm still hoping that ultimately something dynamic will replace static PPD files, which of the 1980's. But we're not going to break CUPS compatibility until and unless it's clear that even the trailing edge has abandoned it (as it became clear about lpr, lprng, and some of the other things out there). But at the same time, I don't want to insist that anything new be released independently of Gutenprint. > My reason behind is that from the past I know that > >>> ... basically each and every printer manufacturer that makes >>> "printing software" intends to provide to his users his >>> "one and only fully complete ultimate right final solution". > > Usually this means that printer manufacturers tend to > tightly combine their "plain printer driver" together > with their special "additional pieces" where the latter > usually require whatever further additional stuff like > special libraries or special scripting languages and so on > until all gets mixed up and comes to a bad end in one > huge "interdepedency monstrosity". I don't want to go there either. I laid out my thoughts on that matter the other day, including what conditions I -- and I'm not the entire project, to be sure -- consider acceptable for that kind of thing. A GUI that isn't tied to a particular vendor is fine, as long as it's extensible, even if whoever donates it only implements the data for one particular vendor. But we can't prevent third parties from releasing their own bits, as long as they follow the GPL. So if some company wants to do that, they have every right to. > I fear when the "plain printer driver" and "additional software" > is in one same source archive, it will happen that deveolpers > at printer manufacturers assume they can "just combine" all that > arbitrarily as they like. As you note, we've avoided this for many years now (getting on toward 19). Please trust -- verify, if you like, as you should -- that we're not going to abandon this willy nilly. > I fear over time they may no longer keep separated parts separated > because it is "just so easy" to "simply call" whatever additional > "nice to have" functionality from inside the "plain printer driver". > E.g. just a nice GUI popup dialog written in whatever scripting > language in case of "out of paper" or "paper jam" because that > "just works so nicely" with a USB printer connected to the > deveolper's local workstation. Well, let's look at the other side of this. An out of paper or paper jam warning really is useful in any environment, even more so in a networked environment (as would a job completion notice). Obviously it would be easier to make work with a local USB printer than with a network printer, but that doesn't mean everything has to be frozen in place either. This is something I've seen as a problem in the Linux printing community: everyone wants to rely solely on the base technologies in use, namely CUPS and PPD files. PPD files, remember, were defined when personal computer memory was measured at best in small numbers of megabytes. There wasn't even a web when the first version of the PPD spec was written, much less REST APIs and all that. There was an attempt, remember, to define a common Linux printing dialog, but it was decided from the get-go that it would use conformant PPD files and those only. There's enough of an extension mechanism in PPD files to allow some amount of this, but it's still basically static. The attempt, which was well-intentioned, foundered over what I believe in large part to this restriction. Given the way PPD files work, it's very difficult to present only relevant options and values to users, or present a UI that allows depicting where the paper is going to get loaded from. And for printers that can detect what kind of paper is loaded, it's not practical (or possible?) to relay that back to the user, gray out non-present paper types, and restrict options to those meaningful for the type of paper. It could be done very differently. It would, I think, be possible to implement a REST API as a layer on the existing Gutenprint API, so that printing (and everything else surrounding it) could be completely networked and provide rich functionality, including status monitoring and all that. The printer could participate actively in the process as well. > In contrast when the "plain printer driver" sources are > kept strictly separated from any "additional software" > it ensures that separated parts are kept separated. Yes, and it also seems to ensure that nobody ever does the integration work needed to produce a good user experience. Or has anyone not noticed that all the printer dialogs -- be they Mozilla, LibreOffice, KDE, GNOME -- all suck where it comes to a decent experience, at least on Linux? And that they're all different, but basically suffer the same core warts? >> Again, see my comments in the message I just sent. If a printer >> manufacturer wants to donate an extensible GUI that could be useful >> for all printer users, but only fill in the details for their >> printers, I don't see any harm in it. Yes, it means those who support >> other families have more work to do if they want the GUI support, but >> that's not intrinsically a bad thing. Distributing that kind of GUI >> separately means that either it has to use the PPD interface to CUPS >> without anything else (since we don't promise anything more, even >> though we have additional interfaces we use internally) or that it has >> to be kept up to date with libgutenprint. > > I fear distributing the GUI in Gutenprint will over time > make the plain printer driver somehow depend on that GUI. Noted but I disagree. It is possible to enforce a strict separation between the layers, and as you note we've succeeded in doing so for many years. If we don't do it, nobody else will do it for us. If we insist on distributing it separately, it becomes a bigger release engineering headache and doesn't necessarily prevent dependencies from popping up. > Distributing that GUI outside of Gutenprint ensures > the GUI will also work on a separated client machine > (using operating system version N with Gutenprint version n) > when the Gutenprint printer driver is on a server machine > (using operating system version M with Gutenprint version m) > and then that GUI may even work with any other printer driver > because "outside of Gutenprint" means it must wrork generically > with CUPS and not be a Gutenprint-specific GUI. Look at the Postscript driver within Gutenprint, which exists solely so that printers not supported by Gutenprint can be used with Gutenprint layered apps (which at this point basically means the GIMP plugin). This can be done, but again, since the Linux printing chain is based on an ancient technology that was created before printers had anything like the capabilities they do today, it's going to be very hard to come up with anything that isn't simply yet another warmed-over PPD-based hack. > Imagine the confusing end-user-experience when each driver > would have its own driver-specific GUI. Which is not where I want to go, as I stated clearly. Let me turn that around: think about how confusing the end user experience is when every application is left to implement its own printing dialog and there's no practical possibility to smooth over the rough edges because they can't be expressed in PPD files. >> A common status monitor would be of value, >> and a user GUI might be useful to the organization's users. > > Yes - but "common" is the crucial word here. > A generically working "common printing fronted" > called "Common Printing Dialog" is the goal, cf. > > https://wiki.linuxfoundation.org/openprinting/commonprintingdialog > > https://wiki.linuxfoundation.org/openprinting/plan-completion-common-printing-dialog > > https://github.com/dracarys09/gcp-backend/wiki/1.-Google-Summer-of-Code-2017-|-Common-Printing-Dialog Which hasn't, so far as I can tell, gone much of anywhere in years. And isn't basing it on Google Cloud Print tying it to a particular vendor (not a hardware vendor, to be sure) also? > The printer manufactuers should contribute to that. > There their contributions and cooperation would be > needed and acually helpful and much appreciated. > >> I'm getting more than a bit tired of "Linux printing must be mediated >> through PPD files and PPD files only", if truth be told. > > As far as I know PPD files are declared "deprecated" at CUPS upstream > (but PPD files will still be supported by CUPS for a longer time) > and current CUPS provides newer APIs for that functionality. > But I assume those newer CUPS APIs confilct with that > --------------------------------------------------------------------- > ... there's nothing Gutenprint > does that inherently requires the latest and greatest anything. > Support for old CUPS versions isn't problematic either. > --------------------------------------------------------------------- > > I think such issue would have to be discussed with CUPS upstream. Fair enough. > E.g. what the "officially recommended right way" is how to > implement things so that the new way is used if available > and the old PPD way as fallback to be backward compatible. > > Think about a server and two client systems where each of the three > runs a substantially different CUPS version (like old CUPS 1.5 > versus newer CUPS 1.7 versus newest CUPS 2.3) in any combination. Obviously we have to retain back end compatibility. But that doesn't mean that an alternative front end should not be done if someone wants to do it. >> I don't want to take in a GUI that's specific to a particular printer >> vendor, but if it's extensible and can be made general, it may be >> exactly what's needed. > > I think another precondition should be that the GUI is not specific > to a driver software like Gutenprint and then I think such a GUI > is really generic and therefore its sources could and should be > separated from the Gutenprint sources so that this GUI could > be compiled and distributed also without Gutenprint. > E.g. think about a user with a modern PostScript+PDF+(PWG-Raster) > printer that does not need any driver software. We've been in analysis paralysis for entirely too long. If we can supply a better experience to our users, I want us to do so. If that comes about by somebody donating a GUI -- even if that somebody has a particular interest, just so long as it's not intrinsically tied to a particular vendor -- that doesn't bother me. -- Robert Krawitz <rl...@al...> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Solomon P. <pi...@sh...> - 2018-02-21 16:32:47
Attachments:
signature.asc
|
On Mon, Feb 19, 2018 at 05:27:02PM -0500, Robert Krawitz wrote: > It could be done very differently. It would, I think, be possible to > implement a REST API as a layer on the existing Gutenprint API, so > that printing (and everything else surrounding it) could be completely > networked and provide rich functionality, including status monitoring > and all that. The printer could participate actively in the process > as well. The core libgutenprint API, definitely, but we will probably need to make some additions like a standard way for gutenprint driver families to express UI constraints or feed printer status in so that we can intelligently limit what options are presented. (eg use media detection to restrict the print size/type options..) There's still a lot of new wrapper code that would need to be written, plus the backend code would need some slicing and dicing. Heh, I wonder if writing a prototype IPP wrapper for libgutenprint would be a good GSoC project. :) - Solomon -- Solomon Peachy pizza at shaftnet dot org Coconut Creek, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |
|
From: Robert K. <rl...@al...> - 2018-02-22 01:03:51
|
On Tue, 20 Feb 2018 11:13:50 -0500, Solomon Peachy wrote: > On Mon, Feb 19, 2018 at 05:27:02PM -0500, Robert Krawitz wrote: >> It could be done very differently. It would, I think, be possible to >> implement a REST API as a layer on the existing Gutenprint API, so >> that printing (and everything else surrounding it) could be completely >> networked and provide rich functionality, including status monitoring >> and all that. The printer could participate actively in the process >> as well. > > The core libgutenprint API, definitely, but we will probably need to > make some additions like a standard way for gutenprint driver families > to express UI constraints or feed printer status in so that we can > intelligently limit what options are presented. (eg use media detection > to restrict the print size/type options..) There's already a standard way for the family drivers to dynamically express UI constraints, given the current state of the settings in the stp_vars_t. Watch what the GIMP plugin does when you change from color to BW output; a lot of the options disappear. I believe that that would be sufficient. The same API mechanism could be used for implementing UI constraints based on printer status, if we had a back channel. > There's still a lot of new wrapper code that would need to be written, > plus the backend code would need some slicing and dicing. > > Heh, I wonder if writing a prototype IPP wrapper for libgutenprint would > be a good GSoC project. :) I don't have time to run that, but if someone wants to be the mentor I'd be happy to work with that person and with the student. -- Robert Krawitz <rl...@al...> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Solomon P. <pi...@sh...> - 2018-02-23 16:10:34
Attachments:
signature.asc
|
On Fri, Feb 16, 2018 at 11:59:02AM -0500, fo...@wa... wrote: > There were some hiccups in getting all the binaries signed properly in > High Sierra but that has been accomplished. It’s rather straight > forward and I would be happy to make a write-up if you all want to > update the documentation on this. (Current documentation for OS X > packaging is not up to date). I'm assuming you have to sign it with a propr Apple Developer key? And I'm sure I speak for everyone here when I say that any documentation updates would be welcomed. :) > The only stumble that I have found to making vendor specific OS X > variants is this: I have found NO way to have multiple variants of > gutenprint in /usr/libexec/cups/driver. This is the part of the > system that populates the list of available “gutenprint printer > drivers” when you go to sys prefs and then hit the + button and then > calls the appropriate binary to make the ppd and install the printer. > The only way to distribute a Gutenprint-derived independant driver is > to pre-build the PPDs and place in > >Library>Printers>PPDs>Contents>Resources>. That’s the only sticking > point that I see to this. Some of that is Gutenprint's fault; it's not intended to be parallel-installable across point releases, and I think the "driver" name is hardcoded to be 'gutenprint'. It may be worth looking into allowing all executable names (and dependent data directories) to be changed at compile-time. Perhaps a filename prefix not unlike how gcc cross compilers are set up? > The other thing that I think is do-able (OS X specific) is the ability > to have ColorSync select an output ICC based on the Mediatype chosen. > That said, none of that programming has been done in genppd.c There is > only the generics (sRGB, etc) that have been defined for OS X. Is this a generic feature that allows arbitrary options to be passed to ColorSync, or is it limited to a specific enumerated set? I wonder if colord on Linux supports something similar. (Traditionally, one will set up multiple queues to the same backend device, one for each setting combination, and associate a unique ICC profile to each queue..) - Solomon -- Solomon Peachy pizza at shaftnet dot org Coconut Creek, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |
|
From: <fo...@wa...> - 2018-02-23 17:41:54
Attachments:
signature.asc
|
> On Feb 23, 2018, at 11:10 AM, Solomon Peachy <pi...@sh...> wrote: > > On Fri, Feb 16, 2018 at 11:59:02AM -0500, fo...@wa... wrote: >> There were some hiccups in getting all the binaries signed properly in >> High Sierra but that has been accomplished. It’s rather straight >> forward and I would be happy to make a write-up if you all want to >> update the documentation on this. (Current documentation for OS X >> packaging is not up to date). > > I'm assuming you have to sign it with a propr Apple Developer key? > > And I'm sure I speak for everyone here when I say that any documentation > updates would be welcomed. :) I’ll do the write-up. > >> The only stumble that I have found to making vendor specific OS X >> variants is this: I have found NO way to have multiple variants of >> gutenprint in /usr/libexec/cups/driver. This is the part of the >> system that populates the list of available “gutenprint printer >> drivers” when you go to sys prefs and then hit the + button and then >> calls the appropriate binary to make the ppd and install the printer. >> The only way to distribute a Gutenprint-derived independant driver is >> to pre-build the PPDs and place in >>> Library>Printers>PPDs>Contents>Resources>. That’s the only sticking >> point that I see to this. > > Some of that is Gutenprint's fault; it's not intended to be > parallel-installable across point releases, and I think the "driver" > name is hardcoded to be 'gutenprint'. It may be worth looking into > allowing all executable names (and dependent data directories) to be > changed at compile-time. Perhaps a filename prefix not unlike how gcc > cross compilers are set up? If this is possible, I think it would be incredibly useful for a whole host of reasons. > >> The other thing that I think is do-able (OS X specific) is the ability >> to have ColorSync select an output ICC based on the Mediatype chosen. >> That said, none of that programming has been done in genppd.c There is >> only the generics (sRGB, etc) that have been defined for OS X. > > Is this a generic feature that allows arbitrary options to be passed > to ColorSync, or is it limited to a specific enumerated set? I wonder > if colord on Linux supports something similar. I think it’s tide to Ink and Media setting key words. It’s a cups/ppd thing. https://www.cups.org/doc/spec-ppd.html#cupsICCProfile <https://www.cups.org/doc/spec-ppd.html#cupsICCProfile> > > (Traditionally, one will set up multiple queues to the same backend > device, one for each setting combination, and associate a unique ICC > profile to each queue..) > > - Solomon > -- > Solomon Peachy pizza at shaftnet dot org > Coconut Creek, FL ^^ (email/xmpp) ^^ > Quidquid latine dictum sit, altum videtur. > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > Gimp-print-devel mailing list > Gim...@li... > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
|
From: <fo...@wa...> - 2018-02-23 21:47:09
Attachments:
signature.asc
|
Ok. Here is an example “macosx" folder with all the old stuff taken out using my own workflow (built out of makegutenpkg.sh). It works to build on High Sierra and it allows for more specific pkg options by using the very handy “Packages” app. macosx folder download: https://drive.google.com/open?id=1F1jabLXkbvuQcCxTdfjsOA4-N2eBeE4l <https://drive.google.com/open?id=1F1jabLXkbvuQcCxTdfjsOA4-N2eBeE4l> Delete the old macosx folder and place this in its place. The readme.txt will tell you what to do but here it is: Building Gutenprint for Mac. 1. Make sure you have a developers license with Apple. You need an Installer cert and an Application cert. Download xcode. 2. Download Packages here: http://s.sudre.free.fr/Software/Packages/about.html 3. By default this workflow will make a dmg using OS X's hdutil. On High Sierra this may not be backwards compatible. I suggest you use DropDMG if you find this to be the case. 4. You need a Linux box (I use vmware and Ubuntu). Download the source to Linux and run autogen.sh 5. Copy source to OSX. 6. In Terminal cd to source folder. 7. In Terminal type: sudo CODESIGN_IDENTITY="Developer ID Application: Firstname Lastname" && export SOURCE_PATH=/Path/To/SourceFolder && ./macosx/makegutenmac.sh 5.3 8. After everything has been built, open the macosx folder and then the package folder. Open the Gutenprint package template in Packages. 9. Change version #s, requirements, design, language translations, etc. Command-B for build. 11. In Terminal type: sudo export CODEINSTALLER_IDENTITY="Developer ID Installer: Firstname Lastname" && ./macosx/makedmg.sh 5.3 12. This will sign the pkg and copy it into a new folder called gutenprint-5.3. Then it will copy the doc files into the same folder and make a dmg out of it. The DMG can now be distributed. If you need to sign the DMG for even more security, use DropDMG and make a new dmg out of the "gutenprint-5.3" folder that is inside of the macosx folder. Notes: This will not build for 32bit processors. Only 64bit. This setup installs gutenprint into /Library/Printers/Gutenprint.bundle instead of into /Library/Printers/Gutenprint.printerdriver. This is for 5.3. You will need to change some things for 5.2.x I have not touched the dyesub stuff but can update the install script for that upon request. All the best and happy Friday, Walker > On Feb 23, 2018, at 12:41 PM, fo...@wa... wrote: > > > >> On Feb 23, 2018, at 11:10 AM, Solomon Peachy <pi...@sh... <mailto:pi...@sh...>> wrote: >> >> On Fri, Feb 16, 2018 at 11:59:02AM -0500, fo...@wa... <mailto:fo...@wa...> wrote: >>> There were some hiccups in getting all the binaries signed properly in >>> High Sierra but that has been accomplished. It’s rather straight >>> forward and I would be happy to make a write-up if you all want to >>> update the documentation on this. (Current documentation for OS X >>> packaging is not up to date). >> >> I'm assuming you have to sign it with a propr Apple Developer key? >> >> And I'm sure I speak for everyone here when I say that any documentation >> updates would be welcomed. :) > > I’ll do the write-up. > |
|
From: <fo...@wa...> - 2018-02-23 23:10:16
Attachments:
signature.asc
|
<edit> Step seven command should actually be: sudo export CODESIGN_IDENTITY="Developer ID Application: Firstname Lastname" && export SOURCE_PATH=/Path/To/SourceFolder && ./macosx/makegutenmac.sh 5.3 > On Feb 23, 2018, at 3:51 PM, fo...@wa... wrote: > > 7. In Terminal type: sudo CODESIGN_IDENTITY="Developer ID Application: Firstname Lastname" && export SOURCE_PATH=/Path/To/SourceFolder && ./macosx/makegutenmac.sh 5.3 |
|
From: <fo...@wa...> - 2018-02-23 21:54:39
Attachments:
signature.asc
|
Also, I did not modify the docs or install/uninstall commands. Those .commands should really be turned into signed apps IMO. It gets frustrating quickly when sec warnings show up and Mac users are not always super tech savvy. I use Platypus for this. https://www.sveinbjorn.org/platypus <https://www.sveinbjorn.org/platypus> Best, Walker > On Feb 23, 2018, at 3:51 PM, fo...@wa... wrote: > > Ok. Here is an example “macosx" folder with all the old stuff taken out using my own workflow (built out of makegutenpkg.sh). It works to build on High Sierra and it allows for more specific pkg options by using the very handy “Packages” app. > > macosx folder download: > https://drive.google.com/open?id=1F1jabLXkbvuQcCxTdfjsOA4-N2eBeE4l <https://drive.google.com/open?id=1F1jabLXkbvuQcCxTdfjsOA4-N2eBeE4l> > > Delete the old macosx folder and place this in its place. > > The readme.txt will tell you what to do but here it is: > > Building Gutenprint for Mac. > > 1. Make sure you have a developers license with Apple. You need an Installer cert and an Application cert. Download xcode. > 2. Download Packages here: http://s.sudre.free.fr/Software/Packages/about.html <http://s.sudre.free.fr/Software/Packages/about.html> > 3. By default this workflow will make a dmg using OS X's hdutil. On High Sierra this may not be backwards compatible. I suggest you use DropDMG if you find this to be the case. > 4. You need a Linux box (I use vmware and Ubuntu). Download the source to Linux and run autogen.sh > 5. Copy source to OSX. > 6. In Terminal cd to source folder. > 7. In Terminal type: sudo CODESIGN_IDENTITY="Developer ID Application: Firstname Lastname" && export SOURCE_PATH=/Path/To/SourceFolder && ./macosx/makegutenmac.sh 5.3 > 8. After everything has been built, open the macosx folder and then the package folder. Open the Gutenprint package template in Packages. > 9. Change version #s, requirements, design, language translations, etc. Command-B for build. > 11. In Terminal type: sudo export CODEINSTALLER_IDENTITY="Developer ID Installer: Firstname Lastname" && ./macosx/makedmg.sh 5.3 > 12. This will sign the pkg and copy it into a new folder called gutenprint-5.3. Then it will copy the doc files into the same folder and make a dmg out of it. The DMG can now be distributed. If you need to sign the DMG for even more security, use DropDMG and make a new dmg out of the "gutenprint-5.3" folder that is inside of the macosx folder. > > Notes: > > This will not build for 32bit processors. Only 64bit. > This setup installs gutenprint into /Library/Printers/Gutenprint.bundle instead of into /Library/Printers/Gutenprint.printerdriver. > This is for 5.3. You will need to change some things for 5.2.x > I have not touched the dyesub stuff but can update the install script for that upon request. > > All the best and happy Friday, > Walker > > >> On Feb 23, 2018, at 12:41 PM, fo...@wa... <mailto:fo...@wa...> wrote: >> >> >> >>> On Feb 23, 2018, at 11:10 AM, Solomon Peachy <pi...@sh... <mailto:pi...@sh...>> wrote: >>> >>> On Fri, Feb 16, 2018 at 11:59:02AM -0500, fo...@wa... <mailto:fo...@wa...> wrote: >>>> There were some hiccups in getting all the binaries signed properly in >>>> High Sierra but that has been accomplished. It’s rather straight >>>> forward and I would be happy to make a write-up if you all want to >>>> update the documentation on this. (Current documentation for OS X >>>> packaging is not up to date). >>> >>> I'm assuming you have to sign it with a propr Apple Developer key? >>> >>> And I'm sure I speak for everyone here when I say that any documentation >>> updates would be welcomed. :) >> >> I’ll do the write-up. >> > |
|
From: Matt B. <wal...@ma...> - 2018-02-24 03:21:33
Attachments:
signature.asc
|
> On Feb 23, 2018, at 3:05 PM, fo...@wa... wrote: > > Also, I did not modify the docs or install/uninstall commands. > > Those .commands should really be turned into signed apps IMO. It gets frustrating quickly when sec warnings show up and Mac users are not always super tech savvy. I use Platypus for this. https://www.sveinbjorn.org/platypus <https://www.sveinbjorn.org/platypus> > > Best, > Walker I heartily agree that the unintaller and the Gutenprint Utility for EPSON Inkjet Printers would be much better turning into signed apps. Security was much laxer when I wrote those. Matt -- Matt Broughton wal...@ma... |
|
From: Robert K. <rl...@al...> - 2018-02-24 01:35:53
|
On Fri, 23 Feb 2018 11:10:24 -0500, Solomon Peachy wrote: > On Fri, Feb 16, 2018 at 11:59:02AM -0500, fo...@wa... wrote: >> The only stumble that I have found to making vendor specific OS X >> variants is this: I have found NO way to have multiple variants of >> gutenprint in /usr/libexec/cups/driver. This is the part of the >> system that populates the list of available 'gutenprint printer >> drivers' when you go to sys prefs and then hit the + button and then >> calls the appropriate binary to make the ppd and install the printer. >> The only way to distribute a Gutenprint-derived independant driver is >> to pre-build the PPDs and place in >> >Library>Printers>PPDs>Contents>Resources>. That's the only sticking >> point that I see to this. > > Some of that is Gutenprint's fault; it's not intended to be > parallel-installable across point releases, and I think the "driver" > name is hardcoded to be 'gutenprint'. It may be worth looking into > allowing all executable names (and dependent data directories) to be > changed at compile-time. Perhaps a filename prefix not unlike how > gcc cross compilers are set up? Actually, the filter name is rastertogutenprint.M.m and the driver name is gutenprint.M.m. You can't have multiple point releases, but you can have multiple MAJOR.minor releases installed. >> The other thing that I think is do-able (OS X specific) is the ability >> to have ColorSync select an output ICC based on the Mediatype chosen. >> That said, none of that programming has been done in genppd.c There is >> only the generics (sRGB, etc) that have been defined for OS X. > > Is this a generic feature that allows arbitrary options to be passed > to ColorSync, or is it limited to a specific enumerated set? I wonder > if colord on Linux supports something similar. I can feel a PPD rant coming on... > (Traditionally, one will set up multiple queues to the same backend > device, one for each setting combination, and associate a unique ICC > profile to each queue..) -- Robert Krawitz <rl...@al...> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: <fo...@wa...> - 2018-02-24 01:40:04
Attachments:
signature.asc
|
PPD: Painful Printing Directives > On Feb 23, 2018, at 8:35 PM, Robert Krawitz <rl...@al...> wrote: > > I can feel a PPD rant coming on... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X