144317 - Printing justified text with non-ASCII characters mangles spacing

Status: RESOLVED WORKSFORME

(Core :: Printing: Output, defect, P1)

Description

[Hrvoje Niksic]

[ This is in 1.0 RC2, but also in all previous versions. ]

When Mozilla prints justified text that contains non-ASCII characters, it
apparently inserts spacing after those characters.  It seems that Mozilla is
treating the non-ASCII characters as equivalent to white space, and is trying to
"pad" them to achieve justification.

How to repeat: Take the attached HTML file and try to print it to file.  View
the file with a PostScript viewer and you will notice that the non-ASCII
characters are followed by spacing which is not present in the HTML source.

NOTE: to see this, you *have* to print the page, either to file or to a printer.
 The bug will *not* show up during normal browsing or in Print Preview. 
Apparently the problem occurs only in PostScript form.  Also, the text must be
justified.

I am not sure if the problem occurs with non-ASCII charsets other than Latin 1
and Latin 2, or even if it occurs for all characters in these two charsets.  The
bug is pretty severe for international users because it makes correct printing
of justified Latin 1 and Latin 2 texts impossible from Mozilla.

Comment 1

[Hrvoje Niksic]

Attachment: HTML file exhibiting the problem

Comment 2

[Roland Mainz]

Attachment: Testcase (attachment 83440) printed with 2002-05-08-08-trunk and Xprint module (DIN A4, 300DPI)

Reporter:
Does the attached PostScript job print OK for you ?

Comment 3

[Hrvoje Niksic]

The PostScript file you've attached has a different (and worse) buf: it does not
seem to display Latin 2 characters at all!

The Latin 1 characters are spaced out ok, though.

Comment 4

[Jiri Smitka]

I think this bug is the same as bug #143637. 

Comment 5

[Hrvoje Niksic]

Jiri, you are correct.  It is the same bug, except of course that the
misbehavior is not limited to Scandinavian letters.  As far as I'm concerned,
this one can be marked as a dup.  (Although it would be nice to preserve my test
case which also includes Latin 2 characters.)

By the way, both bugs are still marked as UNCONFIRMED.  What does it take to
change that?

Comment 6

[Roland Mainz]

Hrvoje Niksic wrote:
> The PostScript file you've attached has a different (and worse) buf: it does 
> not seem to display Latin 2 characters at all!

Uhm, that's my mistake - I did not add any Latin-2 fonts to the fontpath...

Comment 7

[Roland Mainz]

Attachment: Testcase (attachment 83440) printed with 2002-06-07-08-trunk and Xprint module (DIN A4, 300DPI); now with ISO-8859-2 fonts in the fontpath

Reporter:
Does this attachment now print correctly for you (sorry for the previous job, I
did not look at the locale and did not compare the screen output with the print
job) ?

Comment 8

[Hrvoje Niksic]

The glyphs displayed where Latin 2 characters should be are not correct.  They
seem to be coming from a wholly different font, with the result that some
viewers (gv) can't show them at all, that the line spacing is wrong, and that
the characters, even when you see them, are larger than the surrounding text. 
Also, spurious spacing is still inserted after some characters, as in the
original report.

To see what the Latin 2 example *should* look like, just view my original
attachment using Mozilla, which shows them correctly.  The difference should be
clear even without any knowledge of the language.

Comment 9

[Roland Mainz]

Hrvoje Niksic wrote:
> The glyphs displayed where Latin 2 characters should be are not correct.  They
> seem to be coming from a wholly different font, with the result that some
> viewers (gv) can't show them at all

Uhm... is it possible that this is a "gv"-bug ? I noticed that some versions of
gv cannot handle fonts which are downloaded to the printer (e.g. are embedded in
the print job).

I'll attach a GIF from Solaris sdtimage (CDE image/PostScript viewer (not
GhostScript-based =:-)) ...

Comment 10

[Roland Mainz]

Attachment: GIF image of PostScript job (attachment 87041), 283% zoom (e.g. (85 DPI / 300 DPI)*1000)

Comment 11

[Drazen Kacar]

No, Roland, it does not print correctly. It's a very **** PostScript document,
and it's quite obvious that it will never, ever print something decent.

/Times-Roman 57 t Tf
(a) 1474 432 T
gr gs
225 225 2030 3057 R
cl n
0 g
/Times-Roman 57 t Tf
(u) 1499 432 T
gr gs
225 225 2030 3057 R
cl n
%%BeginFont: LucidaBrightLat2
%!PS-AdobeFont-1.0: LucidaBrightLat2-Italic 001.100
11 dict dup begin
  /FontInfo 9 dict dup begin
    /FamilyName (LucidaBrightLat2) def

