19 | | The "*Resolution" keyword _must_ be followed by a numeric value (e.g. |
20 | | 360x360). Using 'None' sets dots-per-inch to zero, causing a trap |
21 | | when the driver tries to do some scaling operation. Changing |
22 | | "*DefaultResolution"" to one of the other values listed & eliminating |
23 | | the "*Resolution None" line fixes the issue. |
| 15 | Fixing this causes a non-fatal conflict. For many printers, CUPS uses its "*!StpQuality" keyword to set DPI. Forcing "*Resolution" to be valid (because the IBM driver demands it) causes whatever value "*!StpQuality" set previously to be overridden. These two entries will have to be reconciled (knowing what "/cupsCompression" & "/cupsRowFeed" do would help). |
25 | | Fixing this causes a non-fatal conflict. For many printers, CUPS uses |
26 | | its "*StpQuality" keyword to set DPI. Forcing *Resolution to be valid |
27 | | (because the IBM driver demands it) causes whatever value *StpQuality |
28 | | set previously to be overridden. These two entries will have to be |
29 | | reconciled (knowing what "/cupsCompression" & "/cupsRowFeed" do would |
30 | | help). |
| 17 | 2. The entries which control DPI '''have''' to be set identically in the driver's Properties pages & in the ''Set Printer Options'' web page. If they're not, the output is scaled incorrectly. I had the driver using 8pt type but it was printing out at 24pt. Eventually I found that the driver was set to 360x360 while CUPS itself was set to 360x120. |
32 | | 2- The entries which control DPI *have* to be set identically in the |
33 | | driver's Properties pages & in the "Set Printer Options" web page. |
34 | | If they're not, the output is scaled incorrectly. I had the driver |
35 | | using 8pt type but it was printing out at 24pt. Eventually I found |
36 | | that the driver was set to 360x360 while CUPS itself was set to |
37 | | 360x120. |
| 19 | 3. "*!LanguageEncoding: UTF-8" is a non-issue - at least for Western European languages. AFAICT, the first 256 characters of UTF-8 are IsoLatin1. Change this manually & ppdenc works great. In any case, the only non-CP850 character I found in my PPD (0xD7) translated to a multiplication sign. It's used in some of the paper sizes (e.g. 4x6). I used a search & replace to change them to lowercase 'x' before running ppdenc. The only difference between before & after was "IsoLatin1" became "OS2-850". |
39 | | 3- "*LanguageEncoding: UTF-8" is a non-issue - at least for Western |
40 | | European languages. AFAICT, the first 256 characters of UTF-8 are |
41 | | IsoLatin1. Change this manually & ppdenc works great. In any case, |
42 | | the only non-CP850 character I found in my PPD (0xD7) translated to a |
43 | | multiplication sign. It's used in some of the paper sizes (e.g. 4x6). |
44 | | I used a search & replace to change them to lowercase 'x' before |
45 | | running ppdenc. The only difference between before & after was |
46 | | "IsoLatin1" became "OS2-850". |
| 21 | 4. On the ''Output'' page of the driver's job properties, ''Use printer device fonts'' has to be unchecked (at least when printing plain-text files). If not, I get this error: "[Job 38] /invalidfont in findfont". OS/2's lpd then reports that it got an invalid size for the file it received and aborts the print job. The primary downside to this is that the PS files get monstrously large because they require the font to be embedded. |
48 | | 4- On the 'Output' page of the driver's job properties, "Use printer |
49 | | device fonts" has to be unchecked (at least when printing plain-text |
50 | | files). If not, I get this error: "[Job 38] /invalidfont in findfont". |
51 | | OS/2's lpd then reports that it got an invalid size for the file it |
52 | | received and aborts the print job. The primary downside to this is |
53 | | that the PS files get monstrously large because they require the font |
54 | | to be embedded. |
| 23 | 5. PPD keywords that don't have any Postscript code associated with them are not emitted by the driver, e.g.: |