gimp-print-devel

[Gimp-print-devel] Unsupported Printer

[Nahed S. <na...@gm...>]

Hi,
i'm trying to do a printer server using RPI for all my existing printers,
put it notice that
HP DeskJet T830 is still missing in you package .

it has already support for Mac OS X 10.8

are you willing to support it ?

Thanks,
Nahed

[Gimp-print-devel] (no subject)

[Hannah B. <han...@gm...>]

Hi,
I am having issues with my canon Pixma MG7520 printer and i think it is the
driver (the printer stopped working about 2 years ago).  Through a canon
help forum, i learned I could try to use Gutenprint driver.  My OS is
Catalina 10.15.7.  I've tried to download the guten print driver but not
sure it has done anything.  when i turn on my printer it still shows this
[image: IMG_7789.jpg]

Canon charges $19.99 for a phone calo/support which is ridiculous!  Can you
help? Thank you.
Hannah

Re: [Gimp-print-devel] HeadConfiguration question

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

On 10/6/21 8:41 AM, Andrew X wrote:
> May be its any way to send empty data for fist N nozzles? 
> Unfortunately I don't know how gutenprint generate data for printer and asking stupid questions. 
> Gutenprint generate data for each pass of printhead with offset? In this case we, perhaps, can
> generate "no dots" for nozzles. Or we sending complete dots matrix of image and printer divide
> itself for printgead passes?

What is your use case?

> ср, 6 окт. 2021 г., 15:13 Robert Krawitz <rl...@al... <mailto:rl...@al...>>:
> 
>     On 10/6/21 4:49 AM, Andrew X wrote:
>     > Hello!
>     > Im trying to modify <headConfiguration> for SC-p800 and have some issues/
>     > When I change <Nozzles> - everything work fine/ When I setup 30 nozzles - only first 30 nozzles
>     > printing image.
>     > But when i trying to change <FirstNozzle> to 20 my print doesnt work. 
>     >
>     > As I understand it - when nozzles 30 and firstnozzle 20 - nozzles from 20 to 50 should printing
>     > image? right?
>     >
>     > And when i changing <NozzleSeparation> 5 - printer not printing too.
>     >
>     > May be i not understanding how this options should work? Is any way to force printing only with
>     > specified nozzles array from 20 to 50 for example? not only from first nozzle?
> 
>     These aren't really options; they're descriptions of the printer (firmware + hardware).  The
>     firmware expects a certain number of rows, starting from a specified row (usually, but not always,
>     the first).  We could in principle send dummy data for the first N rows, but I don't recall that we
>     have a way to do that.  Skipping rows would be much harder.  NozzleSeparation really is the
>     specification of the distance between nozzles; it's very unlikely that that would ever work on any
>     printer.

Re: [Gimp-print-devel] HeadConfiguration question

[Andrew X <68...@gm...>]

May be its any way to send empty data for fist N nozzles?
Unfortunately I don't know how gutenprint generate data for printer and
asking stupid questions.
Gutenprint generate data for each pass of printhead with offset? In this
case we, perhaps, can generate "no dots" for nozzles. Or we sending
complete dots matrix of image and printer divide itself for printgead
passes?

ср, 6 окт. 2021 г., 15:13 Robert Krawitz <rl...@al...>:

> On 10/6/21 4:49 AM, Andrew X wrote:
> > Hello!
> > Im trying to modify <headConfiguration> for SC-p800 and have some issues/
> > When I change <Nozzles> - everything work fine/ When I setup 30 nozzles
> - only first 30 nozzles
> > printing image.
> > But when i trying to change <FirstNozzle> to 20 my print doesnt work.
> >
> > As I understand it - when nozzles 30 and firstnozzle 20 - nozzles from
> 20 to 50 should printing
> > image? right?
> >
> > And when i changing <NozzleSeparation> 5 - printer not printing too.
> >
> > May be i not understanding how this options should work? Is any way to
> force printing only with
> > specified nozzles array from 20 to 50 for example? not only from first
> nozzle?
>
> These aren't really options; they're descriptions of the printer (firmware
> + hardware).  The
> firmware expects a certain number of rows, starting from a specified row
> (usually, but not always,
> the first).  We could in principle send dummy data for the first N rows,
> but I don't recall that we
> have a way to do that.  Skipping rows would be much harder.
> NozzleSeparation really is the
> specification of the distance between nozzles; it's very unlikely that
> that would ever work on any
> printer.
>
>
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>

