generated EpsonWF3540.ppd has UTF-8 ″ symbol, print dialogs garble it

[skierpage]

Describe the bug
In both LibreOffice and Okular's print dialog, in the properties for my Epson WF3540 printer type "EPSON WF-3540 Series, driverless, cups-filters 1.28.15", > Page > Page size have garbled characters, e.g. 3.5 x 5 â(³. This is what the UTF-8 double prime '″' "inch" symbol degrades to when interpreted as the ISO 8859 encoding, and there are UTF-8 ″ symbols in my PPD for this printer.

To Reproduce
Steps to reproduce the behavior:

1. Add Epson WF-3540 printer in Linux
2. Print from an application
3. Click [Properties] > Page > Page size.
4. Note garbled page size options in the pop-up menu.
5. Look at /etc/cups/ppd/EpsonWF3540.ppd, note how it has UTF-8 '″' inch symbols in *PageSize lines.

Expected behavior
The ″ symbol should appear as that, or as the plain double-quote.

Screenshots

System Information:

• OS: Linux
• Browser: Firefox
• Version 2.4.7

Additional context
The filer of bug #503 comments " PPD standard states that all the .ppd lines must be in English in ISOLatin1 encoding". This one obviously isn't. There is no double-prime mark glyph in ISO Latin 1. I think cups created the "driverless" PPD file in June 2022 when I added the printer in KDE.

[tillkamppeter]

Do the other print dialogs (GNOME/GTK, Firefox, Thunderbird, Chromium Browser) and printer setup tools (GNOME Control Center, KDE settings, system-config-printer, CUPS web interface) show the UTF-8 double prime correctly?

[skierpage]

Thunderbird, Cups web interface (see screenshot below), KDE Configure Printer all show the garbled â something ³ characters in place of the double prime.

I read up a bit. Using the output of ippfind -l, driverless ipp://localhost/printers/EpsonWF3540f outputs a PPD with the same *LanguageEncoding and *PageSize lines with the UTF-8 double prime as my /etc/cups/ppd/EpsonWF3540.ppd (the former is `*FileVersion: "2.0.0" , the latter 1.28.15). E.g.:

*LanguageEncoding: ISOLatin1
...
*PageSize 3.5x5/3.5 x 5″: "<</PageSize[252 360]>>setpagedevice"

The print property dialogs are using the string after the / which has the UTF-8 double prime, which seems to conflict with the LanguageEncoding line (!). With the --debug option, stderr from driverless includes

DEBUG2:   Attr: attributes-charset
DEBUG2:   Value: utf-8
DEBUG2:   Keyword: utf-8

It seems all my programs' print dialogs are assuming the charset is some flavor of ISOLatin1.