|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Problem with accent in vertical text when exporting to PDF | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | gsl | Reporter: | becho4 <becho4> | ||||||
| Component: | code | Assignee: | AOO issues mailing list <issues> | ||||||
| Status: | CONFIRMED --- | QA Contact: | |||||||
| Severity: | Trivial | ||||||||
| Priority: | P3 | CC: | fonts-bugs, hdu, issues | ||||||
| Version: | OOo 2.4.0 | ||||||||
| Target Milestone: | OOo 3.x | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||
| Developer Difficulty: | --- | ||||||||
| Issue Depends on: | |||||||||
| Issue Blocks: | 95057, 97991 | ||||||||
| Attachments: |
|
||||||||
|
Description
becho4
2008-04-01 10:21:25 UTC
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. |