Re: [Gimp-print-devel] HeadConfiguration question

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

On 10/6/21 4:49 AM, Andrew X wrote:
> Hello!
> Im trying to modify <headConfiguration> for SC-p800 and have some issues/
> When I change <Nozzles> - everything work fine/ When I setup 30 nozzles - only first 30 nozzles
> printing image.
> But when i trying to change <FirstNozzle> to 20 my print doesnt work. 
> 
> As I understand it - when nozzles 30 and firstnozzle 20 - nozzles from 20 to 50 should printing
> image? right?
> 
> And when i changing <NozzleSeparation> 5 - printer not printing too.
> 
> May be i not understanding how this options should work? Is any way to force printing only with
> specified nozzles array from 20 to 50 for example? not only from first nozzle?

These aren't really options; they're descriptions of the printer (firmware + hardware).  The
firmware expects a certain number of rows, starting from a specified row (usually, but not always,
the first).  We could in principle send dummy data for the first N rows, but I don't recall that we
have a way to do that.  Skipping rows would be much harder.  NozzleSeparation really is the
specification of the distance between nozzles; it's very unlikely that that would ever work on any
printer.

[Gimp-print-devel] HeadConfiguration question

[Andrew X <68...@gm...>]

Hello!
Im trying to modify <headConfiguration> for SC-p800 and have some issues/
When I change <Nozzles> - everything work fine/ When I setup 30 nozzles -
only first 30 nozzles printing image.
But when i trying to change <FirstNozzle> to 20 my print doesnt work.

As I understand it - when nozzles 30 and firstnozzle 20 - nozzles from 20
to 50 should printing image? right?

And when i changing <NozzleSeparation> 5 - printer not printing too.

May be i not understanding how this options should work? Is any way to
force printing only with specified nozzles array from 20 to 50 for example?
not only from first nozzle?

[Gimp-print-devel] Printing white and color inks in one pass

[Andrew X <68...@gm...>]

Hello. I have dtg epson 3880 with cmyk and white inks. I am looking for a
way to make it printing white&cmyk in one pass - when first half of nozzles
printing with white inks and second part of nozzles printing with cmyk like
on Pic in attachment. Can you advise something? May be its possible to edit
something in gutenprint to make it possible?

Re: [Gimp-print-devel] Samsung ML-2160

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

On 10/1/21 4:15 PM, Alexandre ARNAUD wrote:
> Hello, 
> 
> Thank you for providing drivers to those in need. Do you plan to include the Samsung ML-2160 as well?

Hi,

Unfortunately, this printer appears to use a proprietary printer command language (SPL) which we
have no way of supporting.  You could try the generic PCL XL driver in Gutenprint, but I don't
expect that it will work.

[Gimp-print-devel] Samsung ML-2160

[Alexandre A. <ale...@gm...>]

Hello,

Thank you for providing drivers to those in need. Do you plan to include
the Samsung ML-2160 as well?

Best Regards,
Alexandre

[Gimp-print-devel] Epson SC-P900 support

