Re: [Gimp-user] [Gimp-print-devel] Adding support for CUPS command files

[Gene Heskett]

On Thursday 03 May 2018 08:31:51 Michael Sweet wrote:

> Robert,
>
> > On May 3, 2018, at 7:49 AM, Robert Krawitz  wrote:
> >
> > On Thu, 3 May 2018 06:34:10 -0400, Solomon Peachy wrote:
> >> On Wed, May 02, 2018 at 09:25:16PM -0400, Robert Krawitz wrote:
> >>> Isn't it the other way around -- higher end business-focused
> >>> printers offer IPP support, while lower-end, specialized, and
> >>> art-focused printers don't?
> >>
> >> These days, nearly every printer that comes with a network port
> >> will support IPP.  This is especially true of the higher-end
> >> business-focused stuff, which always supported "proper" PDLs like
> >> PS or PDF and, in the past decade or so, already sported a web
> >> server...
> >>
> >> On the consumer side, the mid-to-higher-end stuff all supports IPP,
> >> again anything with an ethernet port or wifi.
> >>
> >> Meanwhile, "low-end, specialized, and art-focused" describe our
> >> primary use cases.  :)
> >
> > Not to mention people who use printers as more general
> > chemical-deposition-on-a-substrate devices.
> >
> > Supporting IPP alone isn't enough to really simplify the printing
> > process; printers need to directly support common file formats (PDF
> > and JPEG in particular), because otherwise there still needs to be a
> > layer to perform the translation.
>
> You also need queuing (spooling), so unless every printer provides
> onboard storage having JPEG or PDF is not ultimate solution.  In
> practice, client-side rendering (even from a smartphone) is also
> significantly faster than onboard PDF support, so except for high-end
> MFPs that can sustain a true 25-30ppm doing the spooling and
> translation on the client is still the best architectural choice.
>
All this talk about 25-30ppm printers tells me you are referring to 
$1000+ printers, which are definitely out of reach for the average user.

My Brother B laser is the basic low ball model HL2140, sells for about 
$130 in its latest incarnation, doesn't do duplex without very carefuly 
managed  paper turnover and refeeds, more trouble than its worth.  But 
it does manage to do about 18-19 ppm.

My Brother MFC-J6920DW, which can do tabloid by hand feed, duplex from 
either tray in letter sized but is too picky about its photo paper.

Both are running on Brother supplied drivers, so while Gutenprint is 
fully installed on this old debian wheezy machine, but gutenprint from 
wheezy was last built in 2012, version 5.2 something.

The big printer is inkjet, and running a long job resembles watching 
paint dry, ppm ranges either side of 1 a minute. Interface is via 
ethernet mainly because the usb port is buried inside the machine, using 
about 30" of the maximum 60 inch usb cable. Whats left is not sufficient 
to reach any of my usb-2 hubs by around 4 feet.

The Brother MFC-J6920DW driver gives me all sorts of knobs to adjust the 
color and density in the config menu's cups shows me.  But on copy paper 
its very pastel at best. On photo paper which is not marked or side 
identified in any discernable way, it works great although slightly 
pastel yet as I'm still "tweeking", but change nothing but turn the 
paper over, and it looks like ink was poured straight out of a gallon 
bucket, puddling and running all over.

Can gutenprint improve on any of that?

In what way?

These are the types of printing problems typically encountered by those 
of us on SS and unable to afford the printers that you just feed the 
file to.

I have a home network of several machines running LinuxCNC, all of which 
can print to these printers, so this is effectively the print server, 
dishing out these 2 printers to the rest of my network.

Thank you for any helpfull suggestions. FWIW, the Brother MFC-J6920DW is 
touted to do several ppm. It doesn't try, even in simplex.

> The standard streaming raster formats (Apple and PWG Raster) are
> really what made it possible to get all regular printers to support
> IPP.  Those combined with a thin client-side spooler that handles
> generation of raster data is all you need, and is how printing is
> implemented on iOS.  In the future I also hope to make this the case
> for macOS, Linux, and others...
>
> >>> Copying Mike; I'd like to get his thoughts on this.  Hopefully
> >>> there would be a lot of common code that we could simply reuse.
> >>
> >> Given that CUPS is pretty much IPP at the edges anyway, IMO the
> >> path of least re-iplementation would be to us to fork CUPS and
> >> replace its PPD-centric internals with libgutenprint.  In a sense
> >> that's what CUPS/Apple had in mind with the recent ASL2.0
> >> relicensing.
> >
> > Well, this is exactly what CUPS itself is doing, and I don't want to
> > duplicate that work.  Hopefully CUPS will provide the tools needed
> > to implement the IPP server.
> >
> >> But speaking of licenses, that level of tight integration would
> >> likely be an issue.  Neither the ASL2.0 licensed current CUPS nor
> >> the GPLv2-only older CUPS 

Re: [Gimp-user] [Gimp-print-devel] Adding support for CUPS command files

[Gene Heskett]

On Wednesday 02 May 2018 08:14:11 Solomon Peachy wrote:

> On Wed, May 02, 2018 at 10:13:12AM +0200, Johannes Meixner wrote:
> > https://github.com/apple/cups/issues/5271
> > so that adding support for CUPS command files
> > seems to be a non future proof way.
>
> Relying on CUPS in any way is non-future-proof, because everything
> that doesn't relate to being an IPP *client* has been deprecated, with
> no intention of developing a replacement for any sort of
> locally-attached printer.
>
> Meanwhile, CUPS (and cups-filters and PPDs and everything else that
> CUPS has tossed or is tossing into the rubbish bin) remains the only
> way to get printers that lack IPP support (ie the overwhemling
> majority of what's out there, especially in the non-consumer-focused
> space) to act as anything other than expensive paperweights.
>
Damn!  I know Michael from way back in the late '80's, and when he sold 
himself to Apple, my alarm bells went off.  And it appears they were 
right. We are being microshafted.

> So there are only two viable long-term paths forward for folks like
> us:
>
>  * Fork CUPS when it finally drops the deprecated stuff and carry on
> as before.  Note that this has already happened, resulting in
> 'cups-filters'. * Develop a complete IPP server implementation that
> natively interfaces with libgutenprint (as opposed to the CUPS PPD
> API) This is a _huge_ undertaking that will require re-creating a
> sizeable chunk of what CUPS [used to] provide.  (eg job spooling,
> network daemon including a proper http server, image/PDL
> decode/conversion including things like N-up and manual copy and
> collation support, general option enumeration and parsing, and so
> forth..)
>
> As an aside, every proprietary OSX printer driver I've seen is in a
> similar predicament, because they are also entirely dependent on
> deprecated CUPS functionality.
>
> Meanwhile.  Fully implementating the CommandFile stuff in Gutenprint
> will yield several bits of internal plumbing that are necessary to
> provide proper IPP functionality:
>
>  * Reporting printer options (eg what hardware options are
>present, or what kind/quantity of media is loaded)
>  * Setting driver defaults based on printer options
>  * Reporting printer status (job status, errors, counter, etc)
>  * Invoking printer commands (eg self-test, cleaning, alignment..)
>
> Some of these things exist but in an ad-hoc manner (typically
> requiring use of external cmdline tools that don't integrate with
> anything else). Plus, simply implementing the first will yield
> immediate benefits with modern Linux desktop environments.

The latter seems like the only way foward. But do you have the people 
resources that will take? I have benefitted greatly from cups, so if you 
have to crowdfund the help, count on me for a small donation, I'm on SS, 
but that doesn't cancel TANSTAAFL.

>  - Solomon



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list