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

[Johannes M. <js...@su...>]

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)