gimp-print-devel Mailing List for Gutenprint - Top Quality Printer Drivers (Page 7)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Borrarme de este correo

On Thu, Aug 01, 2024 at 12:36:01PM -0400, Michael Sweet wrote:
> Actually, if it was a "cut media" option that is fairly well supported 
> these days and maps well to IPP...

Except... contemporary clients at the time didn't present the option.

> Third option: offer a 2x6 page size and merge pages in a job to the 4x6 media.

I've actually tried to go down variations of this path multiple times, 
but kept running into the fundamental problem that 98% of the time for 
photo printing, each image/page is submitted as an independent job. (ie 
unless you create a multi-page PDF and submit that) Which, the last time 
I checked, neither iOS or Android's printing functionality (&| their 
photo apps' use of said functionality) work that way.

So there's no way to do job combining (for the typical users) without 
creating some sort of daemon that sits around and waits after one job is 
"finished" for something else to show up before asynchronously sendng 
something to the printer.

Incidently, that's one of the things I was most excited about a Printer 
Application; intra-job state effectively comes along for free. There's 
actually a _lot_ of automagic page/job combining logic sitting unused in 
the backend right now.  Suffice it to say I'd _really_ like to have this 
capability...

Meanwhile, there's another wrinkle for things like ID cards printers, 
where each side of the card may require completely different parameters 
to the point of full CMYK on the front but only K the back (and K can be 
greyscale or 1bpp resin. oh, and different per side.  It all depends on 
the ribbon being used.  Which also may or may not have a lamination 
layer on either side)..  I don't know if that level ove 
each-page-has-different-properties is even expressible under IPP.

> That's not CUPS, that is GNOME, KDE, etc.

And more importantly, iOS, Android...

(Actually, Gnome, KDE, etc worked just fine.  Pretty sure they still do, 
 if you use local CUPS queues instead of the auto-discovered IPP stuff)

> Which functionality exists for these printers beyond the size of the 
> output and the number of copies? (orientation, scaling, etc. are all 
> handled by the client)

Just off the top of my head: Printer resolution, paper size and the 
number/position of cuts (which are nearly always a fixed set of 
enumerated combinations as opposed to being a finishing option on 
any/all print sizes) common finishing options (eg overcoat type and 
decurling), sharpening and color correction knobs, delay time for 
automatic job combining, quality/speed settings, etc.

Incidently, For whatever reason, scaling, etc *still don't* seamlessly 
work, based on the complaints I still get about white margins showing up 
on the sides of prints.  (that's slowly improved thanks to Till's work 
with cups-filters, but telling non-technically-inclined people they have 
to effectively recompile their environment's entire printing stack (or 
"use a different application to print your pictures") doesn't go over 
well...)

> It isn't reasonable to assume that a driver written for MacOS X 10.2 
> on PowerPC and *never* updated would continue to work on macOS 14 on 
> Intel/ARM some 22 years later, even if the printer it supports still 
> works.  

Oh I agree, except I'm not talking about a gap like that.  Instead it's 
tier-ones like Canon not providing drivers for anything more than a 
single MacOS release, outright refusing even to consider relase+1.

Incidently, I have one printer in my fleet that was introduced in *2003* 
and is _still_ actively supported (new media, firmware, and current 
Windows drivers) by its manufacturer.  But that's an outlier; typically 
these things have a product lifecycle a bit over a decade.

> But don't try to blame Apple for printer vendors failing to support 
> their products

I'm sorry, but Apple absolutely carries at least part of the blame here, 
and I say that as someeone who has been involved with trying to provide 
MacOS printer drivers.  Nearly *every* MacOS release for the better part 
of a decade broke something Gutenprint depended on, becoming a release 
blocker.  (That's why Gutenprint hasn't generated a new formal release 
since *2019*.  It would be one thing if we derived actual *revenue* from 
MacOS and used that to pay folks to do this work, but that's not how 
this works)

> printer vendors have historically used terrible software engineering 
> practices (no version control/code repositories, no way to re-build 
> their software, etc.) 

I'm all too familiar with this, unfortunately.

> and *that* combined with a lack of incentive to support products 
> beyond their release is the reason for broken drivers, NOT changes 
> made by Apple.

Not *solely*, perhaps.  But when those same printer manufacturers 
release drivers for newer versions of Windows, but not MacOS.. as the 
saying goes, where there's smoke, there's probably fire.

And when you consider these printers require use of 
printer/model-specific media (ie ribbon+paper) and that's where the real 
money lies.  The easier it is for folks to make prints, the more they 
will print, the more media you will sell, and the more money you make.  

Of course, that doesn't mean the printer manufacturer won't shooot 
themselves in the foot. To beat up on Canon again, their latest SELPHY 
CP printers use the same media kits as the first model they ever 
produced over two decades ago.  There have been only two hardware 
generations (each with its own PDL and communication) in that whole 
time, yet for some reason they insist on each individual model requiring 
a unique driver... which they almost never update or support after the 
initial release.

> The biggest "breakage" events were when PPC emulation was removed 
> (10.6) and when code signing became required (10.14).

That 10.6 period largely coresponds with my increasing involvedment with 
Gutenprint, and 10.13 or 10.14 was when our support effectively ended.

> I'm not at Apple anymore but they don't seem to be changing anything 
> meaningful in the printing stack on macOS...

FWIW it usually wasn't the "printing stack" that broke us, but something 
_else_ in the OS.

> One of my goals has been to support/develop/mentor a Gutenprint 
> printer application based on PAPPL. That would give you your 
> command-line RIP *and* instant support for all of the IPP-based 
> clients.

Till and I are on our third consecutive GSoC attempt to make this 
happen. But there's a wide gap between "willing to help/support/mentor" 
and "doing it myself."  But more on that in a bit.

> *I* am *not* trying to put this all on your shoulders, and I also 
> totally understand that supporting Gutenprint (or any printing 
> software) is a mostly thankless task... 

To put it mildly.

As you can probably tell from these emails, I only ever had an interest 
in the low-level printer interaction sort of stuff. Other than reworking 
my talk-to-the-printer code to be usable as a CUPS backend, Everything 
else higher in the well-layered stack (largely including the rest of 
Gutenprint) was SomeoneElse'sProblem(tm).  And that worked fine for a 
long time, becuse there were OtherPeople maintaining those parts of the 
overall system.

Except those OtherPeople have all left or otherwise abandoned the rest 
of the stack -- heck, the entire printing _system_ -- I simply don't 
have the personal bandwidth to tackle everything. Or much of anything.

To quote Ben Horowitz [1]:

  "There are no silver bullets for this, only lead bullets."  

Every path forward requires competent developers to (a) carefully write 
a decent pile of very domain-specific code, and (b) support/maintain it 
going forward.

And unless someone wants to throw a pile of money my way [2], that 
person wont't be me.

..And while (a) might represent 90% of the overall effort, (b) 
represents the second 90%.  (as demonstrated by the initial context of 
this email)

> But I *do* want to have a discussion to understand the issues 
> surrounding supporting certain printers so that a) I can advocate for 
> those kinds of printers in the Printer Working Group, b) I can make 
> sure that PAPPL supports what is needed for those printers, and c) I 
> can eventually help make Gutenprint available as a printer 
> application.

I'll tackle these in reverse order.

(c) PAPPL makes a hell of a difference, of course, and for minimal 
"Print office documents on USB-print-class-compliant PCL/inkjet 
printers" it should't be _that_ much effort. (Basically everything but 
the dyesubs) This is the scope of the recurring GSoC efforts.  Assuming 
that succeeds this third time, here are two major followup prongs:

 * Figure out how to make available the approximately one gajillion 
   knobs for tuning the printer output (especially for Epson inkjets) 
   You've already said they can't be directly exported due to IPP client 
   limitations, so maybe this can be done using some sort of 
   configurable profile mechanism.  Which has to be created, along with 
   suitable UI, etc etc.

 * Figure out how to adapt/integrate the gutenprint USB dyesub backend's 
   functionality in a way that doesn't result in a hard fork and 
   wholesale duplication of code. Aside from basic communications, this 
   includes job combining and splitting, various processing functions 
   that couldn't be done within gutenprint (due to layering or licensing 
   considerations), media/status reporting, configuring nonvolatile 
   printer options, and even firmware updates for one printer family.

Anything beyond the minimal GSoC scope is almost guaranteed to require 
creating new libgutenprint (and libgutenprintui) APIs, likely 
significant frontend work within PAPPL's UI, plus heavy modifications of 
the dyesub code within core gutenprint and its external (>33KLoC!) 
backend (which in turn also likely requires mucking with PAPPL)

...All this before anything _new_ is added beyond the current feature set.

