Apache OpenOffice (AOO) Bugzilla – Issue 82703
AQUA: PDF export fails when the document contains non-subsettable fonts
Last modified: 2008-01-17 09:44:15 UTC
Hello I am writing a document with French and Japanese text, I noticed that exporting it to pdf yields a pdf file where the japanese text is unreadable (maybe due to a font mismatch ?). I also opened the document with a linux OO.o 2.2 and exported it to pdf and the japanese text is then readable ont the resulting pdf file either on the linux box and the OS X machine (seems there is a font substitution for Japanese) I can provide odt and pdf file but can not find how to submit them through the web interface for the moment
Created attachment 48964 [details] odt file containing french and japanese
Created attachment 48965 [details] Readable output produced by pdf export from OO.o 2.2 on linux debian platform
Created attachment 48966 [details] unreadable (japanese) output produced by pdf export on aqua version
Does the same occur in the X11 version of ooo on the Mac? Could this be similar to http://www.openoffice.org/issues/show_bug.cgi?id=81286 ? Or is it completely different?
adding keyword
I don't think it is the same bug as http://www.openoffice.org/issues/show_bug.cgi?id=81286 since the author of the later claims that both files look the same in preview whereas in my case, the output is not readable either in preview, evince or acrobat reader (linux and aqua version)
reassigning
accepting Subsetting "Hiragino Kaku Gothic Pro W6" seems to fail.
Subsetting PS-Opentype fonts is not yet implemented (issue 43026) and "Hiragino Kaku Gothic Pro W6" is one of those. As a temporary workaround could you use the Osaka font? Eventually enable the bold attribute to match the weight of the W6 font. *** This issue has been marked as a duplicate of 43026 ***
Duplicate to issue 43029 instead => reopening
Fixing the duplicate issue id and adjusting issue summary to the root cause. *** This issue has been marked as a duplicate of 43029 ***
Though issue 43029 is the real root cause on why the font was not subsetted, the font should not have been marked as "subsettable" when this is not yet the case. The problem is that during font enumeration the required info is not directly available and doing the obvious thing could increase the startup time considerably.
.
Issue 43029 is already covering the root cause of the problem. The remaining problem is that font subsetting is not disabled for fonts where subsetting is not implemented yet even though this operation is bound to fail. This remaining problem gets fixed in CWS aquavcl04. Also adjusting the issue summary line to this remaining problem.
@PL: please review in CWS aquavcl04 (vcl/aqua/source/gdi/salatsuifontutils.cxx 1.9.2.1)
fixed but failed ? doesn't quite work for me.
reopen
ok, the font subsetting problem is solved, but the exported file still looks like crap due to the glyph fallback thing.
verified
Got into OOH680_m2 => closing