ppdLocalize: Also translate some global ppd properties #5303
Conversation
There's quite a few ppds out there with translations for Manufacturer, ModelName, ShortNickName and NickName so use them
|
@michaelweghorn This should fix the problem you're having with the PDF-Drucker.ppd file you sent me. |
|
Will consider this, but PPDs have been deprecated for over 10 years now... |
|
I understand, and this is kind of off topic here, but i'll ask anyway, how are we supposed to get the same level of functionality if not using ppd? |
|
Modern printers (basically anything sold since 2010) support IPP-based printing using standard formats - we really only "need" PPDs for older printers and special use printers that haven't yet adopted IPP - mainly industrial (label/POS/kiosk) and things like those 2x3" mobile (bluetooth) photo printers. I'll be presenting an alternative to PPDs at the 2018 Open Printing summit next month that uses the ippserver sample code to create "printer applications" that can be used by any CUPS client since CUPS 1.4. |
@albert-astals-cid-kdab It does. Thanks!
@michaelrsweet I'm really looking forward to hearing more about this then. In the current situation, we unfortunately had to take the difficult decision to stick with the deprecated APIs after careful evaluation. We had the practical problem that devices did not provide all of their options via IPP, even though many of them had some support for IPP. (Corresponding IPP attributes did exist in the specification in the cases I had a closer look at, but were not supported/exposed by the devices.) This included rather new printers as well. It would be great to have a way to finally be able to drop obsolete and deprecated APIs without losing functionality. |
|
@michaelweghorn The printer application method is more targeted at printers that don't support IPP at all or do it so badly we can't use them directly. Newer printers that don't implement all of their functionality via IPP will (unless somebody cares deeply enough about it to write it themselves) need a firmware update from the printer vendor. Firmware updates are somewhat likely for longer-lived office MFPs, which is (coincidentally) where we see these sorts of gaps between IPP and printer drivers - really depends on how much customer feedback they get (so they know the IPP functionality is important...) |
|
@michaelrsweet For those specific MFPs with insufficient support for IPP attributes, we did actually contact the vendor/supplier and got a list of IPP attributes that are currently supported and the information that they might have a look at implementing more if we were willing to pay. Given that even the new devices were problematic and there is a multitude of the "printers that don't support IPP at all or do it so badly we can't use them directly" around as well, we "gave up" at this point and decided to stick with the deprecated APIs for now. Is that printer application method some kind of "wrapper" to be able to use PPD-based printers just like "real" IPP printers? That would be great in my opinion, since it would make the "nasty stuff with the deprecated things" be done in one place and allow frameworks/applications to finally migrate to the new APIs and still use the old printers and their functionality. |
|
@michaelweghorn The printer application could provide a PPD-based wrapper, however it would still suffer from the same limitations of the current CUPS WRT mapping IPP's "job-password" attribute to whatever PPD option(s) are used by the driver. An alternative would be for a vendor (or third party) to support a printer application for those printers, with the printer-specific bits being described in a different way, internally, and exposed externally as the "job-password" attribute. I'm hoping to provide some examples/sample code in the PWG's ippsample project so that it is relatively easy to deploy this sort of solution. |
|
@michaelrsweet: Thanks for the update! |
|
friendly ping about getting this merged :) |
|
@albert-astals-cid-kdab At this point we are debating the merit of "fixing" this issue; these fields were never meant to be localized and PPDs have been deprecated for a very long time. I should have a final answer for you in the next month or so. |
|
Sorry, we've decided that we won't be localizing these fields. |
There's quite a few ppds out there with translations for Manufacturer, ModelName, ShortNickName and NickName so use them