From: Solomon P. <pi...@sh...> - 2024-08-01 00:01:58
|
On Wed, Jul 31, 2024 at 03:00:03PM -0400, Michael Sweet wrote: > Perhaps to "fast track" this discussion, does this printer just use a > roll of media and cut it to the desired size? Yes, albeit with various limitations on the allowed sizes. (And then there are models that use discrete sheets. Nominally they are usually a "standard" size (PC, L, etc) but in reality pretty much _every_ printer family differs slightly on both the physical media size and the overbleed.) > If so, the best thing to do here is report min/max roll (custom) > sizes, with a selection of "standard" photo sizes (as currently) that > are imposed on the roll with pixel duplication at the edges to avoid > bleed issues. ...I'm not sure how this is supposed to work any better than what we have now? After all, it's all "custom" either way. Meanwhile, pixel duplication for overbleed inside gutenprint is insufficient, as that will all but guarantee that there will be a visible artifact on at least one edge of the print. To take the CX-02 for example, in a perfect ideal world the imageable area is 1.5mm-2mm larger than the physical paper size. Cutting the imageable area down to a perfect 4x6" @300dpi means we are, at best, 0.1mm shy of filling the paper competely on all four sides, and at worst (but still within spec) we could be over 2mm off on one or two sides. > From the outside, the printer supports printing on a roll and/or > printing to specific "standard" sizes. Gutenprint then handles any > scaling/imposition to the printer's internal buffer/roll format from > the raster data it gets from the print client/filters. It is a hard requirement that there *must* be a way to say "just print this image as supplied, with absolutely minimal processing" -- and part of that is "tell me what the ideal image dimensions need to be so I can supply an optimized pre-scaled/sharpened/etc image." Lying about the required image size and forcing an internal rescaling is completely unacceptable. (I understand that some, maybe even most use cases don't care about this, but improvements to _other_ use cases don't matter if the ones you do care about cease to work!) > Reporting non-standard sizes with standard names doesn't work on any > OS Except.. this entire discussion is about how Gutenprint _isn't_ using standard sizes, and why can't it just do that instead? > - macOS, for example, will report the odd sizes in the UI and any > CUPS-based client on Linux will likewise show odd dimensional names > and not the "localized" size names from the PPD file. That sounds like a significant functional regression in the UIs. > And regardless of whether the other platforms are open or > proprietary, they are using open standards to print and Gutenprint's > current usage is causing issues. Gutenprint's "current usage" is how it's been doing things for at least 17 years, when driverless IPP was just a pie-in-the-sky dream. (And if I'm not mistaken, *you* are the original author of Gutenprint's CUPS glue code. And much more..) Meanwhile. Let's suppose that everything you have said is 100% objectively true -- ie that Gutenprint's approach is fundamentally incompatible with TheWayThingsAreNowDone(tm), and large parts of it have to be rewritten and its overall scope greatly expanded... or what exactly? Because this really sounds like I'm being "asked" to volunteer myself for a solid 2-3 months of unpaid full time work to produce something that OtherPeople(tm) want. Then actively maintain, update, and support it indefinitely. For free. ...Screw that. Gutenprint is 100% Free Software (GPLv2+), provided AS-IS and WITHOUT ANY WARRANTY WHATSOEVER. And as the sayings go, "scratch your own itches" and "patches welcome". (BTW, it looks like Gutenprint has effectively been ghosted for a *third* year in a row by a GSoC-funded student. Why do I even try any more..) - Solomon -- Solomon Peachy pizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) |