Apache OpenOffice (AOO) Bugzilla – Issue 36691
Reversed parethesis when exporting Hebrew documents with Type1 fonts to PDF
Last modified: 2007-07-06 19:12:31 UTC
Cloned task for *** Issue 33265 *** with target milestone: OOo 2.0 Cloning issue, because reversed hebrew brackets with Type1 fonts does still occur in PDF export.
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