Etc. Why it wants to switch from Times to LucidaBright is beyond me. The viewers
are showing the **** because they are supposed to show the ****.

Comment 12

[Hrvoje Niksic]

I know about sdtimage.  If you take a look at your GIF, it will become apparent
that it is not correct.  The Latin 2 characters are larger than the surrounding
text, the line spacing is wrong, and bogus spacing is inserted after ć.

Comment 13

[Roland Mainz]

Drazen Kacar wrote:
> No, Roland, it does not print correctly. It's a very crappy PostScript 
> document,

What problems do you see beyond the issue that we use the "wrong" fonts ?

> and it's quite obvious that it will never, ever print something 
> decent.

Can you be a little bit more specific about this, please ?

> Etc. Why it wants to switch from Times to LucidaBright is beyond me. The 
> viewers are showing the crap because they are supposed to show the crap.

That's simple to answer. Our fontmetrics system (GTK+/Xlib/Xprint all use the
same code) looks for User-defined fonts, CSS spec, language prefs and font
prefs.
Since none of these is set on my system or defined by the testcase it uses the
first "hit" in the font list which matches the encoding - and that's
LucidaBright for ISO-8859-2.
Setting the font to a specific font like "Courier" either in the prefs, via CSS
etc. seems to fix the problem.

The problem in this case seems to be that there is no spec what font should be
picked here - and without such a spec it always fetches the first match it
finds...

Comment 14

[Roland Mainz]

Attachment: Testcase (attachment 83440) printed with 2002-06-07-08-trunk and Xprint module (DIN A4, 300DPI); with ISO-8859-2 fonts in the fontpath and "Courier" set as default font in the prefs

Comment 15

[Roland Mainz]

Comment on attachment 87047 [details]
Testcase (attachment 83440 [details]) printed with 2002-06-07-08-trunk and Xprint module (DIN A4, 300DPI); with ISO-8859-2 fonts in the fontpath and "Courier" set as default font in the prefs

Sorry, typo in the prefs.js file (reminder: It's better to use the prefs
UI...), new attachment in a few secs...

Comment 16

[Drazen Kacar]

> What problems do you see beyond the issue that we use the "wrong" fonts ?

Isn't that enough?

> Can you be a little bit more specific about this, please ?

Try printing a text in German in which all letters with umlauts are in Courier,
but all the rest are set in Times. Would you call that decent?

Your first example picked italic LucidaBright, then tilted it to the left, so it
would appear without a slant. It could have at least started with regular or
normal font. Your second example uses regular Courier, which isn't better at
all.

If the program started to print the document in Times, it should continue to
print in Times even if it encounters a character which is not ASCII. You don't
need a special user preference for that. Ransom note style cannot possibly be
the default.

In case you don't have Latin 2 Times, some substitution should be performed, but
that's not the point of this bug report. The submitter has the fonts. Mozilla
shows the output on the screen correctly. It just messes up when generating
PostScript.

Comment 17

[Roland Mainz]

Drazen Kacar wrote:
> > What problems do you see beyond the issue that we use the "wrong" fonts ?
>
> Isn't that enough?

Yes, that's enougth - but I wanted to be sure that there are no further
issues... :)

> > Can you be a little bit more specific about this, please ?
> 
> Try printing a text in German in which all letters with umlauts are in 
> Courier, but all the rest are set in Times. Would you call that decent?

Definately no.

> Your first example picked italic LucidaBright, then tilted it to the left, so
> it would appear without a slant. It could have at least started with 
> regular or normal font. Your second example uses regular Courier, which isn't 
> better at all.
> 
> If the program started to print the document in Times, it should continue to
> print in Times even if it encounters a character which is not ASCII. You don't
> need a special user preference for that.

Well, maybe it's better to define some "defaults" for each locale to avoid that
fontmetrics goes "nuts" and picky the fonts randomly...

> Ransom note style cannot possibly be the default.

