140673 - Some Arabic/Hebrew bitmap fonts printed way too small with Xprint

Status: RESOLVED FIXED

(Core Graveyard :: Printing: Xprint, defect)

Description

[Drew Parsons]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412
Debian/0.9.9-6
BuildID:    0.9.9

Running on a Debian unstable system,
Mozilla's "native" printing support of non-latin characters is broken (cf. Bug
125006).   I have therefore, with Roland Mainz's help, gotten xprint running as
a work around.

I tested xprint on a Hebrew page (http://www.a7.org/indexnc.php3).  The page
looks ok on screen, the Hebrew glyphs are no smaller than the latin ones.
Physically the glyphs are approximately 5mm high, big enough to read.  

But when I print the page out using xprint, the Hebrew fonts are rendered
extremely small, only 1mm high, while the latin glyphs on the printed page are
still 5mm high.  This, of course, makes the printed page nearly illegible.

The page declares itself to be charset=iso-8859-8.  I haven't explicitly touched
the mozilla font settings for Hebrew.  Proportional font for Hebrew is
apparently set by default to "Serif", the other fonts are unset.

Reproducible: Always
Steps to Reproduce:
1. start xprint server
2. go to http://www.a7.org/indexnc.php3
3. print page to xprint printer

Actual Results:  Hebrew glyphs on printed page are 5 times smaller than expected.

Expected Results:  Hebrew glyphs on printed page should be same size as latin
glyphs, as is the case on the screen.

Comment 1

[Masaki Katakai]

Drew,

could you attach ps file to Attachment?

Comment 2

[Drew Parsons]

Attachment: Postscript file of hebrew page, created by xprint

This postscript file prints OK on my printer, passing through gs (ghostscript)
as filter.  For some reason gv (v3.5.8), however, is unable to view any of the
postscript files generated by xprint, giving the warning "Error: PostScript
interpreter failed in main window."

Comment 3

[Roland Mainz]

I cannot reproduce this problem on my machine (with both my own Xprt and the
Solaris Xprt (however the Solaris Xprt is more "lucky" since it can use all the
TrueType fonts; the current Linux Xprt does not have TrueType font support...
;-(( )), but looking at attachment 81376 [details] I assume this may somehow be an
incarnation of bug 129666 ("[Xlib] Xlib/Xprint do not scale em-dash & co.
correctly...").

I assume Drew is missing matching or scaleable ISO-8859-8(=hebrew) fonts here
(e.g. only has bitmap fonts; I am not sure what fonts are shipped with debian by
default) and Mozilla's font engine cannot deal with this situation correctly.

I'll attach a PostScript job from my Xprt (gzip-compressed) ...

Comment 4

[Roland Mainz]

Attachment: Gzip packed PostScript job from http://www.a7.org/indexnc.php3 printed using 2002-04-27-08-trunk and my own version of Xprt

Comment 5

[Roland Mainz]

Drew:
After checking my config I figured-out that I have Hebrew PostScript Type1 fonts
in my fontpath.
Can you grab
http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/fonts/postscript_type_1/PS_Type1_iso8859-8.tar.gz
and add these fonts to your fontpath, please ? Does that fix your problem ?

Comment 6

[Drew Parsons]

Roland, I printed out your postscript file, and it came out fine.  The Hebrew
letters are the same size as the latin letters. (the glyphs themselves are a bit
funny: some (e.g. aleph) are thin, others (e.g. gimel) are thick.  But that's a
different problem to the one at hand)

I then extracted your Hebrew Type1 fonts and added their directory to the xprint
fontpath, and discovered I can now print the page, same as your sample.  

I had to put the new directory at the front of the fontpath, otherwise the
Hebrew glyphs came out small again.  This confirms your suspicion that my
default Hebrew font was some unscalable bitmap font.  I was invoking xprint with:

Xprt -fp /usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/misc,
/usr/lib/X11/fonts/koi8-r.75dpi,/usr/lib/X11/fonts/cyrillic,
/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi :12

Adding /usr/local/share/fonts/Type1, where I put your Hebrew fonts, to the front
of this fontpath made the page print with glyphs of the correct size.

The question still remains why the page looked OK on my screen, but goes funny
on paper with xprint.  As you mentioned, this could be because my XFree86 screen
server support TrueType fonts, while your Linux xprint server does not.  Maybe
the font I see on screen is a TrueType font?

Comment 7

[Masaki Katakai]

Another test cases,

Configure Xprt to use dpi=600 and na-letter.

1. start Xprt server with the following fontpath, I just added 75dpi for Japanese,

Xprt :1 -fp
/usr/openwin/lib/X11/fonts/F3/,/usr/openwin/lib/X11/fonts/F3bitmaps/,/usr/openwin/lib/X11/fonts/Type1/,/usr/openwin/lib/X11/fonts/Speedo/,/usr/openwin/lib/X11/fonts/misc/,/usr/openwin/lib/X11/fonts/75dpi/,/usr/openwin/lib/X11/fonts/100dpi/,/usr/openwin/lib/locale/ja/X11/fonts/75dpi

2. Start CDE and set font path as the same of Xprt

xset fp=
/usr/openwin/lib/X11/fonts/F3/,/usr/openwin/lib/X11/fonts/F3bitmaps/,/usr/openwin/lib/X11/fonts/Type1/,/usr/openwin/lib/X11/fonts/Speedo/,/usr/openwin/lib/X11/fonts/misc/,/usr/openwin/lib/X11/fonts/75dpi/,/usr/openwin/lib/X11/fonts/100dpi/,/usr/openwin/lib/locale/ja/X11/fonts/75dpi

3. Start Mozilla and set japanese font to dt-interface which 
is alised in ja/75dpi/

4. go to www.yahoo.co.jp

5. print via Xprint

   Japanese are very small.

Is that same problem?

Comment 8

[Roland Mainz]

Masaki Katakai wrote:
[result:]
> Japanese are very small.
>
> Is that same problem?

I guess this is (again) the all-evil bug 129666 ("[Xlib] Xlib/Xprint do not
scale em-dash & co. correctly...") which pops-up here.
I have the feeling it always occurs if you do not have much fonts for a specific
case (locale?!) ... ;-(

Comment 9

[Simon Montagu :smontagu]

I am currently seeing this problem not with Hebrew but with Arabic in both trunk
and branch builds.

Comment 10

[Roland Mainz]

Simon Montagu wrote:
> I am currently seeing this problem not with Hebrew but with Arabic in both 
> trunk and branch builds.

xx@@@!!!
I thought bug 147743 ("Xprint prints some (non-scaleable) bitmap fonts far too
small") fixed that (the assuption in comment #8 was wrong; further investigation
resulted in bug 147743) ...

smontagu:
Do you have some sample URLs where this problem occur for you ?

Comment 11

[Roland Mainz]

Attachment: http://www.google.de/search?q=mozilla+i18n&ie=UTF-8&oe=UTF-8&hl=ar&btnG=%D8%A8%D8%AD%D8%AB+Google printed with 2002-07-12-08-trunk + Xprint module (300 DPI, DIN-A4)

I can see the bug here with
http://www.google.de/search?q=mozilla+i18n&ie=UTF-8&oe=UTF-8&hl=ar&btnG=%D8%A8%D8%AD%D8%AB+Google
- somehow the patch from bug 147743 does not catch the issue... ;-(

Comment 12

[Roland Mainz]

Confirming per comment #11 ...

Comment 13

[Roland Mainz]

Attachment: Patch for 2002-07-12-08-trunk

More fun from the "bitmap font department".

The idea from bug 147743 was not enougth, sometimes we want some font sizes
between the two non-scaled bitmap fonts provided by the code from bug 147743
(which adds a normal version of a bitmap font and a scaled-to-devscale bitmap
font as normal bitmap fonts to our fontmetrics database).

This patch now adds a range of scaled bitmap fonts (in 0.5x steps) as normal
bitmap fonts to avoid this issue everytimes.

(Note that this issue only happes for bitmap fonts; adding outline scaleable
fonts to Xprt's font path completely avoids this issue.)

Comment 14

[Roland Mainz]

Attachment: Better patch for 2002-07-12-08-trunk

New patch, I only corrected the comments...

Comment 15

[Roland Mainz]

Requesting r=/sr= ...

Comment 16

[Simon Montagu :smontagu]

My test scenario is to go to http://www.unicode.org/iuc/iuc10/x-utf8.html and
print the first page. The Arabic section has text in three sizes: default size
(the long paragraph), <font size="+1"> (the bottom line) and <font size="+2">
(the top two lines).

Before applying attachment 91265 [details] [diff] [review] all three are printed extremely small, at the
edge of readability. After applying it, the default-sized section is unchanged,
and the top and bottom sections are a reasonable size, but still seem small
compared to the size of the equivalent lines in the next section of the page.

Would "before" and "after" prints to file be useful? If so, in what format?

Comment 17

[Roland Mainz]

Attachment: New patch for 2002-07-12-08-trunk

I've adjusted the patch to use a range of "devscale/2 ----> devscale*2" instead
of "2.0 ----> devscale".

This should be better and result in reasonable sizes for small fonts, normal
fonts and large fonts.

Comment 18

[Roland Mainz]

Simon Montagu wrote:
> Before applying attachment 91265 [details] [diff] [review] all three are printed extremely small, at the
> edge of readability.

I can't reproduce the problem with http://www.unicode.org/iuc/iuc10/x-utf8.html
on my side - but I simply guess my device scaling factors are different since my
Xserver runs at a differnt resolution (85 DPI on my box; 90 DPI is the default
for Xsun).

> After applying it, the default-sized section is 
> unchanged, and the top and bottom sections are a reasonable size, but still 
> seem small compared to the size of the equivalent lines in the next section
> of the page.

Can you try it again with the new patch, please ?

> Would "before" and "after" prints to file be useful? If so, in what format?

PostScript (application/postscript) if possible. But having a reduced testcase
with more text sizes (-2, -1, 0, +1, +2) may be nice, too... :)

Comment 19

[Roland Mainz]

Attachment: New patch for 2002-07-12-08-trunk per smontagu's review comments...

Fixed error checking per smontagu's comments...

Comment 20

[Simon Montagu :smontagu]

Comment on attachment 91433 [details] [diff] [review]
New patch for 2002-07-12-08-trunk per smontagu's review comments...

r=smontagu

Comment 21

[Daniel Veditz [:dveditz]]

Comment on attachment 91433 [details] [diff] [review]
New patch for 2002-07-12-08-trunk per smontagu's review comments...

sr=dveditz

Comment 22

[Scott Collins]

Comment on attachment 91433 [details] [diff] [review]
New patch for 2002-07-12-08-trunk per smontagu's review comments...

if I were reviewing this code, I would have warned that |1.5f| and |2.0f| are
`magic numbers' and require either constants or better explanation.  Also, I
would consider the case |2.f| as an attention attracting inconsistency.  But
today, I'm not the reviewer, I'm the approver, and the reviewers liked it.

a=scc for checkin to the mozilla trunk

Comment 23

[Roland Mainz]

Attachment: New patch for 2002-07-12-08-trunk per scc's comment

Comment 24

[Roland Mainz]

Attachment: New patch with more comments

Comment 25

[Roland Mainz]

CC:'ing [e-mail] to carry-over r=/sr=/a= for the new patch...

Comment 26

[Roland Mainz]

Comment on attachment 91743 [details] [diff] [review]
New patch with more comments

Per dveditz's suggestion I'll take the original patch which got r=/sr=/a= and
file a bug to get some stuff in nsFontMetrics*.cpp documented...

Comment 27

[Roland Mainz]

Comment on attachment 91433 [details] [diff] [review]
New patch for 2002-07-12-08-trunk per smontagu's review comments...

This patch should be checked-in...

Comment 28

[jag (Peter Annema)]

Checked in on the trunk

Comment 29

[Randell Jesup [:jesup] (needinfo me)]

approved for branch; please change mozilla1.0.1+ to fixed1.0.1 when fixed on the
branch

Comment 30

[Simon Montagu :smontagu]

Attachment 91433 [details] [diff] checked in to branch

Comment 31

[Randell Jesup [:jesup] (needinfo me)]

this has been checked into trunk and branch according to the comments.  Marking
fixed.

Comment 32

[Roland Mainz]

Unfortunately there is a "leftover" in this patch - the scaling factor |1.0| was
still used in rare cases... bug 161556 ("Arabic bitmap fonts are printed too
small") fixed that issue...