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

RESOLVED FIXED in mozilla1.0.1

Status

RESOLVED FIXED
17 years ago
10 years ago

People

(Reporter: dparsons, Assigned: roland.mainz)

Tracking

Trunk
mozilla1.0.1
x86
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments, 5 obsolete attachments)

(Reporter)

Description

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

17 years ago
Drew,

could you attach ps file to Attachment?
Assignee: katakai → Roland.Mainz
QA Contact: Roland.Mainz → katakai
(Reporter)

Comment 2

17 years ago
Created attachment 81376 [details]
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."
(Assignee)

Comment 3

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

Comment 4

17 years ago
Created attachment 81424 [details]
Gzip packed PostScript job from http://www.a7.org/indexnc.php3 printed using 2002-04-27-08-trunk and my own version of Xprt
(Assignee)

Comment 5

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

Comment 6

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

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

Comment 8

17 years ago
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?!) ... ;-(
I am currently seeing this problem not with Hebrew but with Arabic in both trunk
and branch builds.
(Assignee)

Comment 10

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

Updated

17 years ago
Summary: Hebrew font printed way too small with xprint → Some Arabic/Hebrew font printed way too small with Xprint
(Assignee)

Comment 11

17 years ago
Created attachment 91262 [details]
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... ;-(
(Assignee)

Comment 12

17 years ago
Confirming per comment #11 ...
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 13

17 years ago
Created attachment 91264 [details] [diff] [review]
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.)
(Assignee)

Comment 14

17 years ago
Created attachment 91265 [details] [diff] [review]
Better patch for 2002-07-12-08-trunk

New patch, I only corrected the comments...
Attachment #91264 - Attachment is obsolete: true
(Assignee)

Comment 15

17 years ago
Requesting r=/sr= ...
Keywords: patch, review
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?
(Assignee)

Comment 17

17 years ago
Created attachment 91423 [details] [diff] [review]
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.
(Assignee)

Comment 18

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

Updated

17 years ago
Attachment #91265 - Attachment is obsolete: true
(Assignee)

Comment 19

17 years ago
Created attachment 91433 [details] [diff] [review]
New patch for 2002-07-12-08-trunk per smontagu's review comments...

Fixed error checking per smontagu's comments...
Attachment #91423 - Attachment is obsolete: true
Comment on attachment 91433 [details] [diff] [review]
New patch for 2002-07-12-08-trunk per smontagu's review comments...

r=smontagu
Attachment #91433 - Flags: review+
(Assignee)

Updated

17 years ago
Summary: Some Arabic/Hebrew font printed way too small with Xprint → Some Arabic/Hebrew bitmap fonts printed way too small with Xprint
Target Milestone: --- → mozilla1.0.1
Comment on attachment 91433 [details] [diff] [review]
New patch for 2002-07-12-08-trunk per smontagu's review comments...

sr=dveditz
Attachment #91433 - Flags: superreview+

Comment 22

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

Comment 23

17 years ago
Created attachment 91741 [details] [diff] [review]
New patch for 2002-07-12-08-trunk per scc's comment
Attachment #91433 - Attachment is obsolete: true
(Assignee)

Comment 24

17 years ago
Created attachment 91743 [details] [diff] [review]
New patch with more comments
Attachment #91741 - Attachment is obsolete: true
(Assignee)

Comment 25

17 years ago
CC:'ing scc@mozilla.org to carry-over r=/sr=/a= for the new patch...
(Assignee)

Comment 26

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

Comment 27

17 years ago
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...
Attachment #91433 - Attachment is obsolete: false
Attachment #91433 - Flags: approval+
(Assignee)

Updated

17 years ago
Attachment #91743 - Attachment is obsolete: true

Comment 28

17 years ago
Checked in on the trunk

Updated

17 years ago
Blocks: 158377
approved for branch; please change mozilla1.0.1+ to fixed1.0.1 when fixed on the
branch
Keywords: review → mozilla1.0.1+
Attachment 91433 [details] [diff] checked in to branch
Keywords: mozilla1.0.1+ → fixed1.0.1
this has been checked into trunk and branch according to the comments.  Marking
fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Assignee)

Updated

17 years ago
Blocks: 149768
(Assignee)

Comment 32

16 years ago
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...
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.