139503 - GTK+/Xlib/Xprint removes all spaces between words

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[Jim Crumley]

This is on a local Sparc Solaris 7 build of the trunk from 2002042305. Printing
using Xprint removes the spaces from between all words.  I'll attach a
postscript example of the URL above. This behavior does not occur with the
regular postscript printing module.

This is quite likely a configuration error on my end, but I can't see what it
is. I've looked at the Xprint FAQ at
http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/Xprint_FAQ.txt
and I don't see anything relevant.

Comment 1

[Jim Crumley]

Attachment: Shows printout without spaces between words.

Comment 2

[Roland Mainz]

Reporter:
Which Xprt do you use ? On which platform does it run ?

Comment 3

[Jim Crumley]

Xprt is run on Sparc Solaris 7 - its the standard Solaris version. It looks like
its been affected by a recent Solaris patch, since its got a timestamp from this
February. Is that enough info or is there a way to get Xprt to tell its version?
I didn't see anyway to get it.

Comment 4

[Roland Mainz]

Confirming bug - I can reproduce the problem on my side.

The problem is that the Solaris 2.7 Xprt's default config does not make use of
the printer-builtin fonts. Mozilla finally ends with using a bitmap font instead
(take a look at the print job, you will see a lot of "Im1" images) - that's
another sideeffect of bug 93771 ("Mozilla uses low-resolution bitmap fonts on
high resolution X11 displays").

The fix would be the same as I did in my Linux Xprt distribution (see
http://puck.informatik.med.uni-giessen.de/download/xprint_linux_x86_005.tar.gz) 
- it contains a default model-config for PostScript printers ("PSdefault") which
makes use of some printer-builtin fonts.

Reporter:
Can you download the Linux distribution and use the Xprt config files used with
that distribution (e.g. setting XPCONFIGDIR to the config files distributed with
the Linux x86 binary), please ?

Comment 5

[Roland Mainz]

Attachment: http://ham.space.umn.edu/crumley/index.html printed with correct Xprt config (DIN-A4, 300 DPI)

Comment 6

[Jim Crumley]

Yep, those suggestions solve the problem for me.  Thanks!

I'm not sure how this should be resolved since its not really a Mozilla problem,
but it might come up for other Mozilla users who don't know much about xprint.

Comment 7

[Roland Mainz]

I am not sure whether this is not a Mozilla-related font issue. The Mozilla font
engine is very compliciated - I would not be surprised if we find someday - per
accident - the line of code which causes this.

For now I am thinking about adding an assertion to the debug code which catches
the case if width_of_whitespace==0 (which seems to be the problem here).
Another good way to do some tests may be some code which prints the name of the
font returned by XLoadQueryFont() ...

Comment 8

[Roland Mainz]

Taking, I'll try to hack a patch (however - only a fix for bug 93771 ("Mozilla
uses low-resolution bitmap fonts on high resolution X11 displays" will solve the
problem perfectly (e.g. avoid using lowres fonts unless there is really really
no other solution)).

Comment 9

[Roland Mainz]

If you do it "right" you can get the same problem on the main display.

Comment 10

[Roland Mainz]

Minor problem:
The testcase URL is unavailable (http://ham.space.umn.edu/crumley/index.html)
... reporter: Can you _attach_ the web page, please ?

Comment 11

[Roland Mainz]

Attachment: Prototype for 2002-04-24-08-trunk which bans fonts where the width of a space is lower than a barrier value (which is calculated based on the width of 'a')

Comment 12

[Roland Mainz]

Attachment: Simple testcase

Comment 13

[Roland Mainz]

Attachment: Print job from testcase (attachment 81322) printed with 2002-04-24-08-trunk+patch 81320

The prototype patch now bans the following fonts while printing on a 300 DPI
printer:
-- snip --
###!!! ASSERTION:
font(='-adobe-times-medium-r-normal--57-*-300-300-p-*-iso8859-1')'s space
width(=14) < barrier(=16); (a_Width=25): 'spaceWidth >= barrier', file
nsFontMetricsXlib.cpp, line 2445
-- snip --

The result looks correctly (however - the font choice is now such limited that
the used font is monospaced... ;-( ).

Comment 14

[Roland Mainz]

Setting milestone to "Future" since this is really a result of a misconfigured
Xserver (not Xprt specific - you can reproduce this on a normal Xserver when you
restrict the font path too much and/or increase the DPI value (like 300 DPI or
beyond)) - getting a fix may be nice but this isn't a top priority (unless
katakai says something else... :) ...

Comment 15

[Roland Mainz]

shanjian/bstell:
Any comments/suggestions ?

Comment 16

[kill this account]

I would expect that the issue shows up here with a very small mSpaceWidth:

  nsFontMetricsGTK::RealizeFont()
  ...
   gint rawWidth;
   if ((fontInfo->min_byte1 == 0) && (fontInfo->max_byte1 == 0)) {
     rawWidth = xFont->TextWidth8(" ", 1);
   }
   else {
     XChar2b _16bit_space;
     _16bit_space.byte1 = 0;
     _16bit_space.byte2 = ' ';
     rawWidth = xFont->TextWidth16(&_16bit_space, sizeof(_16bit_space)/2);
   }
   mSpaceWidth = NSToCoordRound(rawWidth * f);

It would be a hack but I suppose the code could test if the space width
was smaller than the '.' width and if so set it to the size of a '-' width.
We could limit any side effects by only doing this when the screen
res was greater than say 150 DPI.

Comment 17

[Roland Mainz]

Brian Stell wrote:
> It would be a hack but I suppose the code could test if the space width
> was smaller than the '.' width and if so set it to the size of a '-' width.

Mhhh, but what about the case when we actually draw a string with XDrawString()
or measure the width of a string ?
We would have to render/measure these fonts char-by-char to get correct results,
right ?

Comment 18

[Roland Mainz]

Attachment: Patch which fixes the problem - but bans some valid fonts, too... ;-(

Using |(spaceWidth < dotWidth)| does not catch the problem - and using
|(spaceWidth <= dotWidth)| (like in this patch) bans some valid fonts, too...
;-(

Comment 19

[kill this account]

> but what about the case when we actually draw a string with XDrawString()
> or measure the width of a string? We would have to render/measure these fonts 
> char-by-char to get correct results, right ?

Moz handles spaces differently from other chars. I believe this relates to line
breaking. It is my understanding that spaces are not drawn; the next word is
just offset by the space width. The symptom appears to be zero (or near zero)
width for spaces but correct width for the "words" (non space chars) so it
does not appear to require char-by-char measuring.

Because the symptom was "missing" spaces I suggested looking at how wide moz
thought the space was. It would still be good to verify what the space width
was being measured as.

> Using |(spaceWidth < dotWidth)| does not catch the problem 

Too bad.

> - and using |(spaceWidth <= dotWidth)| (like in this patch) bans some valid 
> fonts, too...

I never intended to invalidate the fonts just to do a workaround to get a
resaonable space width.

Comment 20

[Roland Mainz]

Putting |spaceWidth = 500;| into the code does not affect both framebuffer
output not the print jobs created with Xprint...

Weired.

Comment 21

[Roland Mainz]

Reporter:
What font path are you using ?

Comment 22

[Roland Mainz]

shanjian:
Are there any places in layout/ where we can insert a |NS_ASSERT()| to see if a
space's width is zero or near zero ?

Comment 23

[Jim Crumley]

My current font path is:
 
/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/100dpi/:unscaled,/usr/lib/X11/fonts/75dpi/:unscaled,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi

Comment 24

[Roland Mainz]

Jim Crumley wrote:
> My current font path is:
> < ... long-line-was-here ... >

Just a bunch of questions:
1. Is that on Solaris or Linux ?
2. Is that the main Xserver (e.g. Xsun/Xfree86) or the Xprt fontpath ?
3. Does the problem occur still occur with that font path ?
4. Does the problem still occur with newer Mozilla builds (like Mozilla 1.0.1
(_not_ 1.0.0!)) ?

Comment 25

[Jim Crumley]

Just a bunch of questions:
> 1. Is that on Solaris or Linux ?

That was for Solaris.

> 2. Is that the main Xserver (e.g. Xsun/Xfree86) or the Xprt fontpath ?

That was the Xserver font path - from xset -q. Does Xprt with Solaris have a
distinct font path?  I wasn't able to locate one in the config files.

> 3. Does the problem occur still occur with that font path ?

Well the problem does not occur for me anymore at all since I am using a
correctly configured Xprt from XF86 as you suggested above in comment 4.

I could try using the default Xprt again if you'd like to see if the problem
still occurs.

Does the problem still occur for you with the Xserver under conditions like in
comment 14.

> 4. Does the problem still occur with newer Mozilla builds (like Mozilla 1.0.1
> (_not_ 1.0.0!)) ?

I'm not sure if the problem still occurs with more recent mozilla builds.  I
rarely use Mozilla on Solaris anymore, since I seldom have console access to a
Sparc box.

I can try testing this remotely.  The problem should still occur if I print to
file, correct?  Or do I need the physical printout to be certain?  If so, I'll
have to delay testing this for a while.

Comment 26

[Chris Gori]

I also have this problem on Solaris, and cannot get the fix from comment 4
to work in my system (Solaris 8, moz 1.3b).

I installed
GISWxprintglue-sparc-2003-02-26-trunk.tar.gz
but it also occurs for
GISWxprintglue-sparc-2003-02-18-trunk.tar.gz
(which I was using before)

As suggested in this bug, I moved 
/usr/openwin/server/etc/XpConfig/C away and used the one from the linux tarball 
in place.

I checked in /etc/init.d/xprint and added debug echos:
XPCONFIGDIR = /opt/GISWxprintglue/server/etc/XpConfig

I realized my change wasn't having any effect, so, I moved
/opt/GISWxprintglue/server/etc/XpConfig/C away and placed the
one from the linux tarball there as well.

The test URL in question is
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&g\
etPagePath=14629

although I also see this behavior on
http://www.netapp.com/tech_library/3183.html#0.

As described in the original report, page display and print preview look
fine, it is only the hard copy output that is space-less.

This machine is an Ultra10 running Solaris 5.8 with the most up-to-date
Sun patch cluster.  xset -q for the font path is

Font Path:
  /usr/openwin/lib/X11/fonts/F3/,/usr/openwin/lib/X11/fonts/F3bitmaps/,/usr/ope\
nwin/lib/X11/fonts/Type1/,/usr/openwin/lib/X11/fonts/Speedo/,/usr/openwin/lib/X\
11/fonts/misc/,/usr/openwin/lib/X11/fonts/75dpi/,/usr/openwin/lib/X11/fonts/100\
dpi/

Mozilla release in use is (Mozilla 1.3b Mozilla/5.0 (X11; U; SunOS sun4u;
en-US; rv:1.3b) Gecko/20030211).  I believe it's the downloadable binary from
mozilla.org

If you need anything more please let me know.

Comment 27

[Chris Gori]

I should add that

http://xprint.mozdev.org/installation.html

prints fine (!!?!).

Comment 28

[Roland Mainz]

Chris Gori wrote:
> I also have this problem on Solaris, and cannot get the fix from comment 4
> to work in my system (Solaris 8, moz 1.3b).
>
> I installed
> GISWxprintglue-sparc-2003-02-26-trunk.tar.gz
> but it also occurs for
> GISWxprintglue-sparc-2003-02-18-trunk.tar.gz
> (which I was using before)
>
> As suggested in this bug, I moved 
> /usr/openwin/server/etc/XpConfig/C away and used the one from the linux 
> tarball in place.

Erm, that's what the GISWxprintglue package does - it uses the Solaris version
of Xprt (/usr/openwin/bin/Xprt), a configuration which has a default
model-config set ("PSdefault", but you may use "SPSPARC" with the plain Solaris
installation, too :) and the startup-script /etc/init.d/xprint ...

[snip]

> although I also see this behavior on
> http://www.netapp.com/tech_library/3183.html#0.

Yeah, I can reproduce the issue with that URL... ;-(

> As described in the original report, page display and print preview look
> fine, it is only the hard copy output that is space-less.

I have more and more the feeling that there is a broken font which causes the
issue... ;-(

> This machine is an Ultra10 running Solaris 5.8 with the most up-to-date
> Sun patch cluster.  xset -q for the font path is
>
> Font Path:
> /usr/openwin/lib/X11/fonts/F3/,/usr/openwin/lib/X11/fonts/F3bitmaps/,/usr/ope\
> nwin/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/

Erm, this does not look like a font path from Xprt... can you post a font path
using 5 (DISPLAY=myxprtdpy:1234 xset q) # please ?

Comment 29

[Roland Mainz]

Fun.

Looks like one of the Zillion "Monotype Arial" fonts causes the problems.

Adding
-- snip --
user_pref("print.xprint.font.rejectfontpattern",
"fname=-dt-.*;scalable=.*;outline_scaled=false;xdisplay=.*;xdpy=.*;ydpy=.*;xdevice=.*|"
+
"fname=-monotype-arial.*;scalable=.*;outline_scaled=.*;xdisplay=.*;xdpy=.*;ydpy=.*;xdevice=.*");
-- snip --
to prefs.js works around the problem in my case... ;-/

Comment 30

[Roland Mainz]

More fun:
i can now reproduce the issue with the Monotype Arial fonts from
/usr/openwin/lib/X11/fonts/TrueType/ - however this issue only occurs when using
Sun's TrueType font engine. Using the Xfree86 TrueType font engine the font is
viewed (gfx/src/gtk/) and printed (gfx/src/xprint) correctly.

Comment 31

[Roland Mainz]

Attachment: gdiff -u output diffing |xlsfonts -lll -fn '-monotype-arial-regular-r-normal--57-137-300-300-p-252-iso8859-1'|-output created from Xfree86+Sun TrueType font engines

Comment 32

[Roland Mainz]

Attachment: Reduced testcase

Comment 33

[Chris Gori]

added requested xprt fontpath from comment 28 (my bad!)

setenv DISPLAY isengard:33
xset q

 
PRINTER:/opt/GISWxprintglue/server/etc/XpConfig/en_US.ISO8859-1/print//models/PSdefault//fonts/,/usr/openwin/lib/X11/fonts/Type1/,/usr/openwin/lib/locale/iso_8859_2/X11/fonts/Type1,/usr/openwin/lib/locale/iso_8859_4/X11/fonts/Type1,/usr/openwin/lib/locale/iso_8859_5/X11/fonts/Type1,/usr/openwin/lib/locale/iso_8859_7/X11/fonts/Type1,/usr/openwin/lib/locale/iso_8859_8/X11/fonts/Type1,/usr/openwin/lib/locale/iso_8859_9/X11/fonts/Type1,/usr/openwin/lib/X11/fonts/TrueType/,/usr/openwin/lib/locale/ar/X11/fonts/TrueType,/usr/openwin/lib/locale/iso_8859_15/X11/fonts/TrueType,/usr/openwin/lib/locale/th_TH/X11/fonts/TrueType,/usr/openwin/lib/X11/fonts/misc/,/usr/openwin/lib/X11/fonts/75dpi/,/usr/openwin/lib/X11/fonts/100dpi/,/usr/openwin/lib/locale/en_US.UTF-8/X11/fonts/misc,/usr/openwin/lib/locale/iso_8859_2/X11/fonts/75dpi,/usr/openwin/lib/locale/iso_8859_4/X11/fonts/75dpi,/usr/openwin/lib/locale/iso_8859_5/X11/fonts/75dpi,/usr/openwin/lib/locale/iso_8859_7/X11/fonts/75dpi,/usr/openwin/lib/locale/iso_8859_9/X11/fonts/75dpi,/usr/openwin/lib/locale/ja/X11/fonts/75dpi,/usr/openwin/lib/locale/ko.UTF-8/X11/fonts/75dpi,/usr/openwin/lib/locale/zh/X11/fonts/75dpi,/usr/openwin/lib/locale/zh_TW.BIG5/X11/fonts/75dpi

Comment 34

[Chris Gori]

just to confirm, when i print the "Reduced testcase" the zero-space problem
occurs for the first 3 test lines.  Everything else is fine.  This is without the
prefs.js hack (I'll try that next).

Comment 35

[Chris Gori]

modifying prefs.js as indicated fixes both of my test URLs.

I think there is still some problem in the code though, since that should not
be necessary :-(

Comment 36

[Roland Mainz]

This bug is now fixed since a long time in Mozilla code.

For Xprint there was a similar bug in the Xprint server shipped with Solaris,
Sun gurus hunted the issue down and fixed it - see comments in
http://xprint.mozdev.org/bugs/show_bug.cgi?id=3353 and
http://xprint.mozdev.org/docs/Xprint_FAQ.html#bug_solaris_xprt_removes_spaces_between_words
Solaris 2.8 and 2.9 patches are available now on http://sunsolve.sun.com/

Solaris 2.9 patch ids are:
For sparc: 112785-21 or later
For x86:   112786-11 or later

Solaris 2.8 patch ids are:
For sparc, 108652-73 or later
For x86, 108653-62 or later

Please read
http://xprint.mozdev.org/docs/Xprint_FAQ.html#bug_solaris_xprt_removes_spaces_between_words
for further information.
If there are still any problems please consult the Xprint mailinglist
(http://xprint.mozdev.org/list.html).

Marking bug as WORKSFORME (for the non-Xprint issue), the matching
Xprint-specific bug report was bug 191335 ("Solaris 8 Xprint server broken") is
marked FIXED since a long time.