116439 - Xprint module prints sometimes underlined text wrong

Status: VERIFIED FIXED

(Core Graveyard :: Printing: Xprint, defect, P1)

Description

[Roland Mainz]

Xprint module seems to have problems with underlined text - the line under the
text is sometimes too short.

Comment 1

[Roland Mainz]

Attachment: Resulting PostScript print job using 2001-12-20-08-trunk Xprinbt module and Solaris 7+108376-33 Xprt

Comment 2

[Roland Mainz]

Attachment: Page 6 of attachment 62552 converted via Solaris 7 sdtimage

Example (pls ignore that the colors are slighly wrong - that's a sdtimage bug
... ;-( )

Comment 3

[rbs]

See bug 8322 for a similar bug in GfxWin which was solved by special-casing. But 
in the case of bug 8322, the line was too long, and the fix was simpler there
because it amounts to clip the drawing area. When the line is too short, hmm...

Comment 4

[Roland Mainz]

rbs:
But it is not only the underline which is wrong here... looking at attachment
62553 [details] - the underlined text parts partially overwrite other text. Is it possible
that the font metrics information is wrong or gets interpreted the wrong way ?

Comment 5

[Roland Mainz]

Xprt loads the following fonts while printing the example URL:
-- snip --
XLoadQueryFont(aDisplay=':1.0',mName='-adobe-helvetica-medium-r-normal--34-240-100-100-p-176-iso8859-1')
returned d3fc78
XLoadQueryFont(aDisplay=':1.0',mName='-adobe-helvetica-bold-r-normal--34-240-100-100-p-182-iso8859-1')
returned e9d228
XLoadQueryFont(aDisplay=':1.0',mName='-adobe-helvetica-bold-r-normal--50-120-300-300-p-0-iso8859-1')
returned ea21a8
XLoadQueryFont(aDisplay=':1.0',mName='-adobe-helvetica-medium-r-normal--50-120-300-300-p-0-iso8859-1')
returned ea2fa0
XLoadQueryFont(aDisplay=':1.0',mName='-adobe-times-medium-r-normal--34-240-100-100-p-170-iso8859-1')
returned ea6860
XLoadQueryFont(aDisplay=':1.0',mName='-adobe-helvetica-medium-r-normal--17-120-100-100-p-88-iso8859-1')
returned f62578
XLoadQueryFont(aDisplay=':1.0',mName='-adobe-times-medium-r-normal--34-240-100-100-p-170-iso8859-1')
returned ccef68
-- snip --

Restricting Xprt to buildin printer fonts fixes this issue.
Xprt in only-printer-buildin mode loads the following fonts:
-- snip --
XLoadQueryFont(aDisplay=':1.0',mName='-adobe-times-medium-r-normal--50-120-300-300-p-0-iso8859-1')
returned d13aa0
XLoadQueryFont(aDisplay=':1.0',mName='-adobe-helvetica-medium-r-normal--50-120-300-300-p-0-iso8859-1')
returned d6f968
XLoadQueryFont(aDisplay=':1.0',mName='-adobe-helvetica-bold-r-normal--50-120-300-300-p-0-iso8859-1')
returned 7cd368
XLoadQueryFont(aDisplay=':1.0',mName='-adobe-helvetica-medium-r-normal--0-0-1200-1200-p-0-iso8859-1')
returned cdeee8
-- snip --

The root of this problem seems to be that somehow 100DPI fonts are used on a
300DPI device ...

... can anyone explain why these fonts are used - and why we calculate the text
width wrong ?

Comment 6

[Roland Mainz]

Taking ...

Comment 7

[Roland Mainz]

Attachment: Patch for 2001-12-29-08-trunk (requires patch from bug 104075 to apply cleanly)

Comment 8

[Roland Mainz]

Attachment: Resulting PostScript print job with patch applied

Comment 9

[Roland Mainz]

Requesting r=/sr= ...

Comment 10

[Roland Mainz]

Attachment: Better patch for 2002-01-01-08-trunk per timeless's IRC comments

Comment 11

[timeless]

Comment on attachment 63270 [details] [diff] [review]
Better patch for 2002-01-01-08-trunk per timeless's IRC comments

change 'May be'=>'Maybe'
change 'builtin'=>'built-in' sorry, this one's my fault I knew buildin was
wrong but i didn't think carefully enough to remember that you need a hyphen.
http://www.m-w.com/cgi-bin/dictionary?va=built-in
i'd like a comment near the out of memory condition (PR_smprintf) but it's ok
w/o one.

later i think i'd like to change 'printer built-in fonts' to 'built-in printer
fonts'

Comment 12

[kill this account]

A couple of items:

1) minor: would you add a note explaining how one tell from the XLFD that a 
   font is "'mysterious' and 'spurious'"

2) Could we resolve this:
   "I am not sure what Xprint printer builtin fonts really look like"

Otherwise everything looks reasonable.

Comment 13

[Roland Mainz]

Brian Stell wrote:
> 1) minor: would you add a note explaining how one tell from the XLFD that a 
>   font is "'mysterious' and 'spurious'"

That comment is from  Jungshik Shin's patch (attachment 53094 [details] [diff] [review] - see
http://bugzilla.mozilla.org/show_bug.cgi?id=94327#c34).
I do not have a real clue what went wrong there - but his patch fixed the issue
in bug 94327 - therefore I copied it "blindly" into my patch (and tested it) ...
:)

> 2) Could we resolve this:
>   "I am not sure what Xprint printer builtin fonts really look like"

Not really. AFAIK there is no written spec which says "Xprint built-in fonts
look like this ...". Thomas Gilg at HP (e.g. one of the original authors of
Xprint) may have more infos ... :-)
However - the X.org code works like this and eXceed's version of Xprt does the
same. I'll take that as the "spec"... :-))

Comment 14

[Roland Mainz]

Attachment: New patch for 2002-01-01-08-trunk to match r=timeless

Comment 15

[jag (Peter Annema)]

Comment on attachment 63311 [details] [diff] [review]
New patch for 2002-01-01-08-trunk to match r=timeless

sr=jag

Comment 16

[Roland Mainz]

Fix checked in, marking FIXED.

Comment 17

[Masaki Katakai]

Verified on 2002011614 linux build.