(Which reminds me -- I _still don't have an answer on what we should be 
 doing with respect to the original complaint that led to this thread; 
 ie "the printer accurately reports that it uses custom sizes, and 
 lying/pretending otherwise will require fundamental alterations to how 
 it works with sizes internally, plus rescaling/padding/cropping what 
 the user supplied.")

(b) I touched on sone of this above, but ultimately the only way we're 
going to know what else PAPPL needs is to (heh) FAFO.  This is what I 
was referring to with my "lead bullets" remarks -- it's going to take a 
lot of work, and I'd hoped the GSoC stuff would start that rolling.

(a) When I was first introduced to Java, and someone described it as 
"making hard things easy and easy things hard."  That seems to apply to 
IPP as well.  

FWIW, I don't speak for anyone other than myself (based in part on 
conversations and general industry exposure over the years)

First, these aren't "printers" so much as "industrial equipment", 
deployed as part of some larger system that produces something that is 
will be sold for money.

As such, this class of printers is only rarely "shared" over a network.  
Printing is nearly exclusively using direct connections from a custom 
application running on the local system. More often than not, the 
OS-level printer stack is bypassed competely.

From that perspective, IPP is completely superfluous.  Both because the 
functionality it offers is unnecessary (least of which being that all 
printing is local) and because even in a best-case scenario, it adds a 
_lot_ of overhead that just slows things down.  (In this general market, 
time-to-print and prints-per-hour (with each print typically being a 
separate self-contained job!) numbers can matter even more than the 
incremental price-per-print)

For situations when these printers need to be made available to generic 
applications, they provide standard OS drivers.  And if the printer 
needs to be exported over the network, the OS can handle that.  Why 
reimpement the wheel and drive product complexity & cost upwards when it 
won't be of use to the majority of the suer base?

Meanwhile, these are printers that have production lifecycles that 
routinely exceed a decade, and are supported well beyond that.  IPP has 
iterated so rapidly (and the reality of having a network-facing device) 
is such that it makes sense for an industrial printer maker to 
completely decouple this functionality.

Now the makers know that there are other markets for these printers, and 
those markets may require driver-less network printing support. This was 
traditionally handled using a "hot folder" sort of arrangement (ie you 
upload files to a network share) running on some sort of server (these 
days typically Linux+SAMBA) which prints them out based on 
pre-configured settings) but more recently, AirPrint etc has allowed 
them to support mobile-centric clients (usually thanks to CUPS).

So while they care about IPP, it is not because of any inherent 
superiority of IPP, but because that's what it takes to support 
AirPrint.  Even with AirPrint+IPP, everyone seems to heavily push their 
own dedicated apps that give the user a richer experience (more control 
knobs, better status reporting, and I'm sure all sorts of data 
collection and tie-ins with various cloudy services).  I have no idea if 
these apps also use IPP under the hood (I know Canon's doesn't!), but 
years ago I was told that the first version the app to one 
manufacturer's print server was motivated by standard iOS printing not 
supporting/exposing some critical feature. (In hindsight it was probably 
the ability to configure the printer to generate 2x6" strips instead of 
a single 4x6")

ANYWay. To loop back to the beginning, IPP lets folks do all sorts of 
complicated things relatively easily, but it makes "simple" things a lot 
harder because the simple things have to be handled the same way as the 
complicated things. So when all you care about are those "simple" things 
(because you already have elaborate business-specific 
software/infrastructure to take care of the complicated stuff) it 
becomes an easy "all cost, but no benefit" decision to make.

Where they do care about IPP in of itself, it is because they are 
selling additional products (or services) that build on top of the 
actual printers.  The stuff on top iterates rapidly (one maker I'm 
familar with has gone through at least four major hardware revisions and 
even more software revisions of their "print server" sice 2015) but the 
actual printers do not.  (their _newest_ model was releasd in 2020 and 
the oldest still-in-production model was introduced in 2011, only 
because they had to cease prouction of a model introduced in 2007 due to 
COVID supply chain issues, and it remains in active support to this day)

 [1] https://a16z.com/lead-bullets/
 [2] ie enough for me to quit my never-had-anything-to-do-with-printing
     $dayjob.  Which I am _really_ happy at, btw.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

> On Aug 2, 2024, at 4:48 AM, in...@ju... wrote:
> 
> Hi there,
>  
> I wonder if you have a driver available for HP DesignJet 510 CH336 for Mac OS 14?

Unfortunately, The DesignJet is not supported by the Gutenprint drivers.

Matt

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Helvetica;
	panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Aptos;
	panose-1:2 11 0 4 2 2 2 2 2 4;}
@font-face
	{font-family:"Avenir Next Condensed";
	panose-1:2 11 5 6 2 2 2 2 2 4;}
@font-face
	{font-family:"Avenir Next Condensed Demi Bold";
	panose-1:2 11 7 6 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	font-size:11.0pt;
	font-family:"Aptos",sans-serif;
	mso-ligatures:standardcontextual;
	mso-fareast-language:EN-US;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Aptos",sans-serif;
	color:windowtext;}
