Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Problem with accent in vertical text when exporting to PDF|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||fonts-bugs, hdu, issues|
|Target Milestone:||OOo 3.x|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
|Issue Blocks:||95057, 97991|
Description becho4 2008-04-01 10:21:25 UTC
- Create a new writer document - Place a text drawing object - Fill in a text with an accent, for example "FormaciÃ³n" - Rotate the Text object to 90 degrees - Export the document to pdf The text object in resulting pdf document contains "Formaci". The word is truncated.
Comment 2 becho4 2008-04-01 10:22:54 UTC
Created attachment 52425 [details] Sample writer document exported to pdf
Comment 3 michael.ruess 2008-04-01 10:50:51 UTC
Reassigned to HI.
Comment 4 h.ilter 2008-04-01 15:54:20 UTC
Reassigned to HDU
Comment 5 Mathias_Bauer 2008-04-21 16:29:25 UTC
Comment 6 email@example.com 2008-06-04 13:05:35 UTC
Confirmed with DEV300_m16
Comment 7 firstname.lastname@example.org 2008-06-05 15:25:21 UTC
have to retarget (I hope to get a solution for OOo3 though)
Comment 9 email@example.com 2009-01-12 10:57:00 UTC
Not related to issue 97326. @pl: since CWS glyphadv PdfWriter_Impl::drawLayout() has bad problems in situations with nGlyphs!=1 and nOrientation!=0, because the glyph iteration in this method ignores the orientation. The bug is usually hidden by the fact that the glyph run is merged, so the PDF text matrix does the glyph position update (correctly) instead of the code in drawLayout (incorrectly). The accented glyph triggers the bug becoming visible because of its type1-glyph advance. The most simple workaround against this bug in PdfWriter_Impl::drawLayout() is to set nMaxGlyps=1 to let GetNextGlyphs() do the work of calculating the correct positions. The point of CWS glyphadv was to reduce the PDF size by merging glyph runs whereever possible, so this workaround is no good long term fix.
Comment 10 philipp.lohmann 2009-01-12 11:22:10 UTC
And would you perchance enlighten me with your wisdom what exactly is supposed to be wrong in there ?
Comment 11 firstname.lastname@example.org 2009-01-12 11:51:00 UTC
> And would you perchance enlighten me with your wisdom what exactly is supposed to be wrong in there ? Sure, listen to these words of wisdom: The line aGNGlyphPos.X() += nAdvanceWidths[i]/rLayout.GetUnitsPerPixel(); only works when orientation==0. Likewise the line when the vertical-alternate glyphs are enabled aGNGlyphPos.Y() += nAdvanceWidths[i]/rLayout.GetUnitsPerPixel(); only works when orientation==2700. The proper solution is to advance the glyph postion in the direction requested by the orientation.
Comment 12 philipp.lohmann 2009-01-12 12:01:03 UTC
and where o wise master do I get the information from that the direction changes within a glyph run ? And why doesn't the layout deliver different orientations in a run in the first place ? Since obviously the advancement array in such a case does not make much conceptual sense.
Comment 13 email@example.com 2009-01-12 12:24:29 UTC
A layout and thus a glyph run only has one orientation. The advancement array is in the direction of that orientation. The individual glyph positions are thus something like nPixelWidthSum = nAdvWidthSum / rLayout.GetUnitsPerPixel() Point aPixOfs = Point( cos_oriented*nPixelWidthSum, sin_oriented*nPixelWidthSum) aGNGlyphPos = aBasePoint + aOrientedOffset Since some orientations are more common than others and a glyph run often contains just one glyph there are some obvious optimization possibilities.
Comment 14 firstname.lastname@example.org 2009-01-12 12:27:00 UTC
Comment 15 philipp.lohmann 2009-01-12 12:31:34 UTC
Comment 16 Rob Weir 2013-07-30 02:13:19 UTC
Reset assignee on issues not touched by assignee in more than 2000 days.