From: Solomon P. <pi...@sh...> - 2017-10-19 05:41:15
|
On Wed, Oct 18, 2017 at 03:53:08PM -0400, Robert Krawitz wrote: > which the drivers can delegate in whole or in part back to the core > using its own master list of standard paper sizes (if you look at the > printfuncs in a lot of the family drivers, most of them delegate a lot > of things back to the core). Yeah, the dyesub driverreuses a bit less of the core. > Also, the standard vs. extended thing is a useful UI hint. It's > particularly important for dyesub and dedicated label printers, which > have a set of "standard" sizes that are very different from what most > printers use. I was thinking only about the distinction made in the "simplified" PPDs; the dyesub printers would want all of their sizes to be marked as "standard" so none would get dropped by a simplified PPD or hidden by the UI. (Ideally the UI could filter that list against what's loaded in the printer, but I think that's asking WAY too much...) While waiting for a test to run here, I deicded to take a crack at portin the dyesub driver to the API in your papersize patch. I rapidly ran into a bit of a snag. basically the describe_papersize() call is supposed to return a const stp_papersize_t struct, but the dyesub driver doesn't acutally use that struct internally; all of its custom sizes are defined in terms of dyesub_pagesize_t, which has some, but not tcomplete, overlap with the papersize_t structure. It may make sense to encapsulate a stp_papersize_t structure inside the pagesize_t definition, but that's going to create a ton of mechanical churn for all of those static definitions. The other options all seem worse. (sorry about typos; horribly laggy connection here) - Solomon -- Solomon Peachy pizza at shaftnet dot org Coconut Creek, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |