gimp-print-devel

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Robert K. <rl...@al...>]

On 9/22/21 9:11 PM, Solomon Peachy wrote:
> On Thu, Sep 23, 2021 at 01:21:21AM +0200, Till Kamppeter wrote:
>> As I understand, the limitations are also done with clients in mind. If you
>> have a low-resource client, and your Printer Application reports a 5760x2880
>> dpi resolution for PWG Raster input, the client could have problems
>> rendering this.
> 
> Let's be clear here, even a $5 Raspberry Pi Zero has sufficient 
> resources (RAM and CPU oomph) to RIP all but the most specialized (eg 
> max resolution wide format banner printing) output on Epson devices.

Actually, the wide format printers (17"+) are less of a problem -- they all do weaving
(interleaving) inside the printer, and all we need is enough buffering for one row of each color.
The most demanding ones are the high resolution prosumer printers, a step below the pro ones, where
there needs to be enough buffering for a lot of rows, where "lot of" depends on the printer
resolution in more ways than one would realize.  Particularly bad are things like the R1800 (which
is why I used that as an example) where it's really necessary to print at very high resolution to
get decent photo output, because there are no light inks to generate smooth tones with larger drop
sizes.

> (And when you're spending >$20K on such a printer, it's reasonable to 
>  expect that the system it's plugged into is more capable than a RPi Zero)

A lot of routers have less RAM than the Raspberry Pi 0, and RAM's more of an issue than CPU.  And I
could see someone wanting to run a printer app there, if they're using it as a print server.  But
they wouldn't be able to do anything very sophisticated, and that's not what I think we should be
targeting.

> A printer may have a raw hardware resolution of 5760x2800, and you would 
> want to use every bit of that when printing containing fine line details 
> but very little color variation.  Whereas for a photograph, continuous 
> color tones matter more than fine detail, and the necessity of dithering 
> reduces the usable "image" resolution to a fraction of the hardware 
> resolution.  Even with that 5760x2880 hardware resolution there's 
> probably little point in supplying an photograph that's much over 
> 300dpi.

Yes, and as far as that goes I think input resolution and printing resolution should be decoupled,
as long as the input resolution is not allowed to exceed the output resolution.  But some people
need that very high input resolution.

> Ultimately the question is "what is Gutenprint used for" -- if it's just 
> "enable folks use their ancient pre-IPP printer to print office 
> documents and grand-cat photos" then what you've implemented today with 
> the simplified PPDs is fine -- and a "native" version would presumably 
> face the same sorts of restrictions, at least if we're to use stock 
> upstream PAPPL as its base.

Interestingly, in the office (where I was last >18 months ago) we had some high end ImageRunner
printers that someone was trying to print a large PDF file on it and the thing choked; it basically
got hung up forever trying to render the PDF.  That was right around the time I finally got color
PCL printing working (and was sort of the impetus for it).  Our PCL driver is pretty
unsophisticated; it's raster-only, but it worked fine and I printed the person's PDF for him.  He
was suitably impressed.

> However, I strongly believe that today the majority of the Gutenprint 
> userbase are folks with specialized needs, using Gutenprint as a highly 
> capable RIP that happens to be a CUPS driver.  What they care about is 
> accessible functionality; take that away (or make it substantially 
> harder to use) they might as well just go back to using official 
> manufacturer SDKs under Windows.

I agree.  We do get a fair number of questions from people who are desperate to hook up their old
printers to a modern Mac, where the vendor doesn't support any Mac OS beyond 10.6 or so and never
will.  But we also get plenty of tickets from people who want to do interesting things with it,
sometimes things that can't be done with the OEM drivers, because those drivers are designed to
support OEM inks and papers (which is where the OEMs make their real money) and can't do things like
white underlay coats and truly absurd quantities of third party inks that are necessary to
successfully print to T-shirts and the like.

I don't mind having good defaults and making the app easy to use for end users who want to do basic
things, but I draw the line -- hard -- at dumbing down the app because somebody /might/ stumble
across something obscure and get themselves in trouble.  Particularly given how many printers are
supposed to be IPP printers these days (although I don't know that the typical cheap home printers
are yet), I'd rather target 1,200 people who want to do something interesting than 1,200,000 or
120,000,000 people who don't really need Gutenprint because they're running on OEM-supported
printers and doing just fine (bonus points if you know the reference!)

> Don't get me wrong, there are some substantial benefits from the 
> integrated printer application approach vs the loosely-coupled set of 
> filters but at the end of the day we need to meet our users' needs.

Aye, there's the bottom line.  If PAPPL restrictions don't allow us to properly meet the needs of
our user base, then that's just not an option for us.  I desperately want to get away from PPD
files; I've never cared for them and I've been ranting off and on about the subject for 20 years
now.  But replacing them with something that's actually a lot less capable is a non-starter.  We'd
be better off basing it on libgutenprintui2 and properly CUPS-enabling that.

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Solomon P. <pi...@sh...>]

On Thu, Sep 23, 2021 at 01:21:21AM +0200, Till Kamppeter wrote:
> As I understand, the limitations are also done with clients in mind. If you
> have a low-resource client, and your Printer Application reports a 5760x2880
> dpi resolution for PWG Raster input, the client could have problems
> rendering this.

Let's be clear here, even a $5 Raspberry Pi Zero has sufficient 
resources (RAM and CPU oomph) to RIP all but the most specialized (eg 
max resolution wide format banner printing) output on Epson devices.

(And when you're spending >$20K on such a printer, it's reasonable to 
 expect that the system it's plugged into is more capable than a RPi Zero)

That said, "printer hardware resolution" and "input data resolution" are 
only loosely coupled and their relation depends entirely on what you're 
trying to print/produce.

A printer may have a raw hardware resolution of 5760x2800, and you would 
want to use every bit of that when printing containing fine line details 
but very little color variation.  Whereas for a photograph, continuous 
color tones matter more than fine detail, and the necessity of dithering 
reduces the usable "image" resolution to a fraction of the hardware 
resolution.  Even with that 5760x2880 hardware resolution there's 
probably little point in supplying an photograph that's much over 
300dpi.

Ultimately the question is "what is Gutenprint used for" -- if it's just 
"enable folks use their ancient pre-IPP printer to print office 
documents and grand-cat photos" then what you've implemented today with 
the simplified PPDs is fine -- and a "native" version would presumably 
face the same sorts of restrictions, at least if we're to use stock 
upstream PAPPL as its base.

However, I strongly believe that today the majority of the Gutenprint 
userbase are folks with specialized needs, using Gutenprint as a highly 
capable RIP that happens to be a CUPS driver.  What they care about is 
accessible functionality; take that away (or make it substantially 
harder to use) they might as well just go back to using official 
manufacturer SDKs under Windows.

Don't get me wrong, there are some substantial benefits from the 
integrated printer application approach vs the loosely-coupled set of 
filters but at the end of the day we need to meet our users' needs.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (libra.chat)

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Robert K. <rl...@al...>]

On 9/22/21 7:21 PM, Till Kamppeter wrote:
> I think also the 32 vendor options can be very restrictive, here are some thoughts on what I do and
> what one can do.
> 
> On 23/09/2021 00:47, Robert Krawitz wrote:
>>
>> I understand the concern about embedded platforms, but some printers (in particular, ESC/P2 printers
>> without printer interleave) require substantial host memory to print, particularly at high
>> resolution.  If you're printing at 5760x2880 DPI with an 8-channel printer, that's a lot of memory
>> just to print at all, particularly with a wide page.  Is the purpose of this to limit the memory
>> consumed by PAPPL, or to discourage printing applications that are resource-intensive?
>
> As I understand, the limitations are also done with clients in mind. If you have a low-resource
> client, and your Printer Application reports a 5760x2880 dpi resolution for PWG Raster input, the
> client could have problems rendering this.

That's absolutely true, but it's not a reason to restrict all clients.

> My current Gutenprint retro-fit Printer Application would expose 360 dpi for draft, 720 dpi for
> normal, and 1440 dpi for high quality. Clients then would render in these resolutions. Inside the
> Printer Application Gutenprint will dither with any resolution it is capable of, for example with
> 5760x2880 dpi.

It depends upon what you're doing.  Gutenprint does offer quality presets, which vary with the
printer and paper type.  For photos, the ideal output resolution depends upon the printer.  With the
CcMmYKkk printers with 3-4 pl drops, 1440x720 usually does just fine.  With 4 color (or CMYKRB)
printers with 1 pl drops, it needs to be a lot higher, although input resolution doesn't.  If you're
printing extremely detailed line art, though, the higher resolution the better.

> libpappl-retrofit usually reports 3 resolutions for each printer, one for draft, one for normal, and
> one for high quality, selecting the appropriate one when the input data is an image (JPEG, PNG).

But there are more kinds of outputs than that; there are typically about 6-8 quality presets
(economy draft, draft, normal, high, photo, photo high, and best IIRC).

> If the input is PDF or PostScript, the driver uses anything what it needs, not necessarily one of
> the 3 reported resolutions. So sending a line drawing (vector graphics) in PDF and printing in
> highest possible quality, can make Ghostscript render in 5760x2880 for example.

Yep.  But you don't ever want to send higher resolution to the driver than the printing resolution.

> If a PPD file has a "Resolution" option, you can access all the resolutions it offers, on the
> "Printing Defaults" page there will be a "Resolution" entry near the top for the reported
> resolutions, but also a "resolution  entry more down which is set to "automatic-selection". Select
> anything else here to access the advanced resolutions.
> 
> If there is no "Resolution" option in the PPD, resolution is set by some other PPD options
> ("Quality"?). Also this option you find down the list, defaulting to "automatic-selection". Set it
> to something else to get more detailed quality control than only the draft/normal/high of the
> standard IPP attribute.
> 
> The Gutenprint Printer Application itself needs the same high amount of memory and CPU power as the
> CUPS driver.

And there's the rub -- it simply isn't going to run well at high quality settings on low spec
clients.  A router with 256 MB RAM just is not going to be able to print to an Epson R1800 at high
resolution; the RAM is just insufficient.  I doubt whether 32 options or 320 is going to make nearly
as much difference.

>> That certainly isn't something I want to do, for those reasons and more.  But the suggestion of some
>> kind of web application to generate bundles of settings is extremely complicated itself.  I'm not
>> sure what a Gutenprint-specific web UI that allows people to tweak those knobs and create presets
>> would mean, but that would seem to only increase complexity over having just one application.  Where
>> would the web UI back end run?  If it's on the local system, that suggests that a server has to be
>> running there, which makes for its own exposure.  We don't have the resources to support a cloud
>> infrastructure, and it creates additional dependencies (active internet connection that can reach a
>> service) to boot.
> 
> You do not need an extra application. You can add web interface pages to the Printer Application.
> See my PostScript Printer Application. It has one extra page for the system (to upload PPD files)
> and one extra page for the printers ("Device Settings", to configure installable accessories). You
> could add one or more pages for the printers to create presets of advanced adjustments, as I have
> already described with more detail in another e-mail.

Then I don't understand what this "web interface pages" is.

> By the way, I will add two additional interfaces for adding web interface pages to
> libpappl-retrofit, one for extra pages for the system, one for extra pages for the printers.
> 
>    Till

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Till K. <til...@gm...>]

I think also the 32 vendor options can be very restrictive, here are 
some thoughts on what I do and what one can do.

On 23/09/2021 00:47, Robert Krawitz wrote:
> 
> I understand the concern about embedded platforms, but some printers (in particular, ESC/P2 printers
> without printer interleave) require substantial host memory to print, particularly at high
> resolution.  If you're printing at 5760x2880 DPI with an 8-channel printer, that's a lot of memory
> just to print at all, particularly with a wide page.  Is the purpose of this to limit the memory
> consumed by PAPPL, or to discourage printing applications that are resource-intensive?
>

As I understand, the limitations are also done with clients in mind. If 
you have a low-resource client, and your Printer Application reports a 
5760x2880 dpi resolution for PWG Raster input, the client could have 
problems rendering this.

My current Gutenprint retro-fit Printer Application would expose 360 dpi 
for draft, 720 dpi for normal, and 1440 dpi for high quality. Clients 
then would render in these resolutions. Inside the Printer Application 
Gutenprint will dither with any resolution it is capable of, for example 
with 5760x2880 dpi.

libpappl-retrofit usually reports 3 resolutions for each printer, one 
for draft, one for normal, and one for high quality, selecting the 
appropriate one when the input data is an image (JPEG, PNG).

If the input is PDF or PostScript, the driver uses anything what it 
needs, not necessarily one of the 3 reported resolutions. So sending a 
line drawing (vector graphics) in PDF and printing in highest possible 
quality, can make Ghostscript render in 5760x2880 for example.

If a PPD file has a "Resolution" option, you can access all the 
resolutions it offers, on the "Printing Defaults" page there will be a 
"Resolution" entry near the top for the reported resolutions, but also a 
"resolution  entry more down which is set to "automatic-selection". 
Select anything else here to access the advanced resolutions.

If there is no "Resolution" option in the PPD, resolution is set by some 
other PPD options ("Quality"?). Also this option you find down the list, 
defaulting to "automatic-selection". Set it to something else to get 
more detailed quality control than only the draft/normal/high of the 
standard IPP attribute.

The Gutenprint Printer Application itself needs the same high amount of 
memory and CPU power as the CUPS driver.