[Pierre <pi...@or...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"><head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 </head><body style="font-family: arial,helvetica,sans-serif; font-size: 13pt"><p>Hello,</p><p>Do you plan to support the new EPSON Sc-P900 and 700 printers ?</p><p>There is a violet ink in these printers that is not taken into account when I try to print charts via Cups/gutenprint on linux Ubuntu 20.04 with my Sc-p900&#8230; so I print on Windows ... :-(</p><p>Best regards.</p><p>Pierre</p></body></html>

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

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

On Thu, Sep 16, 2021 at 07:48:39PM -0400, Robert Krawitz wrote:
> 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.

I just committed the first steps in this direction.  I generalized the 
logic in the PPD generator to get the command filter name and the list 
of supported commands out of internal configuration variables, instead 
of blindly exporting support for 'commandtoepson' with an implicit (and 
incorrect) list of supported commands if the printer name included the 
string 'EPSON'.

I used the same variable mechanism to finally hook up cups command 
support to the dyesub family, and I can confirm it works on the models 
that I can access remotely right now.  Huzzah!

Next up will be to try and bridge escputil consumable & status queries 
into the commandtoepson backend.

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

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

On 26/09/2021 23:31, Solomon Peachy wrote:
> On Thu, Sep 23, 2021 at 05:57:04PM +0200, Till Kamppeter wrote:
>> Please test my Gutenprint Printer Application with different printer models
>> and report issues and feature requests, and also post pull requests on
>>
>> https://github.com/OpenPrinting/gutenprint-printer-app/
> 
> For those in fedora-land, there's now a COPR of the openprinting apps:
> 
>    https://copr.fedorainfracloud.org/coprs/nielsenb/printer-apps/
> 

Thanks, great to know.

    Till

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

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

On Thu, Sep 23, 2021 at 05:57:04PM +0200, Till Kamppeter wrote:
> Please test my Gutenprint Printer Application with different printer models
> and report issues and feature requests, and also post pull requests on
> 
> https://github.com/OpenPrinting/gutenprint-printer-app/

For those in fedora-land, there's now a COPR of the openprinting apps:

  https://copr.fedorainfracloud.org/coprs/nielsenb/printer-apps/

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

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

On 26/09/2021 17:12, Robert Krawitz wrote:
> On 9/23/21 8:36 AM, Till Kamppeter wrote:
>> In the snapcraft.yaml for my Snap I modify the PAPPL_MAX_VENDOR in the PAPPL source code to 256
>> before compiling PAPPL. I have to build PAPPL myself anyway for the Snap, as there is no Ubuntu LTS
>> package of it, I want to always have the newest version, I patch it anyway for string option support.
> 
> Thanks for doing this.
> 
> This is not a proper solution to the problem.  While containers and container registries very
> definitely have their place, it's not acceptable to my mind for it to be _only_ usable through this
> mechanism.  We need to find a way around this.
> 

Yes, I do it only for the retro-fitting, interim Printer Application, so 
that Gutenprint in a Printer Application works for the time being, the 
native Printer Application should do it the right way.

    Till

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

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

On 9/23/21 8:36 AM, Till Kamppeter wrote:
> First off, I have made my retro-fitting Gutenprint Printer Application supporting the expert PPDs of
> Gutenprint now.
> 
> It uses simplified or expert PPDs depending on how many vendor-specific options (PAPPL_MAX_VENDOR)
> the installed PAPPL supports. If it is 256 or more, the expert PPDs are used, otherwise the
> simplified ones.
> 
> In the snapcraft.yaml for my Snap I modify the PAPPL_MAX_VENDOR in the PAPPL source code to 256
> before compiling PAPPL. I have to build PAPPL myself anyway for the Snap, as there is no Ubuntu LTS
> package of it, I want to always have the newest version, I patch it anyway for string option support.
> 
> So the Snap as it is in the Snap Store now supports all these options! And for users of devices with
> small, simple print dialogs (like phones) have the best possible control with standard IPP
> attributes (which are automatically converted to PPD option settings).

Thanks for doing this.

This is not a proper solution to the problem.  While containers and container registries very
definitely have their place, it's not acceptable to my mind for it to be _only_ usable through this
mechanism.  We need to find a way around this.

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

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

On Thu, Sep 23, 2021 at 05:57:04PM +0200, Till Kamppeter wrote:
> Please test my Gutenprint Printer Application with different printer models
> and report issues and feature requests, and also post pull requests on
> 
> https://github.com/OpenPrinting/gutenprint-printer-app/

I wanted to express a hearty thank you for this wrapper around 
Gutenprint.  Please don't interpret my grumbling about implementation
as ingratitude!

Unfortunately I'm pretty swamped right now with non-printing 
obligations, but I will be getting this going with my fleet of dyesubs 
as soon as I have a few hours to spare.

 - 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 for Epson L3110

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

On 9/23/21 10:41 AM, Iago Machado wrote:
> Hi,
> 
> Do you have any plans on supporting Epson L3110? I get it working using L310 driver, but the quality
> and speed print are so low. Thanks for your help

What settings are you using?

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

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

Robert,

> On Sep 23, 2021, at 6:06 PM, Robert Krawitz <rl...@al...> wrote:
> 
> On 9/23/21 5:34 PM, Michael Sweet wrote:
>> Robert,
>> 
>>> On Sep 23, 2021, at 7:54 AM, Robert Krawitz <rl...@al...> wrote:
>>>> ...
>>>> No, but having fixed limits does make memory usage *predictable*.
>>> 
>>> Well, other than that the underlying driver might not have such predictable memory usage.
>> 
>> Well, I can't do anything about the drivers themselves, just PAPPL. :)
> 
> Sure, but what kind of devices are you looking at where even dynamic arrays that for most drivers
> won't exceed maybe a dozen elements and even Gutenprint (which isn't designed to run on such
> devices) won't exceed a few hundred will blow out memory?  Drivers that are complex enough to need
> very large numbers of settings aren't likely to run in a very tightly memory constrained environment
> anyway.

The minimal device I'm targeting has at least 128MB of RAM - sufficient for most consumer printers.
> 
>>> So I could have one set of options for the density settings and so forth, and I'm limited to 30 sets
>>> of options (or one set of options for each group of options, such as Basic Printer Options, Basic
>>> Color Options, Advanced Color Options 1, and so forth)?  Because that's not what it looked like.
>> 
>> The usual way is for one attribute = one value (or set of values).  Collections allow you to define more complex values.
> 
> Complex values, not complex settings.  That's really not going to be sufficient.

Robert, there is more than one way to do a thing.  If I look at the 112 Epson Stylus Pro 10000 options, I see a LOT of value/fine-value pairs (not necessary with IPP) and settings that should be grouped in collections.  Thus those 112 PPD options map to various standard IPP attributes and *3* vendor attributes:

- StpVacuumIntensity -> stp-vacuum-intensity (although it should probably be a media-col member attribute)

"stp-output-col (collection)":

- StpBandEnhancement -> stp-output-col.stp-band-enhancement
- StpBrightness/StpFineBrightness -> stp-output-col.stp-brightness
- StpColorCorrection -> stp-output-col.stp-color-correction
- StpColorPrecision -> stp-output-col.stp-color-precision
- StpContrast/StpFineContrast -> stp-output-col.stp-contrast
- StpDitherAlgorithm -> stp-output-col.stp-dither-algorithm
- StpImageType -> stp-output-col.stp-image-type
- StpPrintingDirection -> stp-output-col.stp-printing-direction
- StpQuality -> stp-output-col.stp-print-quality
- StpSaturation/StpFineSaturation -> stp-output-col.stp-saturation
- StpWeave -> stp-output-col.stp-weave

"stp-ink-col (collection)":

- StpGCRXxx/StpFineGCRXxx -> stp-ink-col.stp-gcr-xxx
- StpInkLimit/StpFineInkLimit -> stp-ink-col.stp-ink-limit
- StpInkSet -> stp-ink-col.stp-ink-set
- StpInkType -> stp-ink-col.stp-ink-type
- StpSubchannelCutoff/StpFineSubchannelCutoff -> stp-ink-col.stp-subchannel-cutoff
- StpXxxBalance/StpFineXxxBalance -> stp-ink-col.stp-xxx-balance
- StpXxxDensity/StpFineXxxDensity -> stp-ink-col.stp-xxx-density
- StpXxxGamma/StpFineXxxGamma -> stp-ink-col.stp-xxx-gamma
- StpXxxScale/StpFineXxxScale -> stp-ink-col.stp-xxx-scale
- StpXxxTrans/StpFineXxxTrans -> stp-ink-col.stp-xxx-trans
- StpXxxValue/StpFineXxxValue -> stp-ink-col.stp-xxx-value


>>>> ...
>>>> You already have a GTK+ UI, and modern web UI has similar capabilities.
>>> 
>>> I'd just as soon use the existing GTK+ UI rather than have to write a new web application.
>> 
>> Well, that is ultimately your call.
> 
> Is this going to seamlessly provide the extra settings to users?  Or will they have to use the web
> app to edit something to save as a named setting, but won't be able to change it on the fly?  This
> sounds very painful for users with sophisticated needs.

