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

[Gene Heskett <gheskett shentel net>]

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

> Robert,
>
> > On May 3, 2018, at 7:49 AM, Robert Krawitz <rlk alum mit edu> 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&W 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 are directly compatible with Gutenprint's
> > > current GPLv2+ distribution.
> >
> > Well, GPL2+ is directly compatible with both GPL2 and Apache2.  The
> > problem occurs if GPL2 and Apache2 are mixed.  You might recall that
> > we went through the Gutenprint source and ensured that everything
> > was licensed GPL2+.
>
> That's good!
>
> (and we have some stuff in the works to address GPL2 compatibility,
> too...)
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer



-- 
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 <http://geneslinuxbox.net:6309/gene>