>> See my other message to Till, but in the case of resolution we have two sets of values - raster data that is sent to the "RIP" and raster data that is generated by the RIP for the printer.  As for the number of driver/RIP options, the point of IPP Everywhere is to enable printing from all kinds of clients, many of which don't have limited display/memory/CPU resources so we want to have presets/basic capabilities provided by all printers, with the expert stuff available but not required.  PAPPL_MAX_VENDOR is 32, which *should* be enough for a native Gutenprint implementation (the PPD implementation doubles up many of the current settings).
> 
> It's not enough for a full featured Gutenprint implementation; some printers (particularly Epson
> printers) have a lot of obscure options that we want to make available for people who need them.
> That doesn't mean they all have to be on one page.  With both the CUPS driver and GIMP plugin we
> provide multiple pages with successive disclosure of complexity, as a former colleague describe it.
> 
> As it happens, we get requests for even more options than we already provide, and I've said no to
> some of them.  For example, someone recently wanted a way to remap channels; the black channel on
> his printer was malfunctioning, so he wanted to put that on another channel that he doesn't need.  I
> suggested that he edit the appropriate .xml file.  Some users, like the T-shirt printing crowd,
> really do need a lot of controls to do their printing, and I want to be able to provide those.  If
> that means that users with more conventional printing needs choose to click the Advanced Color
> Settings 4 tab and find it confusing, I consider that acceptable; just don't use those features, and
> we've squirreled them out of the way so that you don't have to see them if you don't want to.
> 
> On the subject of resolutions, many Epson printers use different ink size drop sets for 360,
> 720x360, and 720 DPI, so the results will be significantly different.  Speaking for myself, at any
> rate, I want to provide this flexibility to users.  And I can state that with fine detail line art
> (such as the 1 degree lines on the old CUPS test page, looks significantly different at 2880x2880
> DPI than at 2880x1440 (which does have additional moire issues) or 1440x1440 DPI on those Epson
> printers with small enough drop sizes that support 2880 DPI in the length dimension.  It does take
> longer to generate and send, but for someone who can use that degree of detail, it matters.  And
> again, an option that someone doesn't need can be ignored; an option that isn't provided can't be done.
> 

See above. Send vector fine art as PDF and Ghostscript Gutenprint use 
the final resolution right away inside the Printer Application.


>>>> What I could do is that in the Snap I could build PAPPL with a higher limit (Snaps bring their own
>>>> libraries).
>>>
>>> That's not good.  This would make it impossible to distribute the printer app via other mechanisms
>>> (e. g. RPM).  I still really wouldn't like to do it, but vendoring PAPPL into Gutenprint and
>>> carrying a patch to eliminate the limits would at least be somewhat portable.  If that broke the
>>> network protocol that wouldn't do, but then a snap would have the same problem.
>>
>> Please don't.  Mini-XML as embedded in Gutenprint is hopelessly out of date, but at least the security exposure is limited.  PAPPL provides network print service and web interfaces and is a much bigger target.
> 
> That certainly isn't something I want to do, for those reasons and more.  But the suggestion of some
> kind of web application to generate bundles of settings is extremely complicated itself.  I'm not
> sure what a Gutenprint-specific web UI that allows people to tweak those knobs and create presets
> would mean, but that would seem to only increase complexity over having just one application.  Where
> would the web UI back end run?  If it's on the local system, that suggests that a server has to be
> running there, which makes for its own exposure.  We don't have the resources to support a cloud
> infrastructure, and it creates additional dependencies (active internet connection that can reach a
> service) to boot.

You do not need an extra application. You can add web interface pages to 
the Printer Application. See my PostScript Printer Application. It has 
one extra page for the system (to upload PPD files) and one extra page 
for the printers ("Device Settings", to configure installable 
accessories). You could add one or more pages for the printers to create 
presets of advanced adjustments, as I have already described with more 
detail in another e-mail.

By the way, I will add two additional interfaces for adding web 
interface pages to libpappl-retrofit, one for extra pages for the 
system, one for extra pages for the printers.

    Till

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Robert K. <rl...@al...>]

On 9/22/21 12:53 PM, Till Kamppeter wrote:
> On 21/09/2021 17:01, Michael Sweet wrote:
>> Till,
>>
>> The point should not be to propagate hundreds or thousands of printer-specific knobs to trip up
>> the user (even expert users!)

I disagree.  I'm fine with a simplified UI for people who don't want to do anything fancy, and I'm
fine with that containing a basic set of resolutions.  But it's very important to me that people who
want to do advanced things should be able to without jumping through gratuitous hoops.

Re your comment in a previous message that "it would be a pain to scroll through that many options
(in one long list) on a phone", phones aren't likely to have a Gutenprint port, and iPhones
definitely won't (due to app store policies).  And I don't propose one long list of options,
about:config style

>> It makes more sense to provide a Gutenprint-specific web UI that allows (expert) users to do test
>> prints and tweak those knobs. Once you are happy with the settings, save them with a name ("Bob's
>> Photo Preset") and expose the presets as single vendor extension attribute, which then shows up in
>> the print dialog.
>
> Makes much more sense to me.

How would this work?  Where would the web server run?  This sounds like it would make life very
complicated for people who want to do advanced things, just so that people who only want to do
simple printing don't get curious about an "Advanced Options" box, check it, then get overwhelmed by
what's available.

I have no problem with presets, certainly.  The GIMP plugin does this and it has always worked fine.
 What I don't want is for someone to have to use a separate application to create them that either
needs a web server on the local machine (with all the security problems that go with that) or that
they need to be online for to connect to some cloud infrastructure that has to be maintained.

> In the retro-fitting Gutenprint Printer Application I will continue with the simplified PPDs for
> now, as the retro-fit is an interim solution where we should not spend too much time on.
> 
> I suggest for the native GutenPrint Printer Application an additional web interface page for the
> printers (as I did with the PostScript Printer Application where I have added "Device Settings" to
> configure the installable accessories).
> 
> One could add an "Advanced Settings" page, where one can set all these extra options, with tabs for
> the logical groups of the options, a better way to adjust numeric values (instead of 2 enumerated
> choices for coarse and fine adjustment), buttons for saving the settings under a name (preset), for
> switching between prsets, removing/renaming/copying/cloning presets. And if there is at least one
> preset, the "Printing Defaults" get an "Advanced Settings" vendor option, where one can choose
> between "Default" and each of the save presets.

The "coarse" and "fine" adjustments are a hack due to the lack of an appropriate facility in PPD
files.  In the GIMP plugin there's none of that; it's just a bunch of sliders

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Robert K. <rl...@al...>]

