What on the screen looks like (rendering underlined links as ALLCAPS) Conversations are mere word plays. It's curious that people believe to speak for the sake of THINGS. They don't seem to know the very function of language - that it is merely concerned with itself. LANGUAGE is a renders on the printed page as Conversations are mere word plays. It's curious that people believe to speak for the sake of THINGS. They don't seem to know the very function of language - that it is merely concerned with itself. LANGUAGE is a
Created attachment 67585 [details] PS of the page in question The buzilla file-type selection list ought to have postscript as a possibility...
17 years ago
Attachment #67585 - Attachment mime type: application/octet-stream → application/postscript
Seeing this with build 2002-02-01-08. The postscript has stuff like: 42 577.9 moveto (for the sake of ) show 115 577.9 moveto (thing) show 132 577.9 moveto (s. They don't seem to know the very function of) show So the length of "thing" is 17, while the length of "for the sake of" is 73. That seems like an incorrect calculation.... The latter should be about twice the length of the former, not 4 times as long.
Status: UNCONFIRMED → NEW
Ever confirmed: true
over to don it appears this is a PS issue. It looks fine on Print Preview and printed out to a Windows PS driver.
Assignee: rods → dcone
Example URL prints fine with Xprint module on Linux, therefore I guess this is a PostScript-module only issue...
Summary: big ugly gaps before hrefs in printout → [ps] big ugly gaps before hrefs in printout
This bug can't be reproduced with Mozilla 1.0(Mozilla/5.0(X11;U;SunOS sun4ul en-US; rv:1.0.0) Gecko/20020611) on Solaris 9. "www.neoism.net/language_index_8.html" print fine.
The page specifies that the "LANGUAGE" header be in helvetica and the text be in courier, but the PS selects times-bold for the header and times-roman for the text. I believe the text was formatted using courier character width data, but then printed using times-roman instead. The underlined words are actually positioned correctly, but the text preceeding them is narrower than it should be, leading to the gap. A line of text containing an underlined section would result in three postscript "show" commands: one for the start of the line, one for the underlined section, and one for the rest of the line. Each show command includes the location on the page where the printer should begin writing the text to the page. The spot where the text should end isn't specified; it's implicitly the sum of the widths of the characters that were written. In the case at hand, it looks as though mozilla was using courier to calculate the first block of text on each line, but then switched to times to print it and for processing the rest of the line. The underlines seem to be the right length, and the text following the underlined words appears to be positioned correctly; this implies that it used times width data for those sections. I can't reproduce this with a current copy of mozilla. Stig, I know it's been a long time since you reported this. Do you happen to remember what version of mozilla you were using when you experienced this problem? By any chance are you still experiencing this problem?
No response from the reporter. Resolving Works for me. If anyone can reproduce this with a current version of mozilla, feel free to reopen it.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.