[ps] printing iso-8859-2 fails

RESOLVED DUPLICATE of bug 63737

Status

()

Core
Printing: Output
RESOLVED DUPLICATE of bug 63737
17 years ago
15 years ago

People

(Reporter: Masaki Katakai, Assigned: dcone (gone))

Tracking

({intl})

Trunk
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments)

(Reporter)

Description

17 years ago
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.
(Reporter)

Updated

17 years ago
Keywords: intl
(Reporter)

Updated

17 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 1

17 years ago
hramrach,

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

Thanks.
(Reporter)

Comment 2

17 years ago
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.
(Reporter)

Comment 3

17 years ago
Created attachment 37867 [details]
snapshot: hramrach, is this OK?
(Reporter)

Comment 4

17 years ago
Created attachment 37868 [details] [diff] [review]
proposed patch
(Reporter)

Updated

17 years ago
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.
(Reporter)

Comment 6

17 years ago
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

17 years ago
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.
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.
(Reporter)

Comment 9

17 years ago
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?
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). 
(Reporter)

Updated

17 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3
(Reporter)

Comment 13

17 years ago
hramrach, thanks for the info.

Do you have good examples for PostScript codes?
(Reporter)

Comment 14

17 years ago
Created attachment 39080 [details]
store to mozilla.ps.gz
(Reporter)

Comment 15

17 years ago
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?
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.
(Reporter)

Updated

17 years ago
Target Milestone: mozilla0.9.3 → Future
(Reporter)

Comment 17

17 years ago
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

17 years ago
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.
(Reporter)

Comment 20

17 years ago
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.
Assignee: katakai → rods
Status: ASSIGNED → NEW
(Reporter)

Comment 21

17 years ago
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?
(Reporter)

Comment 22

17 years ago
Created attachment 70869 [details]
jpg image of outputs - replaced with times fonts with iso-8859-2 fonts

Comment 23

16 years ago
Created attachment 83490 [details]
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

16 years ago
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/

Updated

16 years ago
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.

Comment 26

16 years ago
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.

Comment 28

16 years ago
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...
(Reporter)

Comment 29

16 years ago
This should be marked as dup. Already fixed.

Comment 30

16 years ago
-->
Assignee: rods → dcone
(Reporter)

Comment 31

16 years ago
I understand we have already fixed this bug.

Comment 32

15 years ago

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