On 9/21/21 12:02 PM, Michael Sweet wrote:
> Robert,
> 
>> On Sep 21, 2021, at 10:22 AM, Robert Krawitz <rl...@al...> wrote:
>>
>> On 9/21/21 10:01 AM, Till Kamppeter wrote:
>>> On 21/09/2021 02:28, Robert Krawitz wrote:
>>>>> Note that the retro-fit is not perfect, especially due to the restricted number of vendor-specific
>>>>> options in PAPPL I could base my Printer Application only on the simplified PPDs and not on the
>>>>> expert ones.
>>>>
>>>> What restriction is this?
>>>
>>> PAPPL only allows a fixed (hard-coded) maximum number of vendor-specific options (PAPPL_MAX_VENDOR =
>>> 32) in addition to the standard IPP options for a printer. The number of options in the expert PPD
>>> files is too large for this limit.
>>
>> What??????  Hard-coded limits in this day and age?  I notice that there are a bunch of others.
>>
>> With this kind of limit, it would seem very difficult to build a proper RIP using PAPPL.
> 
> The limits were explicitly chosen as a balance of capability vs. scaling, specifically for a "proper RIP" that might run on an embedded platform without swap/unlimited memory.

I understand the concern about embedded platforms, but some printers (in particular, ESC/P2 printers
without printer interleave) require substantial host memory to print, particularly at high
resolution.  If you're printing at 5760x2880 DPI with an 8-channel printer, that's a lot of memory
just to print at all, particularly with a wide page.  Is the purpose of this to limit the memory
consumed by PAPPL, or to discourage printing applications that are resource-intensive?

> See my other message to Till, but in the case of resolution we have two sets of values - raster data that is sent to the "RIP" and raster data that is generated by the RIP for the printer.  As for the number of driver/RIP options, the point of IPP Everywhere is to enable printing from all kinds of clients, many of which don't have limited display/memory/CPU resources so we want to have presets/basic capabilities provided by all printers, with the expert stuff available but not required.  PAPPL_MAX_VENDOR is 32, which *should* be enough for a native Gutenprint implementation (the PPD implementation doubles up many of the current settings).

It's not enough for a full featured Gutenprint implementation; some printers (particularly Epson
printers) have a lot of obscure options that we want to make available for people who need them.
That doesn't mean they all have to be on one page.  With both the CUPS driver and GIMP plugin we
provide multiple pages with successive disclosure of complexity, as a former colleague describe it.

As it happens, we get requests for even more options than we already provide, and I've said no to
some of them.  For example, someone recently wanted a way to remap channels; the black channel on
his printer was malfunctioning, so he wanted to put that on another channel that he doesn't need.  I
suggested that he edit the appropriate .xml file.  Some users, like the T-shirt printing crowd,
really do need a lot of controls to do their printing, and I want to be able to provide those.  If
that means that users with more conventional printing needs choose to click the Advanced Color
Settings 4 tab and find it confusing, I consider that acceptable; just don't use those features, and
we've squirreled them out of the way so that you don't have to see them if you don't want to.

On the subject of resolutions, many Epson printers use different ink size drop sets for 360,
720x360, and 720 DPI, so the results will be significantly different.  Speaking for myself, at any
rate, I want to provide this flexibility to users.  And I can state that with fine detail line art
(such as the 1 degree lines on the old CUPS test page, looks significantly different at 2880x2880
DPI than at 2880x1440 (which does have additional moire issues) or 1440x1440 DPI on those Epson
printers with small enough drop sizes that support 2880 DPI in the length dimension.  It does take
longer to generate and send, but for someone who can use that degree of detail, it matters.  And
again, an option that someone doesn't need can be ignored; an option that isn't provided can't be done.

>>> What I could do is that in the Snap I could build PAPPL with a higher limit (Snaps bring their own
>>> libraries).
>>
>> That's not good.  This would make it impossible to distribute the printer app via other mechanisms
>> (e. g. RPM).  I still really wouldn't like to do it, but vendoring PAPPL into Gutenprint and
>> carrying a patch to eliminate the limits would at least be somewhat portable.  If that broke the
>> network protocol that wouldn't do, but then a snap would have the same problem.
> 
> Please don't.  Mini-XML as embedded in Gutenprint is hopelessly out of date, but at least the security exposure is limited.  PAPPL provides network print service and web interfaces and is a much bigger target.

That certainly isn't something I want to do, for those reasons and more.  But the suggestion of some
kind of web application to generate bundles of settings is extremely complicated itself.  I'm not
sure what a Gutenprint-specific web UI that allows people to tweak those knobs and create presets
would mean, but that would seem to only increase complexity over having just one application.  Where
would the web UI back end run?  If it's on the local system, that suggests that a server has to be
running there, which makes for its own exposure.  We don't have the resources to support a cloud
infrastructure, and it creates additional dependencies (active internet connection that can reach a
service) to boot.

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Till K. <til...@gm...>]

On 21/09/2021 17:01, Michael Sweet wrote:
> Till,
> 
> The point should not be to propagate hundreds or thousands of printer-specific knobs to trip up the user (even expert users!)
> 
> It makes more sense to provide a Gutenprint-specific web UI that allows (expert) users to do test prints and tweak those knobs. Once you are happy with the settings, save them with a name ("Bob's Photo Preset") and expose the presets as single vendor extension attribute, which then shows up in the print dialog.
> 

Makes much more sense to me.

In the retro-fitting Gutenprint Printer Application I will continue with 
the simplified PPDs for now, as the retro-fit is an interim solution 
where we should not spend too much time on.

I suggest for the native GutenPrint Printer Application an additional 
web interface page for the printers (as I did with the PostScript 
Printer Application where I have added "Device Settings" to configure 
the installable accessories).

One could add an "Advanced Settings" page, where one can set all these 
extra options, with tabs for the logical groups of the options, a better 
way to adjust numeric values (instead of 2 enumerated choices for coarse 
and fine adjustment), buttons for saving the settings under a name 
(preset), for switching between prsets, 
removing/renaming/copying/cloning presets. And if there is at least one 
preset, the "Printing Defaults" get an "Advanced Settings" vendor 
option, where one can choose between "Default" and each of the save presets.

    Till

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Till K. <til...@gm...>]

On 21/09/2021 17:38, Michael Sweet via Gimp-print-devel wrote:
> 
> Go ahead, but it'll get closed as "wontfix".  Sorry to be so blunt, but PAPPL runs in embedded environments with hard memory limits far below what you'd have on a smartphone, tablet, or desktop/server computer.  Moreover, supporting an arbitrary number of options/values is a path to madness for both the UI designer (that has to deal with unrealistic numbers of options that have to be laid out automatically) and the end user (who has to figure out WTF they all do...)
>

OK, it would be a pain to scroll through that many options (in one long 
list) on a phone ...

