Closed Bug 219682 Opened 21 years ago Closed 20 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: 20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.