Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Incorrect ToUnicode table mapping for ligatures in PDF | ||
---|---|---|---|
Product: | gsl | Reporter: | awkawk <akirkpat> |
Component: | code | Assignee: | hdu <hdu> |
Status: | CLOSED FIXED | QA Contact: | issues@gsl <issues> |
Severity: | Trivial | ||
Priority: | P3 | CC: | fonts-bugs, hdu, issues, jbf.faure |
Version: | OOO310m11 | ||
Target Milestone: | OOo 3.3 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- | ||
Issue Depends on: | |||
Issue Blocks: | 112382, 112263 |
Description
awkawk
2009-11-27 06:17:42 UTC
MRU->HDU: maybe same problem as issue 95057? @pl: The root cause seems to be that PDFWriterImpl::createToUnicodeCMap() doesn't handle 1:n glyph-
>unicode mappings yet. PDFWriterImpl::drawLayout() has a similar problem. It gets the indices into the
text string but it just stores the first char at the index instead of all text until the next used index.
target @hdu: committed a naive LTR solution to CWS vcl108; please prepare SalLayout::GetNextGlyphs for the following cases: - ligature at end of GetNextGlyphs run: the two or more Unicodes of a ligature could be split over GetNextGlyph runs, that needs to be avoided - RTL/LTR switches. . Removing accessibility keyword. This is simply a broken PDF export, nothing specific to accessibility. Targeted for OOo 3.3 anyway. Fixed in CWS vcl108 which got into DEV300_m71. For ligatures in RTL runs there is the followup issue 112382. Got into DEV300_m71 -> closing |