>> Another limit which I observed is that only 4 resolutions can get registered. Also works with practically all drivers except Gutenprint. And for one PPD (Epson Stylus Photo TX810FW - CUPS+Gutenprint v5.3.4 Simplified) I saw also irregularities with the list of paper types, some showing twice and a sub-process of the Printer Application crashing when one changes the paper type. I did not check, but for me it smells like the number of paper types is overrunning the limit here.

The problem with the paper types is that the ppd-cache.c functions 
(these are the same in libcups and libppd) assign the same PWG name to 
different PPD names of some paper types (variations of glossy photo 
paper). I have now simply skipped the duplicates.

> 
> PAPPL_MAX_MEDIA is 256.
>

These are the paper sizes, no problem with them.

> The number of resolution is limited for two reasons:
> 
> 1. Apple Raster only supports symmetric resolutions
> 2. Sending raster data at full device resolution doesn't make sense (generally limit to 720dpi for photos/images and 1440dpi for lines) since big raster data takes a lot longer to send and dithering limits the amount of edge detail that is possible.  So for printers that support 360, 720x360, 720, 1440x720, 1440, 2880x1440, 2880, and 5760x1440dpi should probably only report 360, 720, and 1440 dpi raster data and then upscale as needed.  (I can update PAPPL to support the driver adding printer-resolution-default/-supported values while PAPPL exports the resolution values in the pwg-raster-document-resolution-supported and urf-supported attributes)
> 

I have now added a limitation for the PAPPL-reported input resolutions 
in libpappl-retrofit: 360 dpi for draft, 720 dpi for normal, and 1440 
dpi for high print quality. Internally, the resolutions of APPL/PWG 
Raster input are converted to whatever the driver needs. PDF and 
PostScript input is directly rendered in the resolution which the driver 
requests.

>> What do you mean with "vendoring PAPPL into Gutenprint"?
> 
> I highly recommend against embedding PAPPL.  The same was done to Mini-XML and the embedded version is hopelessly out of date compared to the current release...
>

I am also against this practice, it is a nightmare for packaging and 
security fix handling.

> Each value is limited to 32767 bytes by the wire protocol, but otherwise this is true in theory.  However, you can cause some pretty serious DoS issues by sending large numbers of values or large numbers of attributes, even on desktop clients.

OK.

    Till

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Michael S. <ms...@ms...>]

Robert,

> On Sep 21, 2021, at 10:22 AM, Robert Krawitz <rl...@al...> wrote:
> 
> On 9/21/21 10:01 AM, Till Kamppeter wrote:
>> On 21/09/2021 02:28, Robert Krawitz wrote:
>>>> Note that the retro-fit is not perfect, especially due to the restricted number of vendor-specific
>>>> options in PAPPL I could base my Printer Application only on the simplified PPDs and not on the
>>>> expert ones.
>>> 
>>> What restriction is this?
>> 
>> PAPPL only allows a fixed (hard-coded) maximum number of vendor-specific options (PAPPL_MAX_VENDOR =
>> 32) in addition to the standard IPP options for a printer. The number of options in the expert PPD
>> files is too large for this limit.
> 
> What??????  Hard-coded limits in this day and age?  I notice that there are a bunch of others.
> 
> With this kind of limit, it would seem very difficult to build a proper RIP using PAPPL.

The limits were explicitly chosen as a balance of capability vs. scaling, specifically for a "proper RIP" that might run on an embedded platform without swap/unlimited memory.

See my other message to Till, but in the case of resolution we have two sets of values - raster data that is sent to the "RIP" and raster data that is generated by the RIP for the printer.  As for the number of driver/RIP options, the point of IPP Everywhere is to enable printing from all kinds of clients, many of which don't have limited display/memory/CPU resources so we want to have presets/basic capabilities provided by all printers, with the expert stuff available but not required.  PAPPL_MAX_VENDOR is 32, which *should* be enough for a native Gutenprint implementation (the PPD implementation doubles up many of the current settings).

>> What I could do is that in the Snap I could build PAPPL with a higher limit (Snaps bring their own
>> libraries).
> 
> That's not good.  This would make it impossible to distribute the printer app via other mechanisms
> (e. g. RPM).  I still really wouldn't like to do it, but vendoring PAPPL into Gutenprint and
> carrying a patch to eliminate the limits would at least be somewhat portable.  If that broke the
> network protocol that wouldn't do, but then a snap would have the same problem.

Please don't.  Mini-XML as embedded in Gutenprint is hopelessly out of date, but at least the security exposure is limited.  PAPPL provides network print service and web interfaces and is a much bigger target.

________________________
Michael Sweet

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Michael S. <ms...@ms...>]

All,

> On Sep 21, 2021, at 11:06 AM, Till Kamppeter <til...@gm...> wrote:
> 
> On 21/09/2021 16:22, Robert Krawitz wrote:
>>> PAPPL only allows a fixed (hard-coded) maximum number of vendor-specific options (PAPPL_MAX_VENDOR =
>>> 32) in addition to the standard IPP options for a printer. The number of options in the expert PPD
>>> files is too large for this limit.
>> What??????  Hard-coded limits in this day and age?  I notice that there are a bunch of others.
>> 
> 
> We should report a bug.

Go ahead, but it'll get closed as "wontfix".  Sorry to be so blunt, but PAPPL runs in embedded environments with hard memory limits far below what you'd have on a smartphone, tablet, or desktop/server computer.  Moreover, supporting an arbitrary number of options/values is a path to madness for both the UI designer (that has to deal with unrealistic numbers of options that have to be laid out automatically) and the end user (who has to figure out WTF they all do...)

> Another limit which I observed is that only 4 resolutions can get registered. Also works with practically all drivers except Gutenprint. And for one PPD (Epson Stylus Photo TX810FW - CUPS+Gutenprint v5.3.4 Simplified) I saw also irregularities with the list of paper types, some showing twice and a sub-process of the Printer Application crashing when one changes the paper type. I did not check, but for me it smells like the number of paper types is overrunning the limit here.

PAPPL_MAX_MEDIA is 256.

The number of resolution is limited for two reasons:

1. Apple Raster only supports symmetric resolutions
2. Sending raster data at full device resolution doesn't make sense (generally limit to 720dpi for photos/images and 1440dpi for lines) since big raster data takes a lot longer to send and dithering limits the amount of edge detail that is possible.  So for printers that support 360, 720x360, 720, 1440x720, 1440, 2880x1440, 2880, and 5760x1440dpi should probably only report 360, 720, and 1440 dpi raster data and then upscale as needed.  (I can update PAPPL to support the driver adding printer-resolution-default/-supported values while PAPPL exports the resolution values in the pwg-raster-document-resolution-supported and urf-supported attributes)

> And was Gutenprint not Mike's baby?

a long time ago now...