Well, that's what the fontmetrics code does in rare cases (e.g. too few fonts or
too many similar fonts) ... ;-(

> In case you don't have Latin 2 Times, some substitution should be performed, 
> but that's not the point of this bug report.
> The submitter has the fonts. Mozilla shows the output on the screen correctly. 
> It just messes up when generating PostScript.

Maybe I am (again) causing the problems since I've restricted Xprt to only have
the fonts from /usr/openwin/lib/locale/iso_8859_2/X11/fonts/Type1,
/usr/openwin/lib/X11/fonts/Type1/ and the MathML fonts
(~/mathml_fonts/wolfram/Type1/,~/mathml_fonts/tex_cmps/Type1) which heavily
cuts-down the number of possible choices.

I am sure we should see the same effect on the normal display if we reduce the
number of fonts to a similar number as used for the Xprt server.

----

BTW: Maybe be should open a seperate bug for the issue in the
GTK+/Xlib/Xprint-fontmetrics code since the original bug report seems to be
about the PostScript module (which uses a similar but far less capable version
of the fontmetrics code).

Comment 18

[Roland Mainz]

Attachment: Testcase (attachment 83440) printed with 2002-06-07-08-trunk and Xprint module (DIN A4, 300DPI); with ISO-8859-2 fonts in the fontpath and "Courier" set as default font in the prefs

I've chosen "courier" for both "western" and "east european" fonts in the font
prefs - I hope this time it's better...

Comment 19

[Roland Mainz]

Just verified my assumption that GTK+ and Xlib fontmetrics suffer from the same
issue, they both show the same defect when reducing the number of fonts to a
minimum set...

Comment 20

[Hrvoje Niksic]

Roland, your "courier" test case seems fine.  However, I am not sure that it is
at all relevant to this bug.  It is certainly not desirable to have to tweak
preferences in order to get things printed correctly?

Even if I found Xprint fascinating (which I don't), I would still prefer to see
a "conventional" fix for this problem for the people who can't or won't use
Xprint.  So if you cannot help with fixing this, could you please make good on
your own suggestion and move the Xprint discussion to a separate bug?

Thank you.

Comment 21

[Hrvoje Niksic]

Attachment: How Mozilla renders HTML in attachment 83440

In case people don't feel like trying to print this, I've now attached a
PostScript document Mozilla creates when I try to print the provided HTML.

Note the bogus spacing in the second line between [Scaron] and "ume".  Similar
bogus spacing is present in Latin 1 example below...  As you can see by
clicking on the HTML attachment, Mozilla renders the example correctly on
screen.

Comment 22

[Hrvoje Niksic]

This bug is still present in Mozilla 1.1.  Changing status to NEW.

Comment 23

[Radoslav Bendik]

I have mozilla 1.3 on linux, and the bug is still present.

Seem like non-ascii characters are treated as word boundaries and space is added
after them in justify mode.

Comment 24

[PeteVine]

I have just experienced this bug with Mozilla Firebird 0.6/1.5b on Linux while
trying to print a page containing iso8859-2 characters:
http://www.almatur.pl/drukuj.php?nr=PFSC

Looks like it's quite a longstanding bug :(

Comment 25

[Petr Kristan]

Attachment: Printed second page from http://www.root.cz/print.php4?id=1867

This is realy long standing bug. Is here from that time when mozilla know to
print (I think). 

But this is not only "non-ASCII" problem. It can be seen in font style change
too. 

If for example font was changed from normal to italic then mozilla prints
variously wide white space.

Comment 26

[João S. O. Bueno]

Also hits utf-8 encoded pages, with Latin accented letters. 
Maybe someone could test it with non-roman letters? (Just tested it in mozilla 
1.5) 
 
Bug 182217 should be marked as a duplicate of this one. 
 
And...it seens like it has to be reasigned. The "assigned-to " field has got a 
netscape.com e-mail yet. :-( 
 
This missbehaviour severily impairs mozilla as an application to the 
non-english speaking world., please, give it some attention. Someone, please 
change it´s severity from "normal" to a higher one. This might have been 
secondary back in the pre-1.0 days. Today's mozilla apps should be more mature 
than being unable to print accented characters. I could do that in "Magic 
Windows" text editor for Apple Dos 3.3 (in an Apple II e), back in 1988. 
 
 
 
 

Comment 27

[Roland Mainz]

dbaron/bz:
Can you take a look at this bug, please ?

Comment 28

[Boris Zbarsky [:bzbarsky]]

Given that I know next to nothing about printing or font code... can you help me
out with some answers?

1)  Is the size of the textframe wrong?  Or just the painting?  That is, do we
get text overlapping?

2)  If we do get it overlapping, do you have any idea what in
    nsTextFrame::PaintTextSlowly could be causing problems?

Comment 29

[Simon Montagu :smontagu]

This bug no longer exists in current versions (presumably fixed by the new text frame like other bugs with justified text)