Apache OpenOffice (AOO) Bugzilla – Issue 67167
Bold, Italic Asian characters are displayed inappropriately.
Last modified: 2006-09-15 04:51:24 UTC
Phenomenon: Bold, Italic Asian characters are displayed inappropriately on Solaris. This seems to happen regardless of a type of application. Reproduction: Solaris 10 x64/x86 with Japanese font packages LANG environment variable: ja_JP.UTF-8 1. Open the bugdoc.odt attached. 2. Change zoom rate from 100% to 50% or 200% and confirm what happens. The invisible texts become visible at the rate of 75% and 200%. 3. Copy some texts in the document to Calc and a text box of Impress.
Created attachment 37613 [details] A bugdoc
Created attachment 37614 [details] Its snapshot
Created attachment 37615 [details] Its exported PDF
Additionally, please think of font names listed in the pulldown menu of OOo: HG-MinchoL-Sun Hg Minchol sun Those two names might come from one font file: /usr/openwin/lib/locale/ja/X11/fonts/TT/hgmlsun.ttf The appearances, however, look different. Confirm them with the snapshot. The text "HG-MinchoL-Sun" can be found in a table "name" of the file. But, i am not sure where the text "Hg Minchol Sun" comes from.
File - Document Properties - Fonts of Acrobat Reader says: TimesNewRomanRS-BoldMT TimesNewRomanPSMT HG-MinchoL-Sun Baekmuk-Dotum (*1) FZXSSB--B51-0 (*2) TimesNewRomanPS-ItalicMT Neither *1 nor *2 is specified in the document, but they are embedded in the PDF. *1 seems to come from either: /usr/openwin/lib/locale/ko/X11/fonts/TrueType/sundotumf.ttf /usr/openwin/lib/locale/ko/X11/fonts/TrueType/sundotump.ttf *2 seems to come from: /usr/openwin/lib/locale/zh_TW.BIG5/X11/fonts/TT/ming.ttf
pl->hdu: please have a look
I'm wondering if the problem is related to the X-servers native fonts. To test this please go into OOo's program directory, set an environment variable and then start OOo. Depending on the shell do either export SAL_ENABLE_NATIVE_XFONTS=0 ./soffice 67167.odt or setenv SAL_ENABLE_NATIVE_XFONTS 0 ./soffice 67167.odt Does this help? If it does then the result of xlsfonts | grep -i MinchoL would be interesting.
Specifying "export SAL_ENABLE_NATIVE_XFONTS=0" seems not to help much. - The invisible text now becomes visible. - Unaware Korean and Chinese-like fonts are still embedded in the exported PDF. Just in case, here is a result of "xlsfonts | grep -i MinchoL" -ricoh-hg minchol sun-medium-r-normal--0-0-0-0-c-0-jisx0201.1976-0 -ricoh-hg minchol sun-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0 -ricoh-hg minchol sun-medium-r-normal--0-0-0-0-c-0-jisx0212.1990-0 -ricoh-hg minchol sun-medium-r-normal--0-0-0-0-c-0-jisx0213.2000-1 -ricoh-hg minchol sun-medium-r-normal--0-0-0-0-c-0-jisx0213.2000-2 -ricoh-hg minchol sun-medium-r-normal--0-0-0-0-m-0-jisx0201.1976-0 -ricoh-hg minchol sun-medium-r-normal--0-0-0-0-m-0-jisx0208.1983-0 -ricoh-hg minchol sun-medium-r-normal--0-0-0-0-m-0-jisx0212.1990-0 -ricoh-hg minchol sun-medium-r-normal--0-0-0-0-m-0-jisx0213.2000-1 -ricoh-hg minchol sun-medium-r-normal--0-0-0-0-m-0-jisx0213.2000-2 -ricoh-hg pminchol sun-medium-r-normal--0-0-0-0-p-0-jisx0201.1976-0 -ricoh-hg pminchol sun-medium-r-normal--0-0-0-0-p-0-jisx0208.1983-0 -ricoh-hg pminchol sun-medium-r-normal--0-0-0-0-p-0-jisx0212.1990-0 -ricoh-hg pminchol sun-medium-r-normal--0-0-0-0-p-0-jisx0213.2000-1 -ricoh-hg pminchol sun-medium-r-normal--0-0-0-0-p-0-jisx0213.2000-2 hg-minchol hg-minchol.jisx0201
Created attachment 37631 [details] Appearance on the display with SAL_ENABLE_NATIVE_XFONTS=0
Created attachment 37632 [details] Its exported PDF, SAL_ENABLE_NATIVE_XFONTS=0
One additional thing. The direction of characters in PDF format seems correct, but italic, vertical one is rendered from left upper to right bottom, which looks a little bit confusing. The curve might be expected in an opposite way.
Before the native X11 fonts were disabled by the switch they were used to display the document. Their name matched perfectly with the font name requested in the document. Because X11 fonts cannot be exported to PDF the fonts were substituted. Unfortunately not by the "HG-Minchol-Sun" font. I'll analyze this. The other problem seems to be that the X11 server has problems with certain sizes of these fonts. Run xfontsel -scaled -pattern "-ricoh-hg*" -sample16 xxxx and play with the pxlsz size to isolate this problem. For the problem with wrong artifical slanting and emboldening of vertical glyphs please submit an extra issue to PL. We don't see vertical glyphs in the sample PDFs you attached though.
Created attachment 37690 [details] The same bugdoc, 67167.odt, opened with StarOffice 7 PU5 en
Created attachment 37691 [details] Its PDF exported with StarOffice 7 PU5 en
Created attachment 37692 [details] Trys to show how font name looking up system is working.
Created attachment 37693 [details] Its snapshot
Facing the result depicted in the snapshot 67167-shorter-fontnames.png, we would need to reconsider of the font name looking up system.
Could we escalate this issue from P3 to P2? Since predefined styles Heading 1 through 10 have a typeface either Bold or Bold-Italic which has a problem with rendering texts, - Users cannot use predefined styles Heading 1 through 10. - Existing OOo documents cannot be displayed properly. I have just tried to confirm this issue with CDE on Solaris 9 SPARC, appearance of a text in any style Heading n looks like a series of center-aligned dot. Don't you think that cannot be acceptable?
Is there any practical way to quickly solve or hide this issue? E.g. providing users with modified libvcl680ss.so According to the Security Bulletin 2006-06-29, http://www.openoffice.org/security/bulletin-20060629.html all users of 2.0.x prior to 2.0.2 have been urged to upgrade their OOo to 2.0.3. OOo 2.0.3 Solaris x64/x86 and SPARC, however, have been suffering from this issue.
Is there any progress? All platform versions of OpenOffice.org 2.0.3 except Solaris ones have been released to the Japanese market. The status of release process: issue 65763. This issue and other font related issues (issue 67197 and issue 67176) might be obstacles in the way of releasing 2.0.3 Solaris Japanese.
Impact: Users of Solaris with Japanese environment cannot use any predefined style with Bold and/or Italic typeface. E.g. Once a user apply a style Heading 1 to a text, the text disappears or is rendered with an inappropriate font. Quick Investigation: Tracing system calls with "truss -t open -p process_id_of_soffice.bin" reveals that applying bold and/or italic typeface results in finding another font file as Western system does. However, Japanese font sets have only normal typefaces. I.e no bold, italic, bold-italic, font file is provided because of its tremendous number of characters. Apparently, there is something that can be considered.
set target to 2.1
hdu->hdu reminder: HG* font special emboldening (#114999#)
Fixed in CWS vcl65. There is a family of fonts where "special embolding" makes sense. I.e. if font A is selected and bold is enabled then font B was to be used. This works fine unless font B is not available => in this case we use artifical emboldeing instead
Also fixed in CWS boldhg. Please verify.
SBA: Target set to OOo 2.04, as discussed with MH and UL. Setting dependency to issue 68046. Verified in CWS boldhg.
How can I appreciate all of you? Thanks a lot for the fix in time to the upcoming release.
SBA: OK in OOD6980m4 Build9069. Closed.
*** Issue 59785 has been marked as a duplicate of this issue. ***
*** Issue 67176 has been marked as a duplicate of this issue. ***