> The limits not only affect my (interim) retro-fit but also your native Printer Application.
> 
>> With this kind of limit, it would seem very difficult to build a proper RIP using PAPPL.
>>> What I could do is that in the Snap I could build PAPPL with a higher limit (Snaps bring their own
>>> libraries).
>> That's not good.  This would make it impossible to distribute the printer app via other mechanisms
>> (e. g. RPM).  I still really wouldn't like to do it, but vendoring PAPPL into Gutenprint and
>> carrying a patch to eliminate the limits would at least be somewhat portable. 
> 
> What do you mean with "vendoring PAPPL into Gutenprint"?

I highly recommend against embedding PAPPL.  The same was done to Mini-XML and the embedded version is hopelessly out of date compared to the current release...

>> If that broke the
>> network protocol that wouldn't do, but then a snap would have the same problem.
> 
> The network protocol cannot break by raising these limits, AFAIK IPP has no limits for the number of attributes and the number of values for each attribute.

Each value is limited to 32767 bytes by the wire protocol, but otherwise this is true in theory.  However, you can cause some pretty serious DoS issues by sending large numbers of values or large numbers of attributes, even on desktop clients.

________________________
Michael Sweet

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Michael S. <ms...@ms...>]

Till,

The point should not be to propagate hundreds or thousands of printer-specific knobs to trip up the user (even expert users!)

It makes more sense to provide a Gutenprint-specific web UI that allows (expert) users to do test prints and tweak those knobs. Once you are happy with the settings, save them with a name ("Bob's Photo Preset") and expose the presets as single vendor extension attribute, which then shows up in the print dialog.


> On Sep 21, 2021, at 10:01 AM, Till Kamppeter <til...@gm...> wrote:
> 
> On 21/09/2021 02:28, Robert Krawitz wrote:
>>> Note that the retro-fit is not perfect, especially due to the restricted number of vendor-specific
>>> options in PAPPL I could base my Printer Application only on the simplified PPDs and not on the
>>> expert ones.
>> What restriction is this?
> 
> PAPPL only allows a fixed (hard-coded) maximum number of vendor-specific options (PAPPL_MAX_VENDOR = 32) in addition to the standard IPP options for a printer. The number of options in the expert PPD files is too large for this limit.
> 
> What I could do is that in the Snap I could build PAPPL with a higher limit (Snaps bring their own libraries).
> 
>   Till
> 

________________________
Michael Sweet

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Robert K. <rl...@al...>]

On 9/21/21 11:06 AM, Till Kamppeter wrote:
> On 21/09/2021 16:22, Robert Krawitz wrote:
>>> PAPPL only allows a fixed (hard-coded) maximum number of vendor-specific options (PAPPL_MAX_VENDOR =
>>> 32) in addition to the standard IPP options for a printer. The number of options in the expert PPD
>>> files is too large for this limit.
>>
>> What??????  Hard-coded limits in this day and age?  I notice that there are a bunch of others.
>>
> We should report a bug.
> 
> Another limit which I observed is that only 4 resolutions can get registered. Also works with
> practically all drivers except Gutenprint. And for one PPD (Epson Stylus Photo TX810FW -
> CUPS+Gutenprint v5.3.4 Simplified) I saw also irregularities with the list of paper types, some
> showing twice and a sub-process of the Printer Application crashing when one changes the paper type.
> I did not check, but for me it smells like the number of paper types is overrunning the limit here.
> 
> And was Gutenprint not Mike's baby?

Mike wrote the original Print plugin for GIMP which I took and started the Gimp-Print (renamed
Gutenprint with release 5.0) project around.  Mike wrote the original CUPS driver for Gutenprint
working with the rest of the team.

> The limits not only affect my (interim) retro-fit but also your native Printer Application.

Yes.  That's a problem.

>> With this kind of limit, it would seem very difficult to build a proper RIP using PAPPL.
>>
>>> What I could do is that in the Snap I could build PAPPL with a higher limit (Snaps bring their own
>>> libraries).
>>
>> That's not good.  This would make it impossible to distribute the printer app via other mechanisms
>> (e. g. RPM).  I still really wouldn't like to do it, but vendoring PAPPL into Gutenprint and
>> carrying a patch to eliminate the limits would at least be somewhat portable. 
> 
> What do you mean with "vendoring PAPPL into Gutenprint"?

Putting a copy of PAPPL into the Gutenprint source with these limits lifted.  Same kind of thing
that a lot of projects have done with dcraw.

>> If that broke the
>> network protocol that wouldn't do, but then a snap would have the same problem.
> 
> The network protocol cannot break by raising these limits, AFAIK IPP has no limits for the number of
> attributes and the number of values for each attribute.

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Till K. <til...@gm...>]

On 21/09/2021 16:22, Robert Krawitz wrote:
>> PAPPL only allows a fixed (hard-coded) maximum number of vendor-specific options (PAPPL_MAX_VENDOR =
>> 32) in addition to the standard IPP options for a printer. The number of options in the expert PPD
>> files is too large for this limit.
> 
> What??????  Hard-coded limits in this day and age?  I notice that there are a bunch of others.
>

We should report a bug.

Another limit which I observed is that only 4 resolutions can get 
registered. Also works with practically all drivers except Gutenprint. 
And for one PPD (Epson Stylus Photo TX810FW - CUPS+Gutenprint v5.3.4 
Simplified) I saw also irregularities with the list of paper types, some 
showing twice and a sub-process of the Printer Application crashing when 
one changes the paper type. I did not check, but for me it smells like 
the number of paper types is overrunning the limit here.

And was Gutenprint not Mike's baby?

The limits not only affect my (interim) retro-fit but also your native 
Printer Application.

> With this kind of limit, it would seem very difficult to build a proper RIP using PAPPL.
> 
>> What I could do is that in the Snap I could build PAPPL with a higher limit (Snaps bring their own
>> libraries).
> 
> That's not good.  This would make it impossible to distribute the printer app via other mechanisms
> (e. g. RPM).  I still really wouldn't like to do it, but vendoring PAPPL into Gutenprint and
> carrying a patch to eliminate the limits would at least be somewhat portable. 

What do you mean with "vendoring PAPPL into Gutenprint"?

> If that broke the
> network protocol that wouldn't do, but then a snap would have the same problem.

The network protocol cannot break by raising these limits, AFAIK IPP has 
no limits for the number of attributes and the number of values for each 
attribute.

    Till

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Robert K. <rl...@al...>]

On 9/21/21 10:01 AM, Till Kamppeter wrote:
> On 21/09/2021 02:28, Robert Krawitz wrote:
>>> Note that the retro-fit is not perfect, especially due to the restricted number of vendor-specific
>>> options in PAPPL I could base my Printer Application only on the simplified PPDs and not on the
>>> expert ones.
>>
>> What restriction is this?
> 
> PAPPL only allows a fixed (hard-coded) maximum number of vendor-specific options (PAPPL_MAX_VENDOR =
> 32) in addition to the standard IPP options for a printer. The number of options in the expert PPD
> files is too large for this limit.

