Apache OpenOffice (AOO) Bugzilla – Issue 105631
IPA PGothic,IPA PMincho font can't be printed
Last modified: 2009-12-03 17:19:54 UTC
Writer can't print Japanese font [ã”] by IPA P Gothic or IPA P Mincho. It, however, can do by IPA Mincho and IPA Gothic. Proportional fonts might have some problem. In case printing to a pdf file and printing it by a pdf viewer software, it can do correctly. It might be OOWriter's ptinting problem.
Created attachment 65151 [details] Sample document
Hi. I'm IPAfont package maintainer in Debian. I want to clearfy that this is not font specific issue, but OpenOffice.org's one. With some different Japanese fonts, similar issue would happen (I'll attache test case). And I saw that printing expert folks triaged this issue at Printing-japan (Japanese discussions on printing under Linux) and its conclution is OpenOffice.org embeds font data into PS file wrongly. See https://lists.linux-foundation.org/pipermail/printing-japan/2009-October/002465.html With newer versions of CUPS that have PDF workflow, this bug would appear.
Created attachment 65579 [details] test case with some Japanese font
Hi, I'm a member of OpenPrinting, the standardize organization of *nix printing. Printing-Japan ML is our discussion ML in Japanese. I'll roughly translate the e-mail henrich_d attached. This e-mail is written by Koji Otani, implementer of the PDF workflow. ---------------------------------------------------------------- OOo make wrong PS data with embedded font, but this problem caused only in PDF workflow. (Translator Remark: PDF workflow is OpenPrinting's new printer workflow. Final goal is all of applications creates PDF instead of PS, and CUPS filters handles PDF, because PDF is light, Page-oriented, any other good feature from printing point of view. Currently, some distribution, especially Debian Lenny (or later) and Ubuntu 8.10 (or later) have supported this workflow) Problem 1. ========== OpenOffice.org has wrong login when it creates PS with embedded fonts. In this case, OOo embed Type 42 (Truetype) fonts, however, some glyphs of unprinterble characters (e.g. 「ã”〠of IPA P Gothic) put with GID == 0 (for .notdef glyph only). This output is wrong. And also Encoding is wrong. For example, when 「ã”ã€is assigned in code == 1, Encoding[1] should be related glyph name (glyph1), but OOo put the name to Encoding[0]. Encoding[1] leave as .notdef. Problem 2. ========== Ghostscript can proceed that kind wrong PS (maybe it's a kind of bug). 　　( code --> .notdef -->　GID==0) So we have no problem without PDF workflow. In the PDF workflow, PS data with problem 1 translated to PDF by Ghostscript without any changes about font feature, then the PDF translated to PS. In this process, this issue caused. PDF workflow is need newer CUPS, so this issue depends on the CUPS version. And we only have the problem in Debian Lenny (or later) / Ubuntu 8.10 (or later), that's why only the two distros supports PDF workflow now. ----------------------------------------------------------------
hdu: Could you please re-assign to appropriate person? change component gsl as this is not a ja issue. many many thanks!
Created attachment 65663 [details] ps-result for the second sample document
Created attachment 65664 [details] screenshot from a ps-viewer
I'm not sure that I understand the problem yet: 1. On which milestones was the problem confirmed? If it was DEV300_m56 or older then please check again with something newer (e.g. DEV300_m6x or OOO320_m0x) 2. Does the problem exist in the ps-export I attached (created with DEV300_m60 and IPA2.03 fonts)? 3. Would the problem be visible in the screenshot of a postscript-viewer? I attached a screenshot. If the problems are visible there please highlight them and attach the resulting image.
hdu: Thanks for your looking into this issue. Please see the .png file you attached. In the fourth line and tenth line, two 「ã”ã€s are missing. Please compare the fourth line and tenth line the .ps file you attached. You will see 「ã”ã€in fourth line and tenth line. thanks!
Created attachment 65665 [details] Missing 「ã”
Created attachment 65666 [details] Missing 「ã”〠is highlighted
hdu: > 1. On which milestones was the problem confirmed? If it was DEV300_m56 or older then please check again with something newer (e.g. DEV300_m6x or OOO320_m0x) sorry not for this time. > 2. Does the problem exist in the ps-export I attached (created with DEV300_m60 and IPA2.03 fonts)? to me, it's okay. http://www.openoffice.org/nonav/issues/showattachment.cgi/65663/i105631_fontcheck.ps > 3. Would the problem be visible in the screenshot of a postscript-viewer? I attached a screenshot. If the problems are visible there please highlight them and attach the resulting image. http://www.openoffice.org/nonav/issues/showattachment.cgi/65664/i105631_psviewed.png visible, I highlighted where are the missing chars in http://www.openoffice.org/nonav/issues/showattachment.cgi/65666/i105631_psviewed_maho.png thanks!
So the problem ares the lines with "Encoding 0 /glyph1 put" in the postscript file. The problem is reproducible with the old versions such as OOo31. AFAIK this is supposed to be prevented by http://hg.services.openoffice.org/DEV300/file/75b77d6c0e63/vcl/unx/source/fontmanager/fontmanager .cxx#l3661 which seems to come directly from http://gsl.openoffice.org/source/browse/gsl/psprint/source/fontmanager/fontmanager.cxx? r1=1.30&r2=1.31 I'm not exactly sure how this is supposed to work. Reassigning to the author.
Hi, I've add comment with png file that maho attached one. Not only missing "ã”" with IPA P Gothic/Mincho but also missing "ãˆ" with VL Gothic/VL P Gothic and MS P Mincho and "ゆ" with Sazanami Gothic. Thanks.
Created attachment 65680 [details] missing glyph "ã”" "ãˆ" and "ゆ" is highlighted
target
We, OpenPrinting recommends all of applications (and all of distros) will change their print workflow from Postscript workflow to PDF workflow. So we hope OOo also shift to PDF workflow. In distros with PDF workflow already supported (e.g. Ubuntu and Debian stable), these kind of bug will be gone and we'll have a better performance. However, we're not sure that we have any problem to use PDF print data in distros with PS workflow (e.g. Fedora right now). Technically it should work fine, but we can't know about hidden issues. So now our rational choice is OOo (or any other applications) have a switch to select print format. This switch don't need UI, just packager of each distros can be select which is suitable. We know this proposal needs big change, so if we need another process not only issue tracker but also some kind of feature request system, please let me know.
duplicate to 106833 *** This issue has been marked as a duplicate of 106833 ***
closing