Closed Bug 219682 Opened 22 years ago Closed 21 years ago

[ps] Freetype print should support PS level 2 as well

Categories

(Core :: Printing: Output, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 234182

People

(Reporter: wolfiR, Unassigned)

Details

(Keywords: intl)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030915 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030915 The current implementation of the freetype2 postscript printing is a little strange to me. If Mozilla is built with freetype2 support and font.FreeType2.printing is true, it seems to create Postscript Level 3? Is this really needed? Most Linux printsystems doesn't filter this if a PS printer is used and many printers are not level 3 printers. As it is possible to filter this via Ghostscript in a Postscript language which can be interpreted by a level 2 printer it must be possible for Mozilla to create this directly, isn't it? Reproducible: Sometimes Steps to Reproduce: 1.
It's possible, but being possible is different from having to do. With most, if not all, Linux printing modules supporting filtering through gs _even_ to a PS printer, I think Mozilla doesn't have to duplicate what can be done with ghostscript. For an alternative, you may take a look at http://www.mozilla.org/releases/mozilla1.5rc1/known-issues-int.html#printing
Of course the printing system could do any prefiltering you like. But in fact for a real PostScript printer no such prefiltering is done and no such prefiltering should be done because Ghostscript prefiltering results a bit lower print quality and loss of some CUPS general filtering functions - see http://sdb.suse.de/en/sdb/html/jsmeix_print-cups-filters.html#PostScript ... 3. ... However, the possibilities of /usr/lib/cups/filter/pstops ... do not always work in connection with PostScript preprocessing. It is is really bad to require the printing system to do Ghostscript prefiltering especially for Mozilla's output because Mozilla can no longer produce THE standard printing language "PostScript Level 2" :-( The solution is a switch in the Mozilla printing dialog which PostScript level it should produce and whether or not to download Asian fonts (like in Acrobar Reader's printing dialog). It is sufficient to offer "Level 2" and "Level 3" (it would be nice if "Level 1" is offered as well to support older PostScript printers). "Level 2" should be the default. When "Level 1" or "Level 2" was selected, Mozilla may use Ghostscript to produce the requested kind of output but this would let Mozilla require Ghostscript to print on normal PostScript printers which looks really strange. By the way: The gs commands like gs -q -sDEVICE=pswrite -sOutputFile=- -dNOPAUSE -dBATCH \ -dLanguageLevel=1 -dMozConvertedToLevel1=true - | lp are insecure. Please use the additional parameter -dPARANOIDSAFER.
Summary: Postscript printing via freetype2 → [ps] Postscript printing via freetype2
A group of users you have in mind is very different from a group of users I have in mind. For my group of users, a PS printer is a novelty and most of them have never seen one. So, it's not a problem at all whether it's PS level1, level2 or level3 because they always have to filter through ghostscript. I'm not saying that we can ignore your group of users (those 'lucky' ones with access to PS printers at school and work). However, it's not a pretty low prirority issue from my point of view. There are other printing issues to deal with (see, for instance, bug 190031) that are more important. Why did bstell (the original implementor of freetype printing) choose PS level 3? I can only guess but that's probably because it's easier that way to 'embed' truetype fonts with more than 256 glyphs. Actually, truetype outlines are converted to PS outlines before being embedded and are wrapped as CID-keyed font (type 9 font). His original plan was to embed truetype outlines (without converting to PS outlines) and wrap them as CID-keyed font (type 11). To generate PS level 2 output, a truetype fonts with more than 256 glyphs have to be fragmented into multiple small fonts and embedded as type 42 fonts (or converted to type 1 fonts).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: intl
Summary: [ps] Postscript printing via freetype2 → [ps] Freetype print should support PS level 2 as well
You cannot use PS Type42 fonts with PostScript Level 2. I tried that myself with Xprint's server side (which now supports PS Type1 and PS Type3 font download) and failed horribly because most printers on the market either do not support PS Type42 fonts or crash the printer firmware due bugs in the early implementations of the support for that in the Adobe engine (the same problems are responsible that FreeType font embedding used by the PostScript module fails on most old printers).
Wolfgang, sorry to resolve this as a dupe of bug 234182 that was filed later than this (please, add yourself to Cc there), but it has more relevant stuff than this. After finding out that HP LJ (with PS level 2 only) and ghostscript 7.x combination has some problems (as we discussed elsewhere. My Xerox printer doesn't have such a problem), I'm now convinced that we have to produce level 2 output. *** This bug has been marked as a duplicate of 234182 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.