|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Reversed parethesis when exporting Hebrew documents with Type1 fonts to PDF | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | gsl | Reporter: | ulf.stroehler | ||||||||||
| Component: | code | Assignee: | eric.savary | ||||||||||
| Status: | CLOSED FIXED | QA Contact: | issues@gsl <issues> | ||||||||||
| Severity: | Trivial | ||||||||||||
| Priority: | P3 | CC: | alan, hdu, issues, nyh, shlomif, xslf, yba, yuval | ||||||||||
| Version: | OOo 2.0 | Keywords: | regression | ||||||||||
| Target Milestone: | OOo 2.3 | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | All | ||||||||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||||||
| Developer Difficulty: | --- | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
ulf.stroehler
2004-11-04 16:41:56 UTC
Reassigning Clone to HDU. Target to be discussed. Confirming issue. . Any chance for this to have a milstone set? this has been fixed, broke again, and is highly visible on Linux (where the Hebrew fonts are moslty type1) Sorry, should have been 2.0, but would have been re-targeted meanwhile. Soshanna, can you confirm that the described problem does only affect PDF-Export in conjunction with Type1 fonts? Or do we still fail to display brackets right in a different context too? >Soshanna, can you confirm that the described problem does only affect PDF-Export
in conjunction with Type1 fonts?
Yes, this seems to be the case (tested with m69).
However, I discovered another anomality- since around m62 or m65, it seems that
gpdf (2.8.1) fails to display any Hebrew in type1 fonts created by OOo. xpdf
displays the fonts ok, but with some artifacts.
PDF's with type1 Hebrew fonts created with older versions of OOo display OK in gpdf.
Should I file another issue for that? this seems to be very annoying...
Created attachment 21474 [details]
simple test doc
Created attachment 21475 [details]
PDF created from the test doc
Created attachment 21476 [details]
screenshot: original file in writer, file in xpdf and file in gpdf
Thanks Shoshanna for the reply. Yes, pls. file a new issue for the gpdf findings. Additionally wouldn't it be worth an issue against gpdf? As if RC2, this bug (reversed parenthesis with type1 fonts) is still there. As the default fonts for Hebrew are Linux are type 1 fonts (culmus) this is a highly visible bug. This issue came and went for the 1.1 branch- see issue #23202 Just discovered that this happens with the Mac build as well (with the culmus fonts). Updating info. Alan- as the Hebrew version uses Culmus (which are the fonts affected by this bug), any chance that tkos will create a fix? This is a highly visible bug, and a regression from 1.1 us->hdu: this one remains uggly. Any chance for OO.o 2.0.2? This one still exists in OOo 2.1 on (gentoo) Linux. Any chance to wake this issue up (besides voting for it)? I can also confirm this bug, on OpenOffice 2.0.4 on Linux. Exporting to PDF text in the Culmus font results in reversed parantheses. If I export to Postscript instead of PDF, or if I use Microsoft's TTF fonts, the parantheses are printed correctly. This bug is highly annoying and visible, and I've been noticing it for over a year now. Created attachment 41837 [details]
Seems to fix the problem
ayaniger->hdu: I've attached a patch which seems to fix the bug. Could you review it to see if this is the best way to go about fixing the problem, and to insure that it doesn't break anything else? Thanks for the patch. It helps to isolate the problem. @pl: Please have a look at the patch. The method PDFWriterImpl::registerglyphs() seems to be the wrong function to patch though. If one of the problematic glyphs was already registered in a LTR context the patch wouldn't work and if it was registered in a RTL context then the LTR text would look wrong. Will have a look target a slightly better solution is to do this before registerglyphs since at least this will not break the embedded fonts hash. But the strong layout mode of the OutputDevice is not a good indicator; we want to get the right glyph also in weak layout mode. Need further discussion with hdu. pl->hdu: you said you wanted a different solution with SalLayout. Ok, I understand the PDFWriterImpl::registerGlyphs() method now better for the case of non-subsettable fonts. The problem in the code for this case was that though the glyphids (which were determined by the layout engine) are correct they get ignored. The assumption in the method that the glyphids correspond directly to the text's unicode was wrong. The best solution for this wrong assumption would be to map the layout engine's glyphids (i.e. FreeType's synthetic glyphid for a Type1 font) back to unicode and only then to the embeddable font's encoding. But this reverse mapping is not easily available and adding the infrastructure for it would be a lot of work (e.g. on WIN32). With the new knowledge about PDFWriterImpl::registerGlyphs() I was no longer able to come up with a realistic scenario that wouldn't work with Alan's patch and applied it. There might be problems with Type1 fonts that do not map unicodes<=U+007F to the same encoding points. If this scenario should ever become realistic we'll have to reexamine the fix. reassigning to pl: you wanted this issue back... pl->sba: please verify in CWS vcl75 SBA->ES: Please proceed. Thank you. Verified in CWS vcl75 Ok in m219 |