cupstestppd should also report on incompatibilities with Windows clients #163

Closed
michaelrsweet opened this Issue Jun 21, 2003 · 6 comments

Projects

None yet

1 participant

@michaelrsweet

Version: 1.1.19
CUPS.org User: till.kamppeter

Recent reports show that absolute Adobe-conformity (according to "cupstestppd") is not enough for a PPD file to work correctly with the PostScript drivers for Windows. In case of PPD files generated by Foomatic 3.0.x (linuxprinting.org) there is no complaint by "cupstestppd" and Windows drivers choke on having UI strings longer than 40 characters or having "," and/or "+" in the *Nickname and *ShortNickname.

So I make the following suggestion:

Investigate which Windows drivers (Microsoft, Adobe, CUPS) cause which problems.

If a problem is unique to the CUPS driver, fix the CUPS driver if the PPD is really Adobe-conforming, otherwise fix "cupstestppd" to report the issue as non-Adobe-conforming.

If a problem occurs also or only with the Microsoft or Adobe drivers, add optional checks to "cupstestppd" to check also compatibility to these drivers. The extra checks could be activated by a command line switch ("-w=adobe", "-w=ms", "-w=all" ...) and in the web interface by checkboxes.

@michaelrsweet

CUPS.org User: mike

This is an issue with the current CUPS driver for Windows, but it should not be an issue for the Adobe driver nor will it be for the new CUPS driver for Windows which is based upon the modular Win2k PS driver...

@michaelrsweet

CUPS.org User: till.kamppeter

What does it mean?

  • Should I modify the whole Foomatic database to not contain any string longer than 40 characters?

  • Or should I write into the linuxprinting.org site documentation that the Adobe driver is required for use of Foomatic PPD files?

@michaelrsweet

CUPS.org User: mike

It means that you should, for now, advise those using the Foomatic PPD files to use the Adobe driver. Since Foomatic hides all of the JCL stuff, they will still have the same print accounting capabilities with the Adobe driver.

There isn't anything we can easily do with the old NT PS driver, and we really feel that that is a dead-end. The new 2k PS driver does not have this problem, and we are basic the new CUPS driver on the Win2k driver.

@michaelrsweet

CUPS.org User: till.kamppeter

I have updated linuxprinting.org appropriately now. Primarily I recommend the Adobe driver, but for users of the CUPS driver there is now a possibility to get PPDs with the GUI strings cut off. On the driver pages of the site one simply needs to check "GUI texts limited to 39 characters" and with the commands "foomatic-configure" and "foomatic-ppdfile" one uses the "-w" option (current CVS of "foomatic-db-engine" package).

In the instructions for setting up a printer with CUPS

http://www.linuxprinting.org/cups-doc.html

this is mentioned.

@michaelrsweet

CUPS.org User: h.blischke

Do you know that the current user mode driver supplied
with latest WinXP (including latest service pack) has a
serious bug concerning Type1 fonts which have the"symbolic
encoding" flag (0x02) set in the corresponding PFM file?

Any characters to be shown with such a font are replaced
by the code that represents the bullet in WinAnsi encoding;
the result is that nothing gets printed, as these fonts
usually don't have a bullet glyph in this code place.

@michaelrsweet

CUPS.org User: robert.krawitz

The native Gimp-Print CUPS PPD's (in 4.3) look like this:

*NickName: "EPSON Stylus Photo 960 - CUPS+Gimp-Print v4.3.21"

Should we fix this to remove the "+"?

@michaelrsweet michaelrsweet added this to the Stable milestone Mar 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment