Issue 36691 - Reversed parethesis when exporting Hebrew documents with Type1 fonts to PDF
Summary: Reversed parethesis when exporting Hebrew documents with Type1 fonts to PDF
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 2.0
Hardware: All All
: P3 Trivial with 30 votes (vote)
Target Milestone: OOo 2.3
Assignee: eric.savary
QA Contact: issues@gsl
Keywords: regression
Depends on:
Reported: 2004-11-04 16:41 UTC by ulf.stroehler
Modified: 2007-07-06 19:12 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

simple test doc (6.69 KB, application/vnd.sun.xml.writer)
2005-01-13 19:17 UTC, sforbes
no flags Details
PDF created from the test doc (168.18 KB, application/pdf)
2005-01-13 19:18 UTC, sforbes
no flags Details
screenshot: original file in writer, file in xpdf and file in gpdf (106.20 KB, image/png)
2005-01-13 19:20 UTC, sforbes
no flags Details
Seems to fix the problem (670 bytes, patch)
2007-01-02 17:31 UTC, alan
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description ulf.stroehler 2004-11-04 16:41:56 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.
Comment 1 ulf.stroehler 2004-11-04 16:44:11 UTC
Reassigning Clone to HDU. Target to be discussed.
Comment 2 ulf.stroehler 2004-11-04 16:44:47 UTC
Confirming issue.
Comment 3 2004-11-04 16:50:09 UTC
Comment 4 sforbes 2005-01-10 04:43:49 UTC
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)
Comment 5 ulf.stroehler 2005-01-10 10:45:10 UTC
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?
Comment 6 sforbes 2005-01-13 19:16:18 UTC
>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...
Comment 7 sforbes 2005-01-13 19:17:47 UTC
Created attachment 21474 [details]
simple test doc
Comment 8 sforbes 2005-01-13 19:18:32 UTC
Created attachment 21475 [details]
PDF created from the test doc
Comment 9 sforbes 2005-01-13 19:20:39 UTC
Created attachment 21476 [details]
screenshot: original file in writer, file in xpdf and file in gpdf
Comment 10 ulf.stroehler 2005-02-15 18:55:27 UTC
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?
Comment 11 sforbes 2005-10-19 07:05:34 UTC
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
Comment 12 sforbes 2005-11-15 21:41:55 UTC
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
Comment 13 ulf.stroehler 2005-11-16 08:05:56 UTC
us->hdu: this one remains uggly. Any chance for OO.o 2.0.2?
Comment 14 yhager 2006-12-21 07:39:08 UTC
This one still exists in OOo 2.1 on (gentoo) Linux. 
Any chance to wake this issue up (besides voting for it)?
Comment 15 nyh 2006-12-31 10:03:28 UTC
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

This bug is highly annoying and visible, and I've been noticing it for over a
year now.
Comment 16 alan 2007-01-02 17:31:51 UTC
Created attachment 41837 [details]
Seems to fix the problem
Comment 17 alan 2007-01-02 17:33:33 UTC
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?
Comment 18 2007-01-03 11:44:29 UTC
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.
Comment 19 philipp.lohmann 2007-01-10 09:08:22 UTC
Will have a look
Comment 20 philipp.lohmann 2007-02-20 08:23:09 UTC
Comment 21 philipp.lohmann 2007-02-20 10:22:38 UTC
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.
Comment 22 philipp.lohmann 2007-02-23 09:14:23 UTC
pl->hdu: you said you wanted a different solution with SalLayout.
Comment 23 2007-02-23 15:16:53 UTC
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.
Comment 24 2007-02-26 08:19:09 UTC
reassigning to pl: you wanted this issue back...
Comment 25 philipp.lohmann 2007-03-20 19:21:05 UTC
pl->sba: please verify in CWS vcl75
Comment 26 stefan.baltzer 2007-03-26 12:04:43 UTC
SBA->ES: Please proceed. Thank you.
Comment 27 eric.savary 2007-03-27 11:31:00 UTC
Verified in CWS vcl75
Comment 28 eric.savary 2007-07-06 19:12:31 UTC
Ok in m219