Closed Bug 82982 Opened 24 years ago Closed 21 years ago

[ps] printing iso-8859-2 fails


(Core :: Printing: Output, defect)

Not set





(Reporter: masaki.katakai, Assigned: dcone)




(Keywords: intl)


(5 files)

This bug is from bug 53477. The page can not be printed out properly.

All UNICODE characters (it means except ascii characters) will be
drawn by mbshow() so some iso-8859-2 characters are also mapped to
UNICODE, then will be printed as UNICODE. But those should be
handled as ascii code range. I understand PostScript fonts are
modified for iso-8859-2 in ascii range. We should output as ascii
code point.
Keywords: intl

can you provide the font list of PostScript for iso08859-2?

The current codes assume 2 bytes for native code points. So when the code after
conversion from
UNICODE is 1 byte, the code can not be printed.

-         if (NS_SUCCEEDED(res) && outsize > 1) {

This line should be

+         if (NS_SUCCEEDED(res) && outsize > 0) {

when we consider non asian character set e.g.

After the change, I tried with the following prefs,

user_pref("print.psnativecode.x-central-euro", "ISO-8859-2");
user_pref("print.psnativefont.x-central-euro", "LucidaBrightLat2");

I got a correct result. (I'll attach the snapshot)

Yes, we still have problem GetWidth() for those
ISO-88669-2 characters and we should find out
possible solution. I will file new bug.
Attached patch proposed patchSplinter Review
Target Milestone: --- → mozilla0.9.2
First of all, I was unable to view the attachment with current Mozilla.
When I saved it and displayed, the text is quite correcty rendered. 
However, there are still some problems:
- bad layout (probably the GetWidth problem)
- multiple fonts - this I get sometimes when viewing czech pages in some
browsers (I think Mozilla doesn't do this). The special characters zcaron,
scaron, rcaron, tcaron, ... are rendered in differen font, which is ugly and 
shouldn't happen. It may be that all the other characters are errornously
rendered in different font as they should be available in the iso-2 font.
Yes, we should provide proper GetWidth() for such UNICODE code
points for the first problem. I'll file new bug report.

For the second problem, I think this is dup of bug 52420.
Currently, we can set only one font for the language group.

Anyway, I think this patch would be valuable, not?

I have the same problem.  The iso-08859-2 characters show up fine
on screen.  But they print as boxes on the printer.


The letter between c and a comes out as superscript 3 in iso-8859-1,
and l-slash in iso-8859-2.
Yes, this patch adds the abily to print iso-2 characters, which is valuable and
should be merged.
No, this is NOT bug 52420. The iso-2 font supplies *all ascii characters* and
there's no reason to take these from other fonts. Thus having more iso-2 fonts
configured would be nice feature but it's not neccessary for correct
(single-font) output.

I want to ask you what the correct fonts for iso-8859-2 are.
For example, "Times-Roman" on iso-8859-2 printers contains
all ascii and iso-8859-2 glyphs? I mean I want to know
I can use the same font name for iso-8859-2. Do you know?
To clear things up: I think that page in iso-2 should be *all* printed using
primarily an iso-2 font, and characters missing in iso-2 could be looked up in
fonts configured for different encoding corresponding to the iso-2 font.
(ie. Times-*iso-2 ~ Times-*iso-1 ~ Times-*iso-9).
This means that the iso-1 enconding should be in no way special. Fonts
configured for this encoding should be used only for pages (or parts of pages)
that specify iso-1 encoding and special characters (I think one of them could be
Yen) missing from other encodings. Reading 52420 and examining attachment
06 [details]/10/01 20:32 makes me think iso-1 fonts are always used and only characters
missing from default iso-1 fonts (possibly most characters as in Japanese) are
taken from other fonts.
Masaki Katakai: That's what I wanted to say: all 7-bit characters in iso-1 and
iso-2 are the same. Moreover, iso-2 contains characters that are in iso-1 but
possibly encoded on different position (I think some of these are eacute iacte
aacute). To get correct characters for the web page, you should probably not
need any iso-1 characters.
To the font names: It should be possible to draw iso-2 fonts of any type for
which iso-1 fonts exist but only few are actually drawn. 
On the other hand if fonts of the same name exist for more encodings, it should
look the same (except for the special chars, of course). 
Target Milestone: mozilla0.9.2 → mozilla0.9.3
hramrach, thanks for the info.

Do you have good examples for PostScript codes?
Attached file store to
I've attached the example codes of edited by hand.

What I did here are

1. build fonts with iso-8859-2 encoding
2. switch to the font from default iso8859-1 font when
   x-central-euro language group is specified

There are still GetWidth() problems but do you think
this is correct way?  hramrach, can you evaluate the
PS codes?
Well, I'm not very often online, so try to be patient.
I think this is the right way - scaron, zcaron, aacute and iacute are rendered
correctly and using same font as the rest of the page.
tcaron, ecaron, ccaron, and some character in the date in page footer aren't
rendered but I expect it would be rendered well in case all character
definitions were edited properly. 
I don't know PostScript myself and any working postscript files I can think of
are output of dvips, which seem to have some sort of embedded fonts.
Another working example is StarOffice. As far as I know, in this case the
PostScript font is dispalyed using corresponding display font (including
encoding), and no translation is done on the characters. Thus character encoded
on position 225 in displayed text matches character encoded on the same position
in priter font (in case you configured the thing correctly). StarOffice itself
beleives it works in iso-1 all the time and knows nothing about different encodings.
Target Milestone: mozilla0.9.3 → Future
One solution is to use native PS font which contains iso-8859-2 glyphs,
the other solution is to embed PS codes of the glyphs into PostScript.
3rd solution: Use Xprint module ...
I do not know Xprint but I would suggest optional embedding of the fonts.

Currently I print from original netscape in three steps

1) print into file

2) edit the encoding inside the file 

3) find a system where fonts for all characters are available for printing/displaying

Not embedding the fonts has the advantage that resulting postscript may be smaller. Embedding the glyphs has the advantage that the postscript is independent on the environment.

You are working on bug 100324 and bug 100328. Can you take this one
please? If this problem can be fixed by your changes, please mark
this as dup.

Thank you.
Assignee: katakai → rods

I think we have fixed this problem. I tried the test URL
with iso-8859-2 PostScript fonts, I got the correct outputs.
Can you mark this as bug?
Summary: printing iso-8859-2 fails → [ps] printing iso-8859-2 fails
I do not know about xprint but I get postscript that looks fine by printing to
default the postscript printer. Using 2002-40-23-21 on Linux.
hramrach wrote:
> I do not know about xprint but I get postscript that looks fine by printing to
> default the postscript printer. Using 2002-40-23-21 on Linux.

Did you use any extra fonts (AFAIK this will not work properly for all glyphs
without having the correct fonts...) ?
I use Mandrake Linux which includes some URW fonts that contain iso1 and iso2
lyphs in the same file. From my fonts.dir file:
n021003l.pfb -URW-Times-medium-r-normal--0-0-0-0-p-0-iso8859-1
n021003l.pfb -URW-Times-medium-r-normal--0-0-0-0-p-0-iso8859-2
n021004l.pfb -URW-Times-bold-r-normal--0-0-0-0-p-0-iso8859-1
n021004l.pfb -URW-Times-bold-r-normal--0-0-0-0-p-0-iso8859-2
I used to install (some earlier version of?) these by hand when I was using
RedHat 6.
There are some adobe and b&h fonts in different directory that have glyphs for
more encodings:
couri.pfa -adobe-courier-medium-i-normal--0-0-0-0-m-0-iso8859-1
couri.pfa -adobe-courier-medium-i-normal--0-0-0-0-m-0-iso8859-2
couri.pfa -adobe-courier-medium-i-normal--0-0-0-0-m-0-iso8859-3
couri.pfa -adobe-courier-medium-i-normal--0-0-0-0-m-0-iso8859-9
courb.pfa -adobe-courier-bold-r-normal--0-0-0-0-m-0-iso8859-1
courb.pfa -adobe-courier-bold-r-normal--0-0-0-0-m-0-iso8859-2
courb.pfa -adobe-courier-bold-r-normal--0-0-0-0-m-0-iso8859-3
courb.pfa -adobe-courier-bold-r-normal--0-0-0-0-m-0-iso8859-9
but I doubt these are ever used.
hramrach wrote:
> but I doubt these are ever used.

You can check that, search the PostScript job for the string "BeginFont". This
indicates the start of a font which is embedded within the PostScript job...
This should be marked as dup. Already fixed.
Assignee: rods → dcone
I understand we have already fixed this bug.

*** This bug has been marked as a duplicate of 63737 ***
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.