The web interface (or printer application GUI) is there for the users to test and (hopefully) save presets for the settings they'll use from ordinary apps/devices.  You can be sure that most applications will NOT provide the full set of controls for Gutenprint-specific attributes, so it is on you to provide a way for users to access them.  You might even have the application pop up a print confirmation/preview window when something is printed.

>>> Even a local TCP port (http or https://localhost) has its problems, since it means that something
>>> running under a different UID can access it.  A lot of browsers strongly discourage use of http
>>> these days, and https means getting a certificate.  Just a whole lot of hoops to jump through for
>>> what looks to me to be dubious benefit.
>> 
>> Well, again PAPPL handles all of this for you, and yes I understand that browsers have totally screwed things up WRT IoT device access - that is something I've been fighting for the last 10 years - but the standards call for web UI because that at least is portable.
> 
> Ugh.  Tons and tons of JavaScript or the like.

Please, you don't need Javascript to do a web UI.  And honestly if you can handle GTK+ you shouldn't have any problems doing HTML forms.

________________________
Michael Sweet

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

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

On 9/23/21 5:34 PM, Michael Sweet wrote:
> Robert,
> 
>> On Sep 23, 2021, at 7:54 AM, Robert Krawitz <rl...@al...> wrote:
>>> ...
>>> No, but having fixed limits does make memory usage *predictable*.
>>
>> Well, other than that the underlying driver might not have such predictable memory usage.
> 
> Well, I can't do anything about the drivers themselves, just PAPPL. :)

Sure, but what kind of devices are you looking at where even dynamic arrays that for most drivers
won't exceed maybe a dozen elements and even Gutenprint (which isn't designed to run on such
devices) won't exceed a few hundred will blow out memory?  Drivers that are complex enough to need
very large numbers of settings aren't likely to run in a very tightly memory constrained environment
anyway.

>> So I could have one set of options for the density settings and so forth, and I'm limited to 30 sets
>> of options (or one set of options for each group of options, such as Basic Printer Options, Basic
>> Color Options, Advanced Color Options 1, and so forth)?  Because that's not what it looked like.
> 
> The usual way is for one attribute = one value (or set of values).  Collections allow you to define more complex values.

Complex values, not complex settings.  That's really not going to be sufficient.

>>> ...
>>> You already have a GTK+ UI, and modern web UI has similar capabilities.
>>
>> I'd just as soon use the existing GTK+ UI rather than have to write a new web application.
> 
> Well, that is ultimately your call.

Is this going to seamlessly provide the extra settings to users?  Or will they have to use the web
app to edit something to save as a named setting, but won't be able to change it on the fly?  This
sounds very painful for users with sophisticated needs.

