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 

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&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