Apache OpenOffice (AOO) Bugzilla – Issue 87686
Problem with accent in vertical text when exporting to PDF
Last modified: 2013-07-30 02:13:19 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.
Created attachment 52424 [details] Sample writer document
Created attachment 52425 [details] Sample writer document exported to pdf
Reassigned to HI.
Reassigned to HDU
changed component
Confirmed with DEV300_m16
have to retarget (I hope to get a solution for OOo3 though)
Probably related to issue 97326
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.
And would you perchance enlighten me with your wisdom what exactly is supposed to be wrong in there ?
> 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.
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.
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.
s/aPixOfs/aOrientedOffset/
target
Reset assignee on issues not touched by assignee in more than 2000 days.