MsoChpDefault
	{mso-style-type:export-only;
	font-size:11.0pt;
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style></head><body lang=EN-GB link="#467886" vlink="#96607D" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi there,<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>I wonder if you have a driver available for HP DesignJet 510 CH336 for Mac OS 14?<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Many thanks,<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Leon<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><p class=MsoNormal><a href="http://www.juicegraphics.co.uk/"><span style='color:windowtext;text-decoration:none'><img border=0 width=616 height=231 style='width:6.4166in;height:2.4062in' id="Picture_x0020_4" src="cid:image001.png@01DAE4C9.7F82D110" alt="signature_285000956"></span></a><span style='mso-ligatures:none'><o:p></o:p></span></p></div><p class=MsoNormal><span style='mso-ligatures:none'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><b><span style='font-size:18.0pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:#FF40FF;mso-ligatures:none;mso-fareast-language:EN-GB'>OPENING TIMES</span></b><b><span style='font-size:9.0pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><br></span></b><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'>Monday:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;9.00am to 5.00pm<br>Tuesday:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 9.00am to 5.00pm<br>Wednesday: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 9.00am to 12.00pm<br>Thursday:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 9.00am to 5.00pm<br>Friday:&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 9.00am to 5.00pm<br>Saturday:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 9.00am to 12.00pm<br><br>Please note: <o:p></o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'>We are closed Bank&nbsp;Holiday Weekends which includes the Saturday.<o:p></o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'>There may be times where we will need to close 15mins earlier so that we can take deliveries.<o:p></o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-fareast-language:EN-GB'><img border=0 width=607 height=102 style='width:6.3229in;height:1.0625in' id="Picture_x0020_3" src="cid:image002.png@01DAE4C9.7F82D110" alt="signature_1374648201"><span style='mso-ligatures:none'><o:p></o:p></span></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></b></p><p class=MsoNormal><b><span style='font-size:16.0pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:#3B7D23;mso-ligatures:none;mso-fareast-language:EN-GB'>Please consider leaving us a review on our Trustpilot site…<o:p></o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></b></p><p class=MsoNormal><a href="https://uk.trustpilot.com/review/juicegraphics.co.uk"><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-fareast-language:EN-GB;text-decoration:none'><img border=0 width=605 height=148 style='width:6.302in;height:1.5416in' id="Picture_x0020_2" src="cid:image003.png@01DAE4C9.7F82D110" alt="signature_3977238747"></span></b></a><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p></o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:Helvetica;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></b></p><p class=MsoNormal><span style='mso-ligatures:none'><img border=0 width=618 height=7 style='width:6.4375in;height:.0729in' id="Picture_x0020_1" src="cid:image004.png@01DAE4C9.7F82D110" alt="signature_1839912480"><o:p></o:p></span></p><p class=MsoNormal><span style='mso-ligatures:none'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><b><span style='font-size:9.0pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none'>Please consider the environment when&nbsp;printing this email.</span></b><span style='font-size:9.0pt;font-family:"Avenir Next Condensed",sans-serif;color:black;mso-ligatures:none'><br>&nbsp;<br>This email (including any attachments) is&nbsp;meant only for the intended recipient.<br>It may also contain confidential and&nbsp;privileged information.<br>If you are not the intended recipient, any&nbsp;reliance on, use, disclosure, distribution&nbsp;or copying of this email or attachments is&nbsp;prohibited.&nbsp;<br>Please notify the sender immediately by&nbsp;email if you have received this message&nbsp;by mistake and delete the email and all&nbsp;attachments.&nbsp;<br>Any views or opinions in this email are&nbsp;solely those of the author and do not&nbsp;necessarily represent those of Juice&nbsp;Graphics UK. Juice Graphics UK accepts&nbsp;no liability for the content of this email, or&nbsp;for the consequences of any actions&nbsp;taken on the basis of&nbsp;the information&nbsp;provided, unless that information is&nbsp;subsequently confirmed in writing.<br><br>Although every reasonable effort is made&nbsp;to keep its network free from viruses,&nbsp;Juice Graphics UK accepts no liability for&nbsp;any virus transmitted by this email or any&nbsp;attachments and the recipient should use&nbsp;up-to-date virus checking software.<br><br>Email to or from this address may be&nbsp;subject to interception or monitoring for&nbsp;operational reasons or for lawful&nbsp;business practices.</span><o:p></o:p></p></div></body></html>
Solomon,

> On Aug 1, 2024, at 10:37 AM, Solomon Peachy <pi...@sh...> wrote:
> ...
> This userbase (notably including myself) don't care about application 
> print dialogs or cross-OS support; they have an image generated by some 
> pre-existing pipleine, and they want it to programmically come out a 
> given printer (which may or may not be directly attached) with a given 
> set of near-arbitrary options.
> 
> This is the _only_ use case I've ever cared about.

That's where *I* started with the Gimp-Print plugin all those years ago...

> ...
>> Except.. this entire discussion is about how Gutenprint _isn't_ using 
>> standard sizes, and why can't it just do that instead?
> 
> More backstory here -- Let's take the CX-02 again.  The overwhelmingly 
> common use cases for this class of printers are drugstore-type photo 
> kiosks and photobooths, producing "standard" 4x6inch and a pair of 2x6" 
> strips respectively.
> 
> From the printer's perspective, both are *completely* identical.. except 
> the latter has one extra cut applied.  How do we present this option to 
> the user?  There were two approaches:
> 
> * Single PageSize (eg 4x6inch) with an additional, nonstandard/custom 
>   "cut in half" option that (a) many UIs don't display or support, (b) 
>   only works with some sizes, (c) no usable way to present feedback to 
>   the user about what combinations are valid.  (fun fact: I actually 
>   implemented code that emitted PPD UIConstraints, and you told me to 
>   not bother because what few clients implemented it were hopelessly 
>   broken)

Actually, if it was a "cut media" option that is fairly well supported these days and maps well to IPP...

>    - OR -
> 
> * Do what every printer maker's official Windows (and MacOS) drivers do 
>   and present them as two distinct PageSizes (eg 4x6inch and 2x6*2) for 
>   the user to choose between.

Third option: offer a 2x6 page size and merge pages in a job to the 4x6 media.

> Naturally, I did the latter, and it worked just fine... until AirPrint.  

The changes you speak of happened for CUPS 1.4, which was released in 2009 (16 years ago...)

> Or more accurately, CUPS moving to an IPP-first model, which combined to:
> 
> * "helpfully" deduplicate "media" with the same physical dimensions 
>    even if it had different identifiers.
> * Not presenting _any_ options other than the basic "size, color, 
>   orientation, duplexing, copies" needed for typical office printing 
>   tasks.

That's not CUPS, that is GNOME, KDE, etc.

> ...
> If there's a better way to do this, I'd love to hear it. But any 
> approach has to work with existing deployed print clients *today*.
> 
> Again, any "solution" that doesn't support required functionality is an 
> complete non-starter -- Printing Is Revenue. It Has To Work, Now.

Which functionality exists for these printers beyond the size of the output and the number of copies?

(orientation, scaling, etc. are all handled by the client)

> ...
> Ironically, it's not the commercial dyesub printing niche that generates 
> the support burden.  Instead, that has historically come from MacOS 
> users whose consumer-grade printers were abandoned by their makers 
> (helped along by Apple's near-constant breaking things printer drivers 
> relied upon).

It isn't reasonable to assume that a driver written for MacOS X 10.2 on PowerPC and *never* updated would continue to work on macOS 14 on Intel/ARM some 22 years later, even if the printer it supports still works.  Obviously if you still have the same hardware/OS, it will continue to work.  But don't try to blame Apple for printer vendors failing to support their products - printer vendors have historically used terrible software engineering practices (no version control/code repositories, no way to re-build their software, etc.) and *that* combined with a lack of incentive to support products beyond their release is the reason for broken drivers, NOT changes made by Apple.

During my tenure at Apple we bent over backwards to preserve driver compatibility. Sometimes that meant shipping old shared libraries that drivers were using (but shouldn't have been), or including code translation support (PPC to Intel, Intel to ARM), or leaving holes in the sandbox/security profiles for specific drivers until they could be updated.  The biggest "breakage" events were when PPC emulation was removed (10.6) and when code signing became required (10.14).  I'm not at Apple anymore but they don't seem to be changing anything meaningful in the printing stack on macOS...

> ...
> In the end, it looks like I will go back to where this started for me; 
> ie a command-line-based RIP for direct-attached dye-sublimation 
> printers, and I'll release under a copyleft license in the hope that 
> other folks find it useful.

One of my goals has been to support/develop/mentor a Gutenprint printer application based on PAPPL. That would give you your command-line RIP *and* instant support for all of the IPP-based clients.

*I* am *not* trying to put this all on your shoulders, and I also totally understand that supporting Gutenprint (or any printing software) is a mostly thankless task...  But I *do* want to have a discussion to understand the issues surrounding supporting certain printers so that a) I can advocate for those kinds of printers in the Printer Working Group, b) I can make sure that PAPPL supports what is needed for those printers, and c) I can eventually help make Gutenprint available as a printer application.

________________________
Michael Sweet

On Wed, Jul 31, 2024 at 08:01:45PM -0400, Solomon Peachy via Gimp-print-devel wrote:
> (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!)

I've been trying to understand just why this silly and mostly pointless 
email exchange has aggivated me so much.

The short version is that I never actually _cared_ about general 
purporse printing.  My personal use cases consist nearly entirely of 
command-line RIP-type stuff.  Along those lines, the only 
current/classic CUPS functionality I care about is a generic mechanism 
to enumerate and specify options.

I got into this space when I ended up with a printer that didn't do what 
it said on the box (ie "print images from memory cards").  The 
officially supported vendor drivers (under MacOS and Windows) were utter 
crap, a trait also shared by what appeared to be pretty much everything 
in the market.  Heck, this is _still_ largely the case.

So I decided to do something about this so I could use this printer 
natively under Linux, in the vein of Top Gear's "How hard can it really 
be?" quip.  Armed with Gutenprint's support for older models in the 
family, I rolled up my sleeves and figured out that (1) the printer used 
a different command language than its older siblings, (2) Gutenprint 
makes it pretty easy to add new printers into, and (3) this printer 
didnt't follow USB Printer class specs so the existing CUPS UPS backend 
didn't work.

Two days after I started, I had something that worked well enough for my 
immediate need -- printing arbitrary images from Gutenprint's GIMP 
plugin.

Since then I basically become the "dye sublimation printer guy". Over 
the years what I wrote grew into the all-singing CUPS backend it is 
today, supporting something like 150 distinct models from pretty much 
every manufacturer.  Between the backend and Gutenprint, *every* printer 
feature is supported, and thanks to how CUPS exposes options, you didn't 
have to resort to proprietary per-manufacturer (and often per-printer) 
SDKs to get exactly what you wanted: Consistent looking prints no matter 
which printer you were using.

This userbase (notably including myself) don't care about application 
print dialogs or cross-OS support; they have an image generated by some 
pre-existing pipleine, and they want it to programmically come out a 
given printer (which may or may not be directly attached) with a given 
set of near-arbitrary options.

This is the _only_ use case I've ever cared about.

But thanks to CUPS, my work was automagically applicable to other use 
cases -- Indeed, most of the time, Gutenprint+CUPS worked _better_ than 
the manufacturer's official drivers (and/or SDKs) for $other_os.

> Except.. this entire discussion is about how Gutenprint _isn't_ using 
> standard sizes, and why can't it just do that instead?

More backstory here -- Let's take the CX-02 again.  The overwhelmingly 
common use cases for this class of printers are drugstore-type photo 
kiosks and photobooths, producing "standard" 4x6inch and a pair of 2x6" 
strips respectively.

From the printer's perspective, both are *completely* identical.. except 
the latter has one extra cut applied.  How do we present this option to 
the user?  There were two approaches:

 * Single PageSize (eg 4x6inch) with an additional, nonstandard/custom 
   "cut in half" option that (a) many UIs don't display or support, (b) 
   only works with some sizes, (c) no usable way to present feedback to 
   the user about what combinations are valid.  (fun fact: I actually 
   implemented code that emitted PPD UIConstraints, and you told me to 
   not bother because what few clients implemented it were hopelessly 
   broken)

    - OR -

 * Do what every printer maker's official Windows (and MacOS) drivers do 
   and present them as two distinct PageSizes (eg 4x6inch and 2x6*2) for 
   the user to choose between.

Naturally, I did the latter, and it worked just fine... until AirPrint.  
Or more accurately, CUPS moving to an IPP-first model, which combined to:

 * "helpfully" deduplicate "media" with the same physical dimensions 
    even if it had different identifiers.
 * Not presenting _any_ options other than the basic "size, color, 
   orientation, duplexing, copies" needed for typical office printing 
   tasks.

In other words, it became effectively _impossible_ to simultaneously 
support the two overwhelmingly predominant use cases for dyesub 
printers.  A common workaround was to create multiple printer queues, 
each limited to a single print size.  This approach scales very poorly 
due to exponential numbers of option combinations.