What??????  Hard-coded limits in this day and age?  I notice that there are a bunch of others.

With this kind of limit, it would seem very difficult to build a proper RIP using PAPPL.

> What I could do is that in the Snap I could build PAPPL with a higher limit (Snaps bring their own
> libraries).

That's not good.  This would make it impossible to distribute the printer app via other mechanisms
(e. g. RPM).  I still really wouldn't like to do it, but vendoring PAPPL into Gutenprint and
carrying a patch to eliminate the limits would at least be somewhat portable.  If that broke the
network protocol that wouldn't do, but then a snap would have the same problem.

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Till K. <til...@gm...>]

On 21/09/2021 02:28, Robert Krawitz wrote:
>> Note that the retro-fit is not perfect, especially due to the restricted number of vendor-specific
>> options in PAPPL I could base my Printer Application only on the simplified PPDs and not on the
>> expert ones.
> 
> What restriction is this?

PAPPL only allows a fixed (hard-coded) maximum number of vendor-specific 
options (PAPPL_MAX_VENDOR = 32) in addition to the standard IPP options 
for a printer. The number of options in the expert PPD files is too 
large for this limit.

What I could do is that in the Snap I could build PAPPL with a higher 
limit (Snaps bring their own libraries).

    Till

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Gene C. <gen...@gm...>]

OOPS! I apologize, I was trying to let Scott Boyd, the local expert about
this, and inadvertently sent it to you! I am so sorry, as an attorney (but
definitely not an expert on this) I should have been more careful!

But I waill say, this sounds like a neat thing to me! If it weren't
open-source I would suggest consulting an IP attorney -not me, though, i am
an IP attorney, but I m most decidedly not an "ambulance chaser".

Have a great day, and again, my bad!

Gene Cavanaugh

On Mon, Sep 20, 2021 at 5:29 PM Robert Krawitz <rl...@al...> wrote:

> On 9/20/21 6:32 PM, Till Kamppeter wrote:
> > Hi,
> >
> > I have created a Gutenprint Printer Application by retro-fitting
> Gutenprint's CUPS driver into a
> > Printer Application using PAPPL (https://github.com/michaelrsweet/pappl)
> and my CUPS driver
> > retro-fit library pappl-retrofit (
> https://github.com/OpenPrinting/pappl-retrofit):
> >
> > https://github.com/OpenPrinting/gutenprint-printer-app
> > https://snapcraft.io/gutenprint-printer-app
> >
> > Note that this is only an interim effort, as the right way to make a
> Printer Application out of
> > Gutenprint is a native Printer Apoplication, not using PPDs, the CUPS
> filter, and the CUPS backend
> > of Gutenprint, but instead, use only PAPPL and libgutenprint. Therefore
> I will maintain this Printer
> > Application only as long as there is no native Gutenprint Printer
> Application from the Gutenprint
> > project, once that is there, I will discontinue my Printer Application.
> >
> > Note that the retro-fit is not perfect, especially due to the restricted
> number of vendor-specific
> > options in PAPPL I could base my Printer Application only on the
> simplified PPDs and not on the
> > expert ones.
>
> What restriction is this?
>
>
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>

Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Robert K. <rl...@al...>]

On 9/20/21 6:32 PM, Till Kamppeter wrote:
> Hi,
> 
> I have created a Gutenprint Printer Application by retro-fitting Gutenprint's CUPS driver into a
> Printer Application using PAPPL (https://github.com/michaelrsweet/pappl) and my CUPS driver
> retro-fit library pappl-retrofit (https://github.com/OpenPrinting/pappl-retrofit):
> 
> https://github.com/OpenPrinting/gutenprint-printer-app
> https://snapcraft.io/gutenprint-printer-app
> 
> Note that this is only an interim effort, as the right way to make a Printer Application out of
> Gutenprint is a native Printer Apoplication, not using PPDs, the CUPS filter, and the CUPS backend
> of Gutenprint, but instead, use only PAPPL and libgutenprint. Therefore I will maintain this Printer
> Application only as long as there is no native Gutenprint Printer Application from the Gutenprint
> project, once that is there, I will discontinue my Printer Application.
> 
> Note that the retro-fit is not perfect, especially due to the restricted number of vendor-specific
> options in PAPPL I could base my Printer Application only on the simplified PPDs and not on the
> expert ones.

What restriction is this?

[Gimp-print-devel] Gutenprint Printer Application (Native)

[Till K. <til...@gm...>]

Hi,

I have created a Gutenprint Printer Application by retro-fitting 
Gutenprint's CUPS driver into a Printer Application using PAPPL 
(https://github.com/michaelrsweet/pappl) and my CUPS driver retro-fit 
library pappl-retrofit (https://github.com/OpenPrinting/pappl-retrofit):

https://github.com/OpenPrinting/gutenprint-printer-app
https://snapcraft.io/gutenprint-printer-app

Note that this is only an interim effort, as the right way to make a 
Printer Application out of Gutenprint is a native Printer Apoplication, 
not using PPDs, the CUPS filter, and the CUPS backend of Gutenprint, but 
instead, use only PAPPL and libgutenprint. Therefore I will maintain 
this Printer Application only as long as there is no native Gutenprint 
Printer Application from the Gutenprint project, once that is there, I 
will discontinue my Printer Application.

Note that the retro-fit is not perfect, especially due to the restricted 
number of vendor-specific options in PAPPL I could base my Printer 
Application only on the simplified PPDs and not on the expert ones.

I also included the CUPS backend for dye-sub printers but could not 
actually test it.

So please test my Printer Applications on printers which I do not have 
(I only have the HP OfficeJet Pro 8730, which my Gutenprint Printer 
Application sets up as PCL Color Laser). Issue reports and pull requests 
are more than welcome.

Sambhav, still working on a native Gutenprint Printer Application?

I hope my Printer Application will give some inspiration towards the 
development of a native Gutenprint Printer Application.

    Till

Re: [Gimp-print-devel] your plug-in or app for iMac running Big Sur ...

[Matt B. <wal...@ma...>]

> On Sep 16, 2021, at 2:59 PM, SMYTH Bart <bs...@gm...> wrote:
> 
> 
> Hello —
> 
> I’m currently running Catalina on my iMac and have your program installed so I can continue to print with my Epson Workforce 30 for which I'm very grateful to you.
> 
> The thing is that I’m being pressured into upgrading to Mac OS Big Sur partly because of this spyware called Pegasus. However, if I can’t use my Epson WF30 printer I’m being very reluctant to go up to Big Sur.
> 
> So, do you have a version of your software that will allow me to print on this printer if my Mac is running Big Sur?

The current version of the macos drivers -- gutenprint-5.3.3_rev.dmg <https://sourceforge.net/projects/gimp-print/files/gutenprint-5.3/5.3.3/gutenprint-5.3.3_rev.dmg/download> -- will work with Mac OS X 10.7.x thru Big Sur.  You may need to reinstall the drivers after the upgrade.  Apple has been known to remove third party drivers during an upgrade.

Matt

Re: [Gimp-print-devel] 'commandtoepson' revamping?

[Robert K. <rl...@al...>]

On 9/16/21 8:43 AM, Solomon Peachy wrote:
> I'd like to change 'commandtoepson' to work the way CUPS expects, and 
> add the filter to the PPD so CUPS can invoke it automatically, but this 
> would require an implementation change so that it doesn't trigger a 
> print.
> 
> This would be broadly applicable to any printer escputil can work with, 
> so it probably makes sense to enable it across the board for the entire 
> escp2 family (perhaps with a blacklist) rather than only enabling it for 
> specific models.
> 
> Thoughts?
> 
> (The dyesub backend acually implements this command filter functionality 
>  already, but I never did hook it up to the PPDs)

This is going to need some pretty thorough testing.  Unfortunately, I don't have many old printers
any more, so there's going to need to be some kind of graceful failure.

[Gimp-print-devel] your plug-in or app for iMac running Big Sur ...

[SMYTH B. <bs...@gm...>]

Hello —

I’m currently running Catalina on my iMac and have your program installed so I can continue to print with my Epson Workforce 30 for which I'm very grateful to you.

The thing is that I’m being pressured into upgrading to Mac OS Big Sur partly because of this spyware called Pegasus. However, if I can’t use my Epson WF30 printer I’m being very reluctant to go up to Big Sur.

So, do you have a version of your software that will allow me to print on this printer if my Mac is running Big Sur?

Bart Smyth
(412) 576-8448

•

 

[Gimp-print-devel] 'commandtoepson' revamping?

[Solomon P. <pi...@sh...>]

I've been looking at how to get escp2 printer status and ink level 
reporting back up through the CUPS stack.  This is normally done via 
inline ATTRs via the normal print filter flow, but can also be done 
using an out-of-band "command filter".

I saw that there is an existing 'commandtoepson' filter, but it's not 
hooked up through our generated PPDs, so CUPS doesn't know it exists.  
Digging a little further I discovered that due to how it's written, the 
'ReportLevels' command trigges a physical printout rather than just 
querying and returning (ala escputil) the status/levels as ATTRs that 
CUPS expects and can report to the user:

  https://www.cups.org/doc/spec-command.html#ReportLevels

I'd like to change 'commandtoepson' to work the way CUPS expects, and 
add the filter to the PPD so CUPS can invoke it automatically, but this 
would require an implementation change so that it doesn't trigger a 
print.

This would be broadly applicable to any printer escputil can work with, 
so it probably makes sense to enable it across the board for the entire 
escp2 family (perhaps with a blacklist) rather than only enabling it for 
specific models.

Thoughts?

(The dyesub backend acually implements this command filter functionality 
 already, but I never did hook it up to the PPDs)

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (libra.chat)

Re: [Gimp-print-devel] Printer support_question

[Matt B. <wal...@ma...>]

> On Sep 13, 2021, at 1:49 PM, Max Fomin <fo...@gm...> wrote:
> 
> Hello! 
> Please tell me if it is possible to add the Xerox Phaser 3140-3155 to the list of supported printers? Unfortunately, this model is no longer supported on macOS BigSUR. Thanks in advance for your reply.
> 

Unfortunately Gutenprint will not be able to support this printer.  It relies on a proprietary printer language developed by Xerox.

Matt

Re: [Gimp-print-devel] Does not work on Brother HL-5170DN

[Matt B. <wal...@ma...>]

<html><head></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="ApplePlainTextBody"><div class="ApplePlainTextBody"><br><br><blockquote type="cite">On Sep 13, 2021, at 8:32 PM, Barry Gehm &lt;bar...@ly...&gt; wrote:<br><br>Hi,<br>I downloaded and installed Gutenprint 5.3.3 on my mid-2012 MacBook Pro running Catalina (10.15.7) and attempted to use it with my Brother HL-5170DN printer. &nbsp;Although the installation appeared to go smoothly, attempting to print using the Gutenprint driver resulted in the printer just spitting out page after page of printed error messages (one per page). &nbsp;The same thing happens when I attempt to use the Brother CUPS driver, although the BRscript-3 driver works.<br></blockquote><br>Thank you for your interest in the Gutenprint drivers. &nbsp;It appears to me that the printer is not responding to the PCL language. &nbsp;That would be the printer language used in the Brother CUPS and the Gutenprint drivers. &nbsp;The garbage output is presumably PostScript/BrushScript code. &nbsp;The BrushScript driver is a PostScript driver. &nbsp;Normally, a printer will automatically change modes to whatever print language it is sent. Perhaps others here might have some more insight.<br>Matt<br><br></div></body></html>

Re: [Gimp-print-devel] Gutenprint 5.3.4: only on 32-bit failures with "Image is too long/wide for the page" for certain PPDs

[jsmeix <js...@su...>]

Hello,

On 2021-09-11 17:51, Robert Krawitz wrote:
> On 9/9/21 7:58 AM, jsmeix wrote:
>> From my own experience about 30 years ago I remember
>> that in practice
>> "there is no such thing as 'equal' with float data types".
>> 
>> I.e. code that is based on 'float1 == float2' cannot work
>> reliably in general because even if float1 and float2
>> must me mathematically identical it does not mean their
>> representations as a limited sequences of bits are same.
> 
> That's certainly true, but the converse (that
> inequality comparisons are safe) is not necessarily
> true (even strict inequality comparisons,
> e. g. < vs. <=, aren't always safe for numbers
> that can't be represented exactly).

Yes, of course.
That's what I meant with "based on 'float1 == float2'".
E.g. 'float1 < float2' is based on 'float1 == float2'
because when one cannot safely/reliably determine
when 'float1 == float2' holds then one also cannot
safely/reliably determine when 'float1 < float2' holds
because 'float1 < float2 <=> 'NOT float1 >= float2' and
'float1 >= float2' <=> 'float1 > float2' OR 'float1 == float2'
so 'float1 < float2' needs (is based on) 'float1 == float2'.


> We may need to implement small fudge factors,
> maybe something like 0.000001 point

I would not call it "fudge" because it is not about
to somehow "cheat" a bit here but the contrary:
It is about to ignore meaningless aritfacts
of differences in some least significant bits.
I.e. ignoring such meaningless aritfacts
makes things working correct.


Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Felix Imendoerffer