Re: Gutenprint Printer Application (Native)

Robert,

> On Sep 23, 2021, at 6:06 PM, Robert Krawitz <[email protected]> wrote:
> 
> On 9/23/21 5:34 PM, Michael Sweet wrote:
>> Robert,
>> 
>>> On Sep 23, 2021, at 7:54 AM, Robert Krawitz <[email protected]> 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