>> Even a local TCP port (http or https://localhost) has its problems, since it means that something
>> running under a different UID can access it.  A lot of browsers strongly discourage use of http
>> these days, and https means getting a certificate.  Just a whole lot of hoops to jump through for
>> what looks to me to be dubious benefit.
> 
> Well, again PAPPL handles all of this for you, and yes I understand that browsers have totally screwed things up WRT IoT device access - that is something I've been fighting for the last 10 years - but the standards call for web UI because that at least is portable.

Ugh.  Tons and tons of JavaScript or the like.

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

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

Robert,

> On Sep 23, 2021, at 7:54 AM, Robert Krawitz <rl...@al...> wrote:
>> ...
>> No, but having fixed limits does make memory usage *predictable*.
> 
> Well, other than that the underlying driver might not have such predictable memory usage.

Well, I can't do anything about the drivers themselves, just PAPPL. :)

> ...
> So I could have one set of options for the density settings and so forth, and I'm limited to 30 sets
> of options (or one set of options for each group of options, such as Basic Printer Options, Basic
> Color Options, Advanced Color Options 1, and so forth)?  Because that's not what it looked like.

The usual way is for one attribute = one value (or set of values).  Collections allow you to define more complex values.

>> ...
>> You already have a GTK+ UI, and modern web UI has similar capabilities.
> 
> I'd just as soon use the existing GTK+ UI rather than have to write a new web application.

Well, that is ultimately your call.

> Even a local TCP port (http or https://localhost) has its problems, since it means that something
> running under a different UID can access it.  A lot of browsers strongly discourage use of http
> these days, and https means getting a certificate.  Just a whole lot of hoops to jump through for
> what looks to me to be dubious benefit.

Well, again PAPPL handles all of this for you, and yes I understand that browsers have totally screwed things up WRT IoT device access - that is something I've been fighting for the last 10 years - but the standards call for web UI because that at least is portable.

>>> 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.
>> 
>> I'm not sure I understand what you're saying?
> 
> I don't understand what the architecture would look like.  What exactly would this web UI do?

It is there to manage the printer(s) and job(s), print test pages, monitor supply levels, manage ICC color profiles and other resources, and configure defaults/media/etc.

> Where would the back end run?

The printer application *is* the back end.  This is not a cloud-based web server, this is a HTTP/HTTPS service that is hosted by the application courtesy of PAPPL.

> The printing application is a normal binary, presenting a UI.  A web
> application means a server somewhere.

It is NOT a "web application" that you would put up on a web server someplace.  It is an embedded web server running inside the printer application, and that EWS hosts a (simple) web-based user interface - think the CUPS web interface, but simpler.

> Why should there be a web UI in addition to the printing application UI?

Because people are going to be using printer applications as classic RIPs, to share printers with their family and co-workers, etc. And the only way to interact with the printer on the network is via IPP or HTTP/HTTPS.

>>> Where
>>> would the web UI back end run?
>> 
>> It is part of the printer application.  IPP runs over HTTP.  And a web interface is a required part
>> of AirPrint, Mopria, and IPP Everywhere.
> 
> It sounds like this would be separate from the main UI.\

It is a separate component of the same executable.

________________________
Michael Sweet

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

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

On 23/09/2021 03:45, Robert Krawitz wrote:
> 
> 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.
> 

The only restriction which is in the way for us seems to be the number 
of vendor-specific options. I have simply raised it in the source code 
of the PAPPL in my Printer Application Snap and now one has access to 
all options (see my other mail on this list). My Gutenprint Printer 
Application is ready for testing in the Snap Store.

Internally, it uses PPD files, as it is a CUPS-driver-retro-fit type of 
Printer Application, but in the user experience with it, the PPD files 
are completely invisible. So it is some working model to try out how a 
Gutenprint Printer Application based on PAPPL which gives access to all 
the options looks like. It also does the mapping from standard IPP 
attributes to appropriate PPD option settings, allowing both 
sophisticated all-bells-and-whistles printing and printing from 
restricted clients which only use standard IPP attributes and symmetric 
resolutions.

A native Gutenprint Printer Application would have the same 
functionality but without the restriction to what PPDs can represent you 
have much more liberty how to present the options in the web interface.

Please test my Gutenprint Printer Application with different printer 
models and report issues and feature requests, and also post pull 
requests on

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

    Till

[Gimp-print-devel] Gutenprint for Epson L3110

[Iago M. <iag...@gm...>]

Hi,

Do you have any plans on supporting Epson L3110? I get it working using
L310 driver, but the quality and speed print are so low. Thanks for your
help

-- 
Best regards,
Iago Machado Carneiro Leite

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

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

First off, I have made my retro-fitting Gutenprint Printer Application 
supporting the expert PPDs of Gutenprint now.

It uses simplified or expert PPDs depending on how many vendor-specific 
options (PAPPL_MAX_VENDOR) the installed PAPPL supports. If it is 256 or 
more, the expert PPDs are used, otherwise the simplified ones.

In the snapcraft.yaml for my Snap I modify the PAPPL_MAX_VENDOR in the 
PAPPL source code to 256 before compiling PAPPL. I have to build PAPPL 
myself anyway for the Snap, as there is no Ubuntu LTS package of it, I 
want to always have the newest version, I patch it anyway for string 
option support.

So the Snap as it is in the Snap Store now supports all these options! 
And for users of devices with small, simple print dialogs (like phones) 
have the best possible control with standard IPP attributes (which are 
automatically converted to PPD option settings).

Note that on the "Printing Defaults" page of the web interface, the 
options with names and choices written in all-lowercase (starting after 
"Resolution") are the Gutenprint-specific options, the ones at the top 
(names with uppercase first letters) are standard IPP attributes. All 
PPD options appear in a long list and their settings are supplied to the 
command lines of called CUPS filters, especially ratertogutenprint.

To print a fine-art drawing with 5760x2880 dpi on a printer which uses 
this resolution you can set this resolution explicitly via the 
"resolution" Gutenprint option (not the "Resolution" IPP attribute) on 
the "Printing Defaults" page, or you simply set "quality" to "best", 
which sets thhe resolution to 5760x2880 dpi, too, you set the "Print 
Quality" IPP attribute to "High" which sets several options, including 
"resolution=5760x2880dpi" and "quality=best". The input file should be 
ideally sent as vector-graphics PDF.

The Printer Application has also functionality to upscale and downscale 
Raster input, so if a client sends 1440x1440 dpi PWG Raster and the 
print mode is using 5760x2880 dpi, the print data gets upscaled, in a 
fully streaming process to neither require the full 1440x1440-dpi nor 
the full 5760x2880-dpi page in memory.

See more below.

On 23/09/2021 02:51, Robert Krawitz 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.
> 
> That's absolutely true, but it's not a reason to restrict all clients.
>

You can always send a job as PDF and select the desired resolution, and 
Ghostscript renders in that resolution then (see above).

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

All options are available now and should behave as under CUPS. And 
rendering PDF input in high-resolution and up-/down-scaling Apple/PWG 
Raster is no problem.

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

The Printer Application supports both standard IPP job attributes and 
detailed settings. If you client allows only standard attributes you can 
use them, there are reasonable choices of the 6-8 Gutenprint quality 
levels mapped to the three IPP quality levels. If your client gives full 
access to all options (or if you change defaults by the Printer 
Application's web interface) you can yuse the "quality" Gutenprint 
option and selct from all the 6-8 quality levels. In general, if a 
Gutenprint option is set to "automatic-selection" (the default) it 
receives mapping from the print-color-mode, print-quality, and 
print-content-optimize job IPP attributes, any other choice overrides 
the mapping.

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

You do not do it actually. The PDF input file is for example a drawing 
with fine lines, and patterns, all defined as resolution-independent 
vector graphics. The Printer Application uses the same workflow as CUPS 
internally, letting GhostScript render with the resolution selected by 
the driver settings, so no higher resolution than needed (assuming the 
user does not do unreasonable choices on the "Printing Defaults" page).

Photos (JPEG, PNG) you send as-is and the Printer Application converts 
resolution to what the driver requests, APPLE/PWG Raster gets usually 
sent in one of the IPP-reported resolutions, but this print format is 
most probably used by simpler clients and not by clients where you do 
fine-art editing with Inkscape or so, but here also 
resolution-re-scaling will take place as needed.

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

Yes, you will not run this Printer Application on a router (is there a 
router with access to the Snap Store?), but rather on the PC on which 
you are creating your artwork or on a more powerful server (order of 
magnitude of a PC). The memory occupation from PAPPL is negligible, so 
the Snap using the vendor-option-number-enhanced version of PAPPL should 
be no problem. For distros a PAPPL with dynamic resources would really 
come in handy. And the dynamic PAPPL would stay small if it runs a small 
driver (like for label printers).

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

You know the web interface of PAPPL and of my (retro-fitting) Printer 
Applications, which is pretty much the same. On the main page 
(http://localhost:8000/) you see the general options on the left and the 
printers set up on the right. Each button you see leads to a sub-page 
where you can adjust settings, on teh left for the system (the whole 
Printer Application), on the right for each printer, for the 
printer-specific settings. One page I often mention here is the 
"Printing Defaults" page (a printer-specific one) with all the PPD 
options for the printer.

The Gutenprint Printer Application (the retro-fitting one as it is now) 
has exactly the pages provided by PAPPL, the PostScript Printer 
Application has pages added by me, "Add PPD file" on the left (for the 
system) and "Device Settings" at each printer on the right, for 
configuring the installable accessories of the printer. These are the 
web interface pages, and you can add your own ones for the native 
Gutenprint Printer Application.

Simply test my Printer Applications by getting them from the Snap Store.

    Till

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

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

On 9/22/21 9:51 PM, Michael Sweet wrote:
> Robert,
> 
>> On Sep 22, 2021, at 6:47 PM, Robert Krawitz <rl...@al... <mailto:rl...@al...>> wrote:
>>> ...
>>> 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?
> 
> No, but having fixed limits does make memory usage *predictable*.

Well, other than that the underlying driver might not have such predictable memory usage.

>>> 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.
> 
> Understand that how Gutenprint exposes options in PPD files isn't how it has to expose them over
> IPP.  More specifically, IPP has collection attributes (think of them as dictionaries) that cam
> contain any number of (typically related) member attributes. So just because you need to have 30 PPD
> options to describe transfer curves doesn't mean that you have to have 30 IPP attributes.  Group the
> options in IPP collections, and include a member attribute for named presets for these collections -
> that supports stock and custom "easy" settings as well as complete control over a particular
> category of options.

So I could have one set of options for the density settings and so forth, and I'm limited to 30 sets
of options (or one set of options for each group of options, such as Basic Printer Options, Basic
Color Options, Advanced Color Options 1, and so forth)?  Because that's not what it looked like.

> My point is simply that printing resolution != rasterization resolution.  And yes you could report
> 2880x2880 DPI with the current PAPPL, no problem, but you'll need to upsample to 5760x2880 DPI if
> that is the printing resolution a user chooses, being fully prepared to do so from 360 dpi if that
> is what the Client sends you.

Which is perfectly acceptable.

>> 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.
> 
> You already have a GTK+ UI, and modern web UI has similar capabilities.

I'd just as soon use the existing GTK+ UI rather than have to write a new web application.

Even a local TCP port (http or https://localhost) has its problems, since it means that something
running under a different UID can access it.  A lot of browsers strongly discourage use of http
these days, and https means getting a certificate.  Just a whole lot of hoops to jump through for
what looks to me to be dubious benefit.

>> 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.
> 
> I'm not sure I understand what you're saying?

I don't understand what the architecture would look like.  What exactly would this web UI do?  Where
would the back end run?  The printing application is a normal binary, presenting a UI.  A web
application means a server somewhere.  Why should there be a web UI in addition to the printing
application UI?

>> Where
>> would the web UI back end run?
> 
> It is part of the printer application.  IPP runs over HTTP.  And a web interface is a required part
> of AirPrint, Mopria, and IPP Everywhere.

It sounds like this would be separate from the main UI.\

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

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

Robert,

> On Sep 22, 2021, at 6:47 PM, Robert Krawitz <rl...@al...> wrote:
>> ...
>> 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?

No, but having fixed limits does make memory usage *predictable*.

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

Understand that how Gutenprint exposes options in PPD files isn't how it has to expose them over IPP.  More specifically, IPP has collection attributes (think of them as dictionaries) that cam contain any number of (typically related) member attributes. So just because you need to have 30 PPD options to describe transfer curves doesn't mean that you have to have 30 IPP attributes.  Group the options in IPP collections, and include a member attribute for named presets for these collections - that supports stock and custom "easy" settings as well as complete control over a particular category of options.

(honestly you could put everything in a single collection, but I don't think that is actually a good idea)

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

Nothing prevents you from supporting all resolutions.  But modern Clients can typically only rasterize at 1:1 resolutions (certainly this is the case for all AirPrint clients), and Windows' Mopria class driver only supports a small number of resolutions they decide are OK - 300, 360, 600, and 720 dpi right now. (not even the super-common 203dpi of label and some dye-sub printers...)

My point is simply that printing resolution != rasterization resolution.  And yes you could report 2880x2880 DPI with the current PAPPL, no problem, but you'll need to upsample to 5760x2880 DPI if that is the printing resolution a user chooses, being fully prepared to do so from 360 dpi if that is what the Client sends you.

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

You already have a GTK+ UI, and modern web UI has similar capabilities.

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

I'm not sure I understand what you're saying?

> Where
> would the web UI back end run?

It is part of the printer application.  IPP runs over HTTP.  And a web interface is a required part of AirPrint, Mopria, and IPP Everywhere.

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

There is no need for cloud crap.  This is a local application.  Typically only listening on localhost (unless you configure it to share on the local network), and PAPPL is taking care of 99% of the security issues for you. (the other 1% depends on what kind of extra web UI you provide, but for Gutenprint I don't see there being anything that PAPPL doesn't already handle for you...)

________________________
Michael Sweet