Closed Bug 423047 Opened 12 years ago Closed 12 years ago

letter-spacing is ignored in printing output but results in gaps before italics

Categories

(Core Graveyard :: GFX, defect, P2)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bugzilla.i.sekler, Assigned: vlad)

References

Details

(Keywords: regression)

Attachments

(4 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031404 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031404 Minefield/3.0b5pre

A non-zero "letter-spacing" property gets ignored in printing output but results in gaps or collisions before italics. It doesn't happen with cairo image fallbacks. Print preview is OK.

Last good: 2008-02-19-04
First bad: 2008-02-20-04

Bug 418353?

Testcase follows.

Reproducible: Always

Steps to Reproduce:
1. Print the testcase to a PostScript file
2. Open the PostScript file or convert it to PDF first and open the PDF file

Actual Results:  
No letter-spacing in the first and the third paragraphs, but italics are moved to the right (letter-spacing > 0) or to the left (letter-spacing < 0) from the expected position.

The table that triggers the usage of image fallbacks shows correct letter-spacing.


Expected Results:  
Correct letter-spacing in the printing output like in the table below (but without image fallbacks, of course).
Attached file Testcase
Version: unspecified → Trunk
Could you provide the original PostScript? It is difficult to work out what cairo is doing after the cairo PostScript has been reprocessed by ghostscript.
This time really from the uploaded testcase, not from a local file with a different title.
Attachment #309559 - Attachment is obsolete: true
I thought this may have been the cairo bug was causing incorrect glyph positioning in PostScript output due to a bug in the font subsetting (fixed in bug 421422).

However that is not the cause of this bug as each glyph in the italic font is positioned individually (due to the shear transform in the font matrix) instead of relying on the glyph widths in the font.
It turns out to be that the symptoms of this bug have nothing to do with italics, a span with an empty (or just a different) style gets equally misplaced if printed. Please feel free to adjust the summary to something that makes more sense.

Sorry for the spam!
Just to get things finally right: the spans are not misplaced in the printing output, quite the contrary. The starting position of each textrun in a line respects letter-spacing, only the positioning of glyphs from that point on ignores it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
+'ing w/ P2.  We should fix as many printing issues as possible.  Assigning to dholbert.  

Daniel please take a look and suggest any changes to priority and/or blocking.
Assignee: nobody → dholbert
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Blocks: 418353
Bug 418350 (which regressed this bug AFAIK) doesn't seem to have a patch posted, so here's a link to the changes in Bonsai:  http://tinyurl.com/2oxe25
Bouncing to Vlad per IRC conversation.  My cairo-fu is not so strong, whereas vlad's is.
Assignee: dholbert → vladimir
(In reply to comment #9)
> +'ing w/ P2.
> ...
> Daniel please take a look and suggest any changes to priority and/or blocking.
Blocking & P2 seems reasonable to me.
Thanks for taking a swing at this, Daniel.  :)
Yep, Cairo bug -- glyphs are being incorrectly placed in the PS backend.  Cairo uses a PDF-like emulation layer so that it can output the same commands for PS as for PDF, and the implementation of the text matrix and text output operators isn't correct.  I've sent mail to the list, Adrian and I should be able to come up with a fix soon.
Looks like Adrian already fixed this a few days ago.
Depends on: 419715
Duplicate of this bug: 426078
Should be fixed by cairo upgrade; can folks verify?
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Verified with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040717 Minefield/3.0pre

Checkout start: Mo 7. Apr 17:00:59 CEST 2008

Thanks!
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.