Re: [Gimp-print-devel] OSX support (Was Re: CITIZEN photo printers)

[Robert K. <rl...@al...>]

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