82982 - [ps] printing iso-8859-2 fails

Status: RESOLVED DUPLICATE of bug 63737

(Core :: Printing: Output, defect)

Description

[Masaki Katakai]

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.

Comment 1

[Masaki Katakai]

hramrach,

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

Thanks.

Comment 2

[Masaki Katakai]

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.
iso-8869-2.

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.

Comment 3

[Masaki Katakai]

Attachment: snapshot: hramrach, is this OK?

Comment 4

[Masaki Katakai]

Attachment: proposed patch

Comment 5

[Michal 'hramrach' Suchanek]

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.

Comment 6

[Masaki Katakai]

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?

Comment 7

[Bryce Nesbitt]

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

Example:
	Wroc?awia

The letter between c and a comes out as superscript 3 in iso-8859-1,
and l-slash in iso-8859-2.

Comment 8

[Michal 'hramrach' Suchanek]

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.

Comment 9

[Masaki Katakai]

Thanks.

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?

Comment 10

[Michal 'hramrach' Suchanek]

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.

Comment 11

[Michal 'hramrach' Suchanek]

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.

Comment 12

[Michal 'hramrach' Suchanek]

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). 

Comment 13

[Masaki Katakai]

hramrach, thanks for the info.

Do you have good examples for PostScript codes?

Comment 14

[Masaki Katakai]

Attachment: store to mozilla.ps.gz

Comment 15

[Masaki Katakai]

I've attached the example codes of mozill.ps 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?

Comment 16

[Michal 'hramrach' Suchanek]

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.

Comment 17

[Masaki Katakai]

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.

Comment 18

[Roland Mainz]

3rd solution: Use Xprint module ...

Comment 19

[Michal 'hramrach' Suchanek]

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.

Comment 20

[Masaki Katakai]

Rods,

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.

Comment 21

[Masaki 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?

Comment 22

[Masaki Katakai]

Attachment: jpg image of outputs - replaced with times fonts with iso-8859-2 fonts

Comment 23

[Roland Mainz]

Attachment: http://www.ms.mff.cuni.cz/index.html.cz.iso-8859-2 printed using 2002-05-08-08-trunk + Xprint module (DIN A4, 300 DPI, background colors+images enabled in page setup dialog)

Reporter:
Does the attached page print OK for you ?

Comment 24

[Roland Mainz]

Details how to install/use Xprint are available under http://xprint.mozdev.org/
or http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/

Comment 25

[Michal 'hramrach' Suchanek]

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.

Comment 26

[Roland Mainz]

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...) ?

Comment 27

[Michal 'hramrach' Suchanek]

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.

Comment 28

[Roland Mainz]

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...

Comment 29

[Masaki Katakai]

This should be marked as dup. Already fixed.

Comment 30

[rods (gone)]

-->

Comment 31

[Masaki Katakai]

I understand we have already fixed this bug.

Comment 32

[Vaclav Dvorak]

*** This bug has been marked as a duplicate of 63737 ***