After being pestered about this for some time, I came up with a hack -- 
Each same-physical-size-but-different-cuts variations got bumped up by 
one point.  Native CUPS/PPD didn't care, AirPrint+CUPS was happy, and 
being full bleed printers anyway, Gutenprint could just drop the extra/ 
superfluous data.

If there's a better way to do this, I'd love to hear it. But any 
approach has to work with existing deployed print clients *today*.

Again, any "solution" that doesn't support required functionality is an 
complete non-starter -- Printing Is Revenue. It Has To Work, Now.

> That sounds like a significant functional regression in the UIs.

I don't know when this happened, but what's one more UI/UX setback at 
this point?

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

...For the record I actually agree.  But that agreement doesn't 
magically make time and resources magically appear.

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

This is the crux of the matter.  Above, I wrote about why I got into 
this printing space to begin with, and what my personal use cases 
(still) are.  All of this IPP (and for the most part, even CUPS) stuff 
is at best tangental, yet it is responsible for nearly all of my headaches.

Ironically, it's not the commercial dyesub printing niche that generates 
the support burden.  Instead, that has historically come from MacOS 
users whose consumer-grade printers were abandoned by their makers 
(helped along by Apple's near-constant breaking things printer drivers 
relied upon).

Then it was heavily supplemented by iPhone/Airprint users. And Android 
users. and now, Windows users.  All of these are on the long tail ends 
of _very_ complex (and nearly entirely proprietary) software stacks that 
I have nearly zero influence over or visibility into.  Bug reports are 
little better than "printing doesn't work properly".  Indeed, the only 
piece I have _any_ visibility into or meaningful control over is 
Gutenprint, a thin sliver crushed at very bottom of that heap.

I got into this printing space to get away from dealing with those 
complicated (and proprietary) stacks that only served to get in the way of 
what I wanted to do.  If anything, it seems like the new status quo is 
actually _worse_.

There are of course significant advantages/benefits for a native IPP 
frontend to Gutneprint (combined with a great deal of internal 
restructuring and new development to take advantage of the new 
possibilities).  But those benefits nearly entirely accrue to *other 
people*.  Meanwhile, the *costs* of making all of that happen fall 
nearly entirely on... me, if only beacause I didn't have the good sense 
to formally walk away sooner.

Not only that, but as best as I can tell, for my use cases, the end 
result is actually functionally _worse_ thanks to the harsh reality of 
crappy IPP clients and the increase in overall system and runtime 
complexity.  

In the end, it looks like I will go back to where this started for me; 
ie a command-line-based RIP for direct-attached dye-sublimation 
printers, and I'll release under a copyleft license in the hope that 
other folks find it useful. 

Heck, that's effectively what I've been doing all along anyway.

> 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".

Faced with high costs and negligible (if not outright negative) personal 
benefits, how can the rational conclusion be anything other than "Let 
the people who want this functionality do the siginficant work to make 
it happen."

(To your immense credit, IPP Everywhere is... everywhere! Seriously, 
 that's an amazing accomplishment.)

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

Thank you!

On Wed, 31 Jul 2024 20:05:33 -0400
Solomon Peachy <pi...@sh...> wrote:

> On Wed, Jul 31, 2024 at 06:03:46PM -0400, Bacon At Taha wrote:
> > Are dimensions for all printers specified in points, or does that
> > vary across printers?  
> 
> Points are the unit of measurement for Postscript so that's what PPDs 
> still use.  Beyond that, printers typically represent dimensions via 
> whatever mechanism the operating system (or page definition langauge) 
> requires.  One printer I own natively uses pixels per meter, which
> IIRC is a Windows Bitmap thing.
> 
>  - Solomon

On Wed, Jul 31, 2024 at 06:03:46PM -0400, Bacon At Taha wrote:
> Are dimensions for all printers specified in points, or does that vary 
> across printers?

Points are the unit of measurement for Postscript so that's what PPDs 
still use.  Beyond that, printers typically represent dimensions via 
whatever mechanism the operating system (or page definition langauge) 
requires.  One printer I own natively uses pixels per meter, which IIRC 
is a Windows Bitmap thing.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

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)

Thank you Michael, that is helpful.
Sent from my iPhone

> On Jul 31, 2024, at 18:14, Michael Sweet via Gimp-print-devel <gim...@li...> wrote:
> 
> PPD files use points for all printers... Not sure what the internal units are for Gutenprint...
> 
> 
>> On Jul 31, 2024, at 6:03 PM, Bacon At Taha <ba...@ta...> wrote:
>> 
>> Are dimensions for all printers specified in points, or does that vary across printers?
>> 
>> Thanks,
>> 
>> Erik
>> Sent from my iPhone
>> 
>>>> On Jul 31, 2024, at 13:06, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
>>> 
>>> On Wed, Jul 31, 2024 at 06:13:11PM +0300, ValdikSS wrote:
>>>> I'd expect 3.5x5 PageSize to contain "252 360" value instead of "261.120
>>>> 460.800".
>>>> If I modify .ppd file with the values calculated by multiplying inches by
>>>> 72, CUPS starts to report these values as an IPP-defined media sizes.
>>> 
>>> Again, this printer does not support "standard paper sizes" -- it _only_
>>> uses printer-specific rolls of media.
>>> 
>>> It reports as 251.120 because *that is the actual dimension the
>>> printer needs*
>>> 
>>> If we report it as something smaller, then CUPS will hand us a raster
>>> image that is smaller than the printer needs, and that will make users
>>> very unhappy.
>>> 
>>>> Michael Sweet, the developer of CUPS, told to report this as a bug to you:
>>>> https://github.com/OpenPrinting/cups/issues/1017#issuecomment-2259205981
>>>> 
>>>> Also I'm not sure why there are same PageSize values used for different page
>>>> sizes, for example:
>>>> 
>>>> *PageSize w243h432/3.375x6:    "<</PageSize[297.600 460.800]/ImagingBBox
>>>> null>>setpagedevice"
>>>> *PageSize w270h432/3.75x6:    "<</PageSize[297.600 460.800]/ImagingBBox
>>>> null>>setpagedevice"
>>>> *PageSize w288h432/4x6:    "<</PageSize[297.600 460.800]/ImagingBBox
>>>> null>>setpagedevice"
>>> 
>>> Except it's _not_ the same PageSize; they have different identifiers.  
>>> Additionally, the ImageableAreas corresponding to those identifiers are
>>> different.
>>> 
>>> But... so what?  Even if the parameters were 100% identical, they are
>>> uniquely named, and those unique names are what clients are supposed to
>>> use to disambiguate things.
>>> 
>>>> I see. Should PageSize/PaperDimension use extended values in this case?
>>>> Isn't that controlled by ImageableArea?
>>> 
>>> I would think ImageableArea is more important than PageSize in this
>>> context, yes.
>>> 
>>>> Check the link above: instead of reporting e.g. na_index-4x6_4x6in, CUPS
>>>> reporting custom_117.35x162.56mm_117.35x162.56mm
>>> 
>>> That's because from the printer's perspective, it's physicaly larger
>>> than a "true" 4x6in print.
>>> 
>>> It is my understanding that the ImageableArea must be entirely contained
>>> within the PageSize.  Given that we need an ImageableArea physically
>>> larger than a "true" 4x6in print... that means we can't claim to be 4x6.
>>> So we don't.
>>> 
>>> ...Putting aside the less-than-ideal name, does it actually _work_ and
>>> print as expected?
>>> 
>>> Because this appears to be purely a cosmetic issue, brought on by how
>>> CUPS auto-translates PPD PageSize+ImageableArea into IPP's
>>> media+media-col equivalents.
>>> 
>>> A native IPP gutenprint print application would presumably be able to do
>>> better here; however at the end of the day the CX-02 (and other printers
>>> of its general class) do not use "standard" paper sizes, and I don't
>>> know what the implications could be if we report the "nominal" media
>>> name while correcting/supplenting the specifics in other attributes.
>>> 
>>> Based on my direct experience with IPP, if you're not using "standard
>>> office-type" paper sizes then for a realistic chance of success, you're
>>> probably going to have to use a vendor "app" to do the printing instead
>>> of "standard" IPP -- and that's using _native_ IPP printers, taking
>>> gutenprint + CUPS out of the loop entirely!
>>> 
>>> (As an aside, it is both faster and more reliable to print to my Brother
>>> Laser printer via IPP->CUPS->Gutenprint->JetDirect than it is to use the
>>> printer's native driverless IPP functionality.  Even from an iPhone!)
>>> 
>>> This new IPP world is two orders of magnitude more complicated, and I'm
>>> just one person working on this stuff on a (very) part time,
>>> entirely-out-of-pocket basis.
>>> 
>>>> The clients are Windows 10/11, Android 10 (check the link for more info).
>>> 
>>> At the end of the day I simply *do not care one iota* for supporting or
>>> resolving printing problems on proprietary platforms or operating
>>> systems.  If those platform owners (and printer manufacturers!) care,
>>> then they can do (and/or properly fund) this work themselves.
>>> 
>>> I'm <this> close to saying "eff this BS" and walking away entirely,
>>> because it's at the point where replacing fence posts while having my
>>> blood rapidly drained by swarms of mosquitos a moderate drizzle is more
>>> personally rewarding than continuing to deal with trying to keep
>>> printing working.
>>> 
>>> (Apologies for the rant, but ..... )
>>> 
>>> - Solomon
>>> --
>>> Solomon Peachy                  pizza at shaftnet dot org (email&xmpp)
>>>                                    @pizza:shaftnet dot org   (matrix)
>>> Dowling Park, FL                      speachy (libera.chat)
>>> _______________________________________________
>>> Gimp-print-devel mailing list
>>> Gim...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>>> <signature.asc>
>> 
>> 
>> _______________________________________________
>> Gimp-print-devel mailing list
>> Gim...@li...
>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> 
> ________________________
> Michael Sweet
> 
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

PPD files use points for all printers... Not sure what the internal units are for Gutenprint...

> On Jul 31, 2024, at 6:03 PM, Bacon At Taha <ba...@ta...> wrote:
> 
> Are dimensions for all printers specified in points, or does that vary across printers?
> 
> Thanks,
> 
> Erik
> Sent from my iPhone
> 
>> On Jul 31, 2024, at 13:06, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
>> 
>> On Wed, Jul 31, 2024 at 06:13:11PM +0300, ValdikSS wrote:
>>> I'd expect 3.5x5 PageSize to contain "252 360" value instead of "261.120
>>> 460.800".
>>> If I modify .ppd file with the values calculated by multiplying inches by
>>> 72, CUPS starts to report these values as an IPP-defined media sizes.
>> 
>> Again, this printer does not support "standard paper sizes" -- it _only_
>> uses printer-specific rolls of media.
>> 
>> It reports as 251.120 because *that is the actual dimension the
>> printer needs*
>> 
>> If we report it as something smaller, then CUPS will hand us a raster
>> image that is smaller than the printer needs, and that will make users
>> very unhappy.
>> 
>>> Michael Sweet, the developer of CUPS, told to report this as a bug to you:
>>> https://github.com/OpenPrinting/cups/issues/1017#issuecomment-2259205981
>>> 
>>> Also I'm not sure why there are same PageSize values used for different page
>>> sizes, for example:
>>> 
>>> *PageSize w243h432/3.375x6:    "<</PageSize[297.600 460.800]/ImagingBBox
>>> null>>setpagedevice"
>>> *PageSize w270h432/3.75x6:    "<</PageSize[297.600 460.800]/ImagingBBox
>>> null>>setpagedevice"
>>> *PageSize w288h432/4x6:    "<</PageSize[297.600 460.800]/ImagingBBox
>>> null>>setpagedevice"
>> 
>> Except it's _not_ the same PageSize; they have different identifiers.  
>> Additionally, the ImageableAreas corresponding to those identifiers are
>> different.
>> 
>> But... so what?  Even if the parameters were 100% identical, they are
>> uniquely named, and those unique names are what clients are supposed to
>> use to disambiguate things.
>> 
>>> I see. Should PageSize/PaperDimension use extended values in this case?
>>> Isn't that controlled by ImageableArea?
>> 
>> I would think ImageableArea is more important than PageSize in this
>> context, yes.
>> 
>>> Check the link above: instead of reporting e.g. na_index-4x6_4x6in, CUPS
>>> reporting custom_117.35x162.56mm_117.35x162.56mm
>> 
>> That's because from the printer's perspective, it's physicaly larger
>> than a "true" 4x6in print.
>> 
>> It is my understanding that the ImageableArea must be entirely contained
>> within the PageSize.  Given that we need an ImageableArea physically
>> larger than a "true" 4x6in print... that means we can't claim to be 4x6.
>> So we don't.
>> 
>> ...Putting aside the less-than-ideal name, does it actually _work_ and
>> print as expected?
>> 
>> Because this appears to be purely a cosmetic issue, brought on by how
>> CUPS auto-translates PPD PageSize+ImageableArea into IPP's
>> media+media-col equivalents.
>> 
>> A native IPP gutenprint print application would presumably be able to do
>> better here; however at the end of the day the CX-02 (and other printers
>> of its general class) do not use "standard" paper sizes, and I don't
>> know what the implications could be if we report the "nominal" media
>> name while correcting/supplenting the specifics in other attributes.
>> 
>> Based on my direct experience with IPP, if you're not using "standard
>> office-type" paper sizes then for a realistic chance of success, you're
>> probably going to have to use a vendor "app" to do the printing instead
>> of "standard" IPP -- and that's using _native_ IPP printers, taking
>> gutenprint + CUPS out of the loop entirely!
>> 
>> (As an aside, it is both faster and more reliable to print to my Brother
>> Laser printer via IPP->CUPS->Gutenprint->JetDirect than it is to use the
>> printer's native driverless IPP functionality.  Even from an iPhone!)
>> 
>> This new IPP world is two orders of magnitude more complicated, and I'm
>> just one person working on this stuff on a (very) part time,
>> entirely-out-of-pocket basis.
>> 
>>> The clients are Windows 10/11, Android 10 (check the link for more info).
>> 
>> At the end of the day I simply *do not care one iota* for supporting or
>> resolving printing problems on proprietary platforms or operating
>> systems.  If those platform owners (and printer manufacturers!) care,
>> then they can do (and/or properly fund) this work themselves.
>> 
>> I'm <this> close to saying "eff this BS" and walking away entirely,
>> because it's at the point where replacing fence posts while having my
>> blood rapidly drained by swarms of mosquitos a moderate drizzle is more
>> personally rewarding than continuing to deal with trying to keep
>> printing working.
>> 
>> (Apologies for the rant, but ..... )
>> 
>> - Solomon
>> --
>> Solomon Peachy                  pizza at shaftnet dot org (email&xmpp)
>>                                     @pizza:shaftnet dot org   (matrix)
>> Dowling Park, FL                      speachy (libera.chat)
>> _______________________________________________
>> Gimp-print-devel mailing list
>> Gim...@li...
>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>> <signature.asc>
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

________________________
Michael Sweet

Are dimensions for all printers specified in points, or does that vary across printers?

Thanks,

Erik
Sent from my iPhone

> On Jul 31, 2024, at 13:06, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> On Wed, Jul 31, 2024 at 06:13:11PM +0300, ValdikSS wrote:
>> I'd expect 3.5x5 PageSize to contain "252 360" value instead of "261.120
>> 460.800".
>> If I modify .ppd file with the values calculated by multiplying inches by
>> 72, CUPS starts to report these values as an IPP-defined media sizes.
> 
> Again, this printer does not support "standard paper sizes" -- it _only_
> uses printer-specific rolls of media.
> 
> It reports as 251.120 because *that is the actual dimension the
> printer needs*
> 
> If we report it as something smaller, then CUPS will hand us a raster
> image that is smaller than the printer needs, and that will make users
> very unhappy.
> 
>> Michael Sweet, the developer of CUPS, told to report this as a bug to you:
>> https://github.com/OpenPrinting/cups/issues/1017#issuecomment-2259205981
>> 
>> Also I'm not sure why there are same PageSize values used for different page
>> sizes, for example:
>> 
>> *PageSize w243h432/3.375x6:    "<</PageSize[297.600 460.800]/ImagingBBox
>> null>>setpagedevice"
>> *PageSize w270h432/3.75x6:    "<</PageSize[297.600 460.800]/ImagingBBox
>> null>>setpagedevice"
>> *PageSize w288h432/4x6:    "<</PageSize[297.600 460.800]/ImagingBBox
>> null>>setpagedevice"
> 
> Except it's _not_ the same PageSize; they have different identifiers.  
> Additionally, the ImageableAreas corresponding to those identifiers are
> different.
> 
> But... so what?  Even if the parameters were 100% identical, they are
> uniquely named, and those unique names are what clients are supposed to
> use to disambiguate things.
> 
>> I see. Should PageSize/PaperDimension use extended values in this case?
>> Isn't that controlled by ImageableArea?
> 
> I would think ImageableArea is more important than PageSize in this
> context, yes.
> 
>> Check the link above: instead of reporting e.g. na_index-4x6_4x6in, CUPS
>> reporting custom_117.35x162.56mm_117.35x162.56mm
> 
> That's because from the printer's perspective, it's physicaly larger
> than a "true" 4x6in print.
> 
> It is my understanding that the ImageableArea must be entirely contained
> within the PageSize.  Given that we need an ImageableArea physically
> larger than a "true" 4x6in print... that means we can't claim to be 4x6.
> So we don't.
> 
> ...Putting aside the less-than-ideal name, does it actually _work_ and
> print as expected?
> 
> Because this appears to be purely a cosmetic issue, brought on by how
> CUPS auto-translates PPD PageSize+ImageableArea into IPP's
> media+media-col equivalents.
> 
> A native IPP gutenprint print application would presumably be able to do
> better here; however at the end of the day the CX-02 (and other printers
> of its general class) do not use "standard" paper sizes, and I don't
> know what the implications could be if we report the "nominal" media
> name while correcting/supplenting the specifics in other attributes.
> 
> Based on my direct experience with IPP, if you're not using "standard
> office-type" paper sizes then for a realistic chance of success, you're
> probably going to have to use a vendor "app" to do the printing instead
> of "standard" IPP -- and that's using _native_ IPP printers, taking
> gutenprint + CUPS out of the loop entirely!
> 
> (As an aside, it is both faster and more reliable to print to my Brother
> Laser printer via IPP->CUPS->Gutenprint->JetDirect than it is to use the
> printer's native driverless IPP functionality.  Even from an iPhone!)
> 
> This new IPP world is two orders of magnitude more complicated, and I'm
> just one person working on this stuff on a (very) part time,
> entirely-out-of-pocket basis.
> 
>> The clients are Windows 10/11, Android 10 (check the link for more info).
> 
> At the end of the day I simply *do not care one iota* for supporting or
> resolving printing problems on proprietary platforms or operating
> systems.  If those platform owners (and printer manufacturers!) care,
> then they can do (and/or properly fund) this work themselves.
> 
> I'm <this> close to saying "eff this BS" and walking away entirely,
> because it's at the point where replacing fence posts while having my
> blood rapidly drained by swarms of mosquitos a moderate drizzle is more
> personally rewarding than continuing to deal with trying to keep
> printing working.
> 
> (Apologies for the rant, but ..... )
> 
> - Solomon
> --
> Solomon Peachy                  pizza at shaftnet dot org (email&xmpp)
>                                      @pizza:shaftnet dot org   (matrix)
> Dowling Park, FL                      speachy (libera.chat)
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> <signature.asc>

Solomon,

Perhaps to "fast track" this discussion, does this printer just use a roll of media and cut it to the desired size?

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

Reporting non-standard sizes with standard names doesn't work on any OS - 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.  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.

________________________
Michael Sweet

Solomon,

> On Jul 31, 2024, at 10:42 AM, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> On Wed, Jul 31, 2024 at 04:29:42AM +0300, ValdikSS via Gimp-print-devel wrote:
>> Citizen CX-02 PPD file contains the following sizes, using what it seems
>> should have been PageRegion/ImageableArea for whatever reason (the
>> dimensions are slightly larger than the described page sizes):
> 
> I'm having a very hard time following what you pasted here, so I'll 
> extract the definitions for one size from the PPD:
> 
> *PageSize B7/3.5x5:     "<</PageSize[261.120 460.800]/ImagingBBox null>>setpagedevice"
> *ImageableArea B7/3.5x5:        "0.000 44.640 261.120 416.160"
> *PaperDimension B7/3.5x5:       "261.120 460.800"
> 
> PageSize and PaperDimension are identical, and ImageableArea is smaller 
> because of how the printer works.
> 
> ....This appears to be perfectly fine and is completely compliant with 
> PPD-based printing flows, which one would expect for something designed 
> around PPDs.

Actually, if you ran cupstestppd against the PPD file it will complain about the dimensions not matching the size (3.5x5 inches should be 252x360 points).

>> The software which relies on standard sizes doesn't show up regular 
>> page size names.
> 
> There is no such thing as a "standard size" from the PPD's perspective; 
> they enumerate what they support (using an arbitrary identifier and 
> UI-visible name) and provide the appropriate dimensions.

Actually, many sizes *are* standard and defined in the Adobe PPD specification.  It is just that a lot of photo printers also support other sizes that Adobe never standardized... :/

>> When the printer is shared in CUPS over IPP, IPP reports only a set of 
>> custom page sizes instead of a standard sizes, and some clients can't 
>> handle that. This seems like a bug. |
> 
> Again, what do you mean by "standard sizes"?  The printer supports what 
> it supports, nothing more.  For example. the CX-02's native resolution 
> at 300dpi is 1844x1240, which equates to 15.37x10.33 cm, and in the PPD 
> we assign it the ID of "w288h432" and UI-visible name of "4x6" for a 
> "standard" 4x6" or 10x15cm print.

The issue is that CUPS will take the paper dimensions and convert *those* to the corresponding PWG media size name.  So 261.12x460.8 points from the previous example for the B7 size gets converted to "custom_b7_92.12x162.56mm" instead of "oe_photo-l_3.5x5in" ("L" being the photo size corresponding to 3.5x5 inches).

________________________
Michael Sweet

On Wed, Jul 31, 2024 at 06:13:11PM +0300, ValdikSS wrote:
> I'd expect 3.5x5 PageSize to contain "252 360" value instead of "261.120
> 460.800".
> If I modify .ppd file with the values calculated by multiplying inches by
> 72, CUPS starts to report these values as an IPP-defined media sizes.

Again, this printer does not support "standard paper sizes" -- it _only_ 
uses printer-specific rolls of media.

It reports as 251.120 because *that is the actual dimension the 
printer needs*

If we report it as something smaller, then CUPS will hand us a raster 
image that is smaller than the printer needs, and that will make users 
very unhappy.

> Michael Sweet, the developer of CUPS, told to report this as a bug to you:
> https://github.com/OpenPrinting/cups/issues/1017#issuecomment-2259205981
> 
> Also I'm not sure why there are same PageSize values used for different page
> sizes, for example:
> 
> *PageSize w243h432/3.375x6:	"<</PageSize[297.600 460.800]/ImagingBBox
> null>>setpagedevice"
> *PageSize w270h432/3.75x6:	"<</PageSize[297.600 460.800]/ImagingBBox
> null>>setpagedevice"
> *PageSize w288h432/4x6:	"<</PageSize[297.600 460.800]/ImagingBBox
> null>>setpagedevice"

Except it's _not_ the same PageSize; they have different identifiers.  
Additionally, the ImageableAreas corresponding to those identifiers are 
different.

But... so what?  Even if the parameters were 100% identical, they are 
uniquely named, and those unique names are what clients are supposed to 
use to disambiguate things.

> I see. Should PageSize/PaperDimension use extended values in this case?
> Isn't that controlled by ImageableArea?

I would think ImageableArea is more important than PageSize in this 
context, yes.

> Check the link above: instead of reporting e.g. na_index-4x6_4x6in, CUPS
> reporting custom_117.35x162.56mm_117.35x162.56mm

That's because from the printer's perspective, it's physicaly larger 
than a "true" 4x6in print.

It is my understanding that the ImageableArea must be entirely contained 
within the PageSize.  Given that we need an ImageableArea physically 
larger than a "true" 4x6in print... that means we can't claim to be 4x6.
So we don't.

...Putting aside the less-than-ideal name, does it actually _work_ and 
print as expected?

Because this appears to be purely a cosmetic issue, brought on by how 
CUPS auto-translates PPD PageSize+ImageableArea into IPP's 
media+media-col equivalents.

A native IPP gutenprint print application would presumably be able to do 
better here; however at the end of the day the CX-02 (and other printers 
of its general class) do not use "standard" paper sizes, and I don't 
know what the implications could be if we report the "nominal" media 
name while correcting/supplenting the specifics in other attributes.

Based on my direct experience with IPP, if you're not using "standard 
office-type" paper sizes then for a realistic chance of success, you're 
probably going to have to use a vendor "app" to do the printing instead 
of "standard" IPP -- and that's using _native_ IPP printers, taking 
gutenprint + CUPS out of the loop entirely!

(As an aside, it is both faster and more reliable to print to my Brother 
Laser printer via IPP->CUPS->Gutenprint->JetDirect than it is to use the 
printer's native driverless IPP functionality.  Even from an iPhone!)

This new IPP world is two orders of magnitude more complicated, and I'm 
just one person working on this stuff on a (very) part time, 
entirely-out-of-pocket basis.

> The clients are Windows 10/11, Android 10 (check the link for more info).

At the end of the day I simply *do not care one iota* for supporting or 
resolving printing problems on proprietary platforms or operating 
systems.  If those platform owners (and printer manufacturers!) care, 
then they can do (and/or properly fund) this work themselves.

I'm <this> close to saying "eff this BS" and walking away entirely, 
because it's at the point where replacing fence posts while having my 
blood rapidly drained by swarms of mosquitos a moderate drizzle is more 
personally rewarding than continuing to deal with trying to keep 
printing working.

(Apologies for the rant, but ..... )

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

On 31.07.2024 17:42, Solomon Peachy wrote:
> I'm having a very hard time following what you pasted here, so I'll
> extract the definitions for one size from the PPD:
> 
> *PageSize B7/3.5x5:     "<</PageSize[261.120 460.800]/ImagingBBox null>>setpagedevice"
> *ImageableArea B7/3.5x5:        "0.000 44.640 261.120 416.160"
> *PaperDimension B7/3.5x5:       "261.120 460.800"
> 
> PageSize and PaperDimension are identical, and ImageableArea is smaller
> because of how the printer works.
> 
> ....This appears to be perfectly fine and is completely compliant with
> PPD-based printing flows, which one would expect for something designed
> around PPDs.

Hi Solomon,
I'd expect 3.5x5 PageSize to contain "252 360" value instead of "261.120 
460.800".
If I modify .ppd file with the values calculated by multiplying inches 
by 72, CUPS starts to report these values as an IPP-defined media sizes.

Michael Sweet, the developer of CUPS, told to report this as a bug to you:
https://github.com/OpenPrinting/cups/issues/1017#issuecomment-2259205981

Also I'm not sure why there are same PageSize values used for different 
page sizes, for example:

*PageSize w243h432/3.375x6:	"<</PageSize[297.600 460.800]/ImagingBBox 
null>>setpagedevice"
*PageSize w270h432/3.75x6:	"<</PageSize[297.600 460.800]/ImagingBBox 
null>>setpagedevice"
*PageSize w288h432/4x6:	"<</PageSize[297.600 460.800]/ImagingBBox 
null>>setpagedevice"

> The CX-02 is a full-bleed printer; in order to guarantee edge-to-edge
> printing the image data has to extend past the physical edges of the
> paper. So if we lie about the supported resolution (eg 1800x1200 for a
> perfect 10x15cm at 300dpi) then if we don't lossily re-scale the image
> to fit the printer's native resolution, we are all but guaranteed to end
> up with visible white margins on at least one edge of the print.

I see. Should PageSize/PaperDimension use extended values in this case? 
Isn't that controlled by ImageableArea?

> ...Meanwhile, you didn't say what version of cups, cups-filters, or
> gutenprint is in use, nor what IPP client is exhibiting this
> misbehavior.

Check the link above: instead of reporting e.g. na_index-4x6_4x6in, CUPS 
reporting custom_117.35x162.56mm_117.35x162.56mm

The printer is shared by CUPS 2.4.2, cups-filters 1.28.17, gutenprint 
5.3.4.20220624T01008808d602. This is Debian 12 system.

The clients are Windows 10/11, Android 10 (check the link for more info).

If this this seem like a bug in CUPS to you, please report details here 
or to the ticket above. I'm not at all skilled in PostScript and .ppd files.

On Wed, Jul 31, 2024 at 04:29:42AM +0300, ValdikSS via Gimp-print-devel wrote:
> Citizen CX-02 PPD file contains the following sizes, using what it seems
> should have been PageRegion/ImageableArea for whatever reason (the
> dimensions are slightly larger than the described page sizes):

I'm having a very hard time following what you pasted here, so I'll 
extract the definitions for one size from the PPD:

*PageSize B7/3.5x5:     "<</PageSize[261.120 460.800]/ImagingBBox null>>setpagedevice"
*ImageableArea B7/3.5x5:        "0.000 44.640 261.120 416.160"
*PaperDimension B7/3.5x5:       "261.120 460.800"

PageSize and PaperDimension are identical, and ImageableArea is smaller 
because of how the printer works.

....This appears to be perfectly fine and is completely compliant with 
PPD-based printing flows, which one would expect for something designed 
around PPDs.

> The software which relies on standard sizes doesn't show up regular 
> page size names.

There is no such thing as a "standard size" from the PPD's perspective; 
they enumerate what they support (using an arbitrary identifier and 
UI-visible name) and provide the appropriate dimensions.

> When the printer is shared in CUPS over IPP, IPP reports only a set of 
> custom page sizes instead of a standard sizes, and some clients can't 
> handle that. This seems like a bug. |

Again, what do you mean by "standard sizes"?  The printer supports what 
it supports, nothing more.  For example. the CX-02's native resolution 
at 300dpi is 1844x1240, which equates to 15.37x10.33 cm, and in the PPD 
we assign it the ID of "w288h432" and UI-visible name of "4x6" for a 
"standard" 4x6" or 10x15cm print.

The CX-02 is a full-bleed printer; in order to guarantee edge-to-edge 
printing the image data has to extend past the physical edges of the 
paper. So if we lie about the supported resolution (eg 1800x1200 for a 
perfect 10x15cm at 300dpi) then if we don't lossily re-scale the image 
to fit the printer's native resolution, we are all but guaranteed to end 
up with visible white margins on at least one edge of the print.

...Meanwhile, you didn't say what version of cups, cups-filters, or 
gutenprint is in use, nor what IPP client is exhibiting this 
misbehavior.

Gutenprint has no IPP capabilities at all, so any IPP-related bugs are 
due to whatever is implementing IPP on top of it.  All necessary 
information is already provided by Gutenprint, so either CUPS' IPP 
translation/re-exporting of the PPD data is improperly converting this 
into native IPP representation, or the IPP client is ignoring it.  
Either way there's nothing Gutenprint can do about it. [1]

[1] Beyond writing our own IPP integration layer.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

Hello list,

Citizen CX-02 PPD file contains the following sizes, using what it seems 
should have been PageRegion/ImageableArea for whatever reason (the 
dimensions are slightly larger than the described page sizes):

...(see above)

Due to this, the software which relies on standard sizes doesn't show up 
regular page size names. When the printer is shared in CUPS over IPP, 
IPP reports only a set of custom page sizes instead of a standard sizes, 
and some clients can't handle that.
This seems like a bug.

Hello list,

Citizen CX-02 PPD file contains the following sizes, using what it seems 
should have been PageRegion/ImageableArea for whatever reason (the 
dimensions are slightly larger than the described page sizes):

|*PageSize B7/3.5x5: "<</PageSize[261.120 460.800]/ImagingBBox 
null>>setpagedevice" *PageSize w144h432/2x6: "<</PageSize[297.600 
460.800]/ImagingBBox null>>setpagedevice" *PageSize w243h432/3.375x6: 
"<</PageSize[297.600 460.800]/ImagingBBox null>>setpagedevice" *PageSize 
w270h432/3.75x6: "<</PageSize[297.600 460.800]/ImagingBBox 
null>>setpagedevice" *PageSize w288h432/4x6: "<</PageSize[297.600 
460.800]/ImagingBBox null>>setpagedevice" *PageSize w288h432-div2/2x6*2: 
"<</PageSize[297.600 460.800]/ImagingBBox null>>setpagedevice" *PageSize 
w324h432/4.5x6: "<</PageSize[332.640 460.800]/ImagingBBox 
null>>setpagedevice" *PageSize w360h360/5x5: "<</PageSize[369.600 
460.800]/ImagingBBox null>>setpagedevice" *PageSize w360h504/5x7: 
"<</PageSize[460.800 513.120]/ImagingBBox null>>setpagedevice" *PageSize 
w360h504-div2/3.5x5*2: "<</PageSize[460.800 522.240]/ImagingBBox 
null>>setpagedevice" *PageSize w360h504-w360h360_w360h144/5x5+2x5: 
"<</PageSize[460.800 513.120]/ImagingBBox null>>setpagedevice" *PageSize 
w432h432/6x6: "<</PageSize[440.640 460.800]/ImagingBBox 
null>>setpagedevice" *PageSize w432h576/6x8: "<</PageSize[460.800 
584.640]/ImagingBBox null>>setpagedevice" *PageSize 
w432h576-w432h432_w432h144/6x6+2x6: "<</PageSize[460.800 
584.640]/ImagingBBox null>>setpagedevice" *PageSize w432h576-div4/2x6*4: 
"<</PageSize[460.800 584.640]/ImagingBBox null>>setpagedevice" *PageSize 
w432h576-div2/4x6*2: "<</PageSize[460.800 599.520]/ImagingBBox 
null>>setpagedevice" *PageSize w432h648/6x9: "<</PageSize[460.800 
657.600]/ImagingBBox null>>setpagedevice" *PageSize 
w432h648-div2/4.5x6*2: "<</PageSize[460.800 672.480]/ImagingBBox 
null>>setpagedevice Due to this, the software which relies on standard 
sizes doesn't show up regular page size names. When the printer is 
shared in CUPS over IPP, IPP reports only a set of custom page sizes 
instead of a standard sizes, and some clients can't handle that. This 
seems like a bug. |

Señor, 
Por favor eche un vistazo al siguiente enlace para darse de baja
de esta lista de correo electrónico.

https://sourceforge.net/projects/gimp-print/lists/gimp-print-devel/unsubscribe

Gracias! 

On Tue, 30 Jul 2024 22:15:42 +0200
Jesus Leyva <jes...@gm...> wrote:

> Borrarme de este correo

Borrarme de este correo

First tweak might be to figure out why the Gutenprint GIMP plugin
doesn't observe the paper source selection, put printing from Gimp
using the same PPD/driver does.  Which might be operator error.

Cheers,

Erik

On Tue, 30 Jul 2024 08:47:32 -0400
Erik Beck of Tahoma <ba...@ta...> wrote:

> Thanks for your help!  And yes, I am guessing the tuning and tweaking
> will take some time, especially with the violet cartridge.
> 
> 
> On the patch, do you want it as a monolithic git diff patch file? And
> noted on the autogen stuff; I'll strip that out.
> 
> Regards,
> 
> Erik
> 
> 
> On Mon, 29 Jul 2024 20:57:04 -0400
> Solomon Peachy via Gimp-print-devel
> <gim...@li...> wrote:
> 
> > On Mon, Jul 29, 2024 at 03:31:22PM -0400, Erik Beck of Tahoma
> > wrote:  
> > > Now I am able to get the printer work, no core dumps in the filter
> > > chain, and can print a basic test page from Ubuntu. Yay!    
> > 
> > Excellent.  But, as I'm sure you'll discover, while you're now 90%
> > of the way there, tuning and tweaking will take up the second 90%..
> >   
> > > Some more tweaks and testing. Then try to see if I can add support
> > > for the violet cartridge in this Commercial Edition version.    
> > 
> > There are several other models that are in a similar situation.
> >   
> > > Let me know when you might want patches given the push to get this
> > > new release out.    
> > 
> > Pretty much any time is fine.  But I strongly suggest you strip out
> > all of the all of the autogenerated stuff from your working
> > repository as it will make submitting patches a lot easier.
> > 
> >  - Solomon  
> 
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Thanks for your help!  And yes, I am guessing the tuning and tweaking
will take some time, especially with the violet cartridge.

On the patch, do you want it as a monolithic git diff patch file? And
noted on the autogen stuff; I'll strip that out.

Regards,

Erik

On Mon, 29 Jul 2024 20:57:04 -0400
Solomon Peachy via Gimp-print-devel
<gim...@li...> wrote:

> On Mon, Jul 29, 2024 at 03:31:22PM -0400, Erik Beck of Tahoma wrote:
> > Now I am able to get the printer work, no core dumps in the filter
> > chain, and can print a basic test page from Ubuntu. Yay!  
> 
> Excellent.  But, as I'm sure you'll discover, while you're now 90% of 
> the way there, tuning and tweaking will take up the second 90%..
> 
> > Some more tweaks and testing. Then try to see if I can add support
> > for the violet cartridge in this Commercial Edition version.  
> 
> There are several other models that are in a similar situation.
> 
> > Let me know when you might want patches given the push to get this
> > new release out.  
> 
> Pretty much any time is fine.  But I strongly suggest you strip out
> all of the all of the autogenerated stuff from your working
> repository as it will make submitting patches a lot easier.
> 
>  - Solomon

On Mon, Jul 29, 2024 at 03:31:22PM -0400, Erik Beck of Tahoma wrote:
> Now I am able to get the printer work, no core dumps in the filter
> chain, and can print a basic test page from Ubuntu. Yay!

Excellent.  But, as I'm sure you'll discover, while you're now 90% of 
the way there, tuning and tweaking will take up the second 90%..

> Some more tweaks and testing. Then try to see if I can add support for
> the violet cartridge in this Commercial Edition version.

There are several other models that are in a similar situation.

> Let me know when you might want patches given the push to get this new
> release out.

Pretty much any time is fine.  But I strongly suggest you strip out all 
of the all of the autogenerated stuff from your working repository as it 
will make submitting patches a lot easier.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

Hi all, work done to provide basic/minimal support for this printer is
at my github repo: 
https://github.com/TahomaSoft/Gutenprint-LocalDev

See branch BasicAdd-Epson-SC-p5000
https://github.com/TahomaSoft/Gutenprint-LocalDev/tree/BasicAdd-Epson-SC-p5000

Regards,

Erik

2000	Jan (111)	Feb (412)	Mar (133)	Apr (187)	May (377)	Jun (355)	Jul (129)	Aug (316)	Sep (412)	Oct (258)	Nov (260)	Dec (228)
2001	Jan (291)	Feb (497)	Mar (341)	Apr (105)	May (127)	Jun (97)	Jul (348)	Aug (195)	Sep (353)	Oct (516)	Nov (454)	Dec (99)
2002	Jan (125)	Feb (232)	Mar (222)	Apr (160)	May (147)	Jun (97)	Jul (199)	Aug (275)	Sep (411)	Oct (355)	Nov (371)	Dec (326)
2003	Jan (314)	Feb (181)	Mar (166)	Apr (90)	May (192)	Jun (137)	Jul (91)	Aug (57)	Sep (59)	Oct (67)	Nov (202)	Dec (158)
2004	Jan (67)	Feb (81)	Mar (142)	Apr (124)	May (190)	Jun (245)	Jul (124)	Aug (199)	Sep (182)	Oct (92)	Nov (285)	Dec (173)
2005	Jan (111)	Feb (74)	Mar (90)	Apr (275)	May (133)	Jun (106)	Jul (215)	Aug (142)	Sep (131)	Oct (135)	Nov (75)	Dec (76)
2006	Jan (173)	Feb (96)	Mar (127)	Apr (226)	May (227)	Jun (83)	Jul (101)	Aug (122)	Sep (118)	Oct (27)	Nov (76)	Dec (58)
2007	Jan (204)	Feb (137)	Mar (115)	Apr (50)	May (135)	Jun (111)	Jul (57)	Aug (40)	Sep (36)	Oct (36)	Nov (77)	Dec (145)
2008	Jan (159)	Feb (52)	Mar (77)	Apr (59)	May (80)	Jun (105)	Jul (119)	Aug (225)	Sep (58)	Oct (173)	Nov (64)	Dec (94)
2009	Jan (61)	Feb (13)	Mar (70)	Apr (115)	May (48)	Jun (50)	Jul (34)	Aug (74)	Sep (30)	Oct (95)	Nov (132)	Dec (12)
2010	Jan (40)	Feb (22)	Mar (10)	Apr (5)	May (10)	Jun (73)	Jul (73)	Aug (74)	Sep (117)	Oct (33)	Nov (34)	Dec (41)
2011	Jan (42)	Feb (38)	Mar (60)	Apr (6)	May (26)	Jun (52)	Jul (16)	Aug (21)	Sep (49)	Oct (48)	Nov (64)	Dec (121)
2012	Jan (112)	Feb (81)	Mar (92)	Apr (37)	May (57)	Jun (142)	Jul (65)	Aug (43)	Sep (33)	Oct (81)	Nov (130)	Dec (63)
2013	Jan (63)	Feb (32)	Mar (80)	Apr (48)	May (44)	Jun (79)	Jul (86)	Aug (91)	Sep (43)	Oct (95)	Nov (130)	Dec (117)
2014	Jan (283)	Feb (206)	Mar (90)	Apr (57)	May (105)	Jun (66)	Jul (87)	Aug (30)	Sep (54)	Oct (125)	Nov (45)	Dec (36)
2015	Jan (58)	Feb (51)	Mar (59)	Apr (75)	May (70)	Jun (52)	Jul (58)	Aug (72)	Sep (184)	Oct (157)	Nov (91)	Dec (90)
2016	Jan (89)	Feb (61)	Mar (57)	Apr (86)	May (46)	Jun (63)	Jul (71)	Aug (60)	Sep (207)	Oct (139)	Nov (76)	Dec (68)
2017	Jan (112)	Feb (91)	Mar (138)	Apr (79)	May (36)	Jun (20)	Jul (105)	Aug (71)	Sep (51)	Oct (114)	Nov (148)	Dec (79)
2018	Jan (118)	Feb (107)	Mar (111)	Apr (127)	May (60)	Jun (63)	Jul (49)	Aug (18)	Sep (134)	Oct (68)	Nov (91)	Dec (27)
2019	Jan (41)	Feb (63)	Mar (37)	Apr (42)	May (44)	Jun (81)	Jul (53)	Aug (21)	Sep (62)	Oct (55)	Nov (41)	Dec (57)
2020	Jan (14)	Feb (29)	Mar (33)	Apr (20)	May (19)	Jun (9)	Jul (5)	Aug (23)	Sep (30)	Oct (29)	Nov (58)	Dec (139)
2021	Jan (62)	Feb (117)	Mar (13)	Apr (17)	May (23)	Jun (28)	Jul (7)	Aug (29)	Sep (56)	Oct (21)	Nov (36)	Dec (14)
2022	Jan (10)	Feb (28)	Mar (18)	Apr (19)	May (18)	Jun (3)	Jul (14)	Aug (11)	Sep (12)	Oct (4)	Nov	Dec (5)
2023	Jan	Feb	Mar (5)	Apr	May (2)	Jun (8)	Jul (2)	Aug	Sep	Oct	Nov	Dec (1)
2024	Jan (5)	Feb	Mar	Apr	May (1)	Jun (1)	Jul (51)	Aug (31)	Sep (10)	Oct (14)	Nov (12)	Dec (14)
2025	Jan (17)	Feb (5)	Mar (30)	Apr (2)	May (4)	Jun (9)	Jul (5)	Aug (4)	Sep (2)	Oct	Nov	Dec