Menu
▾
▴
gimp-print-devel
|
From: Michael S. <ms...@ms...> - 2021-09-24 01:45:46
|
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 |
|
From: Robert K. <rl...@al...> - 2021-09-26 15:12:25
|
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. |
|
From: Till K. <til...@gm...> - 2021-09-26 15:59:59
|
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
|
|
From: Solomon P. <pi...@sh...> - 2021-09-26 21:31:41
Attachments:
signature.asc
|
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) |
|
From: Till K. <til...@gm...> - 2021-09-26 21:42:10
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X