Apache OpenOffice (AOO) Bugzilla – Issue 81602
[VI] Characters not displaying in Help 2.3
Last modified: 2013-08-07 15:02:34 UTC
Two of our users have reported display problems in OpenOffice.org 2.3 Help. (Note: 2.3 is our first release to include any of the Help translated, so we cannot compare with previous versions. We have over 25% of the Help translated in OpenOffice.org 2.3.) There are two problems, when displaying the VI 2.3 Help in Windows XP: 1. The upper-case crossed D (Đ) (U+0110) does not display in the Help: as far as we can tell, it does not display _at all_ in any part of the help. Instead of U+0110, the user sees an empty white box, such as that shown when a font is not available. However, these users have the appropriate fonts, and this character displays correctly for them in the interface of the same build. Please see this image: http://picasaweb.google.com/lh/viewPhoto? uname=cumeo89&aid=5110350534790164449&iid=5110350620689510386 Note the white boxes where U+0110 should appear, at the beginning of two of the headings, and at the beginning of the last link listed. 2. Sections of the Help text are difficult to read or completely unreadable: they are fuzzy and/or have missing characters. User 1 reported this problem, for example, in the "Welcome to OpenOffice.org Help" section. User 2 supplied this screenshot: http://picasaweb.google.com/lh/viewPhoto? uname=cumeo89&aid=5110350534790164449&iid=5110350624984477698 Note the first red-ringed section. The text is unreadable. The text shown is this string (from the GSI file): ___ helpcontent2 source\text\swriter\main0503.xhp 0 help par_id3147768 5 0 en-US $[officename] Writer lets you create both basic documents, such as memos, \<link href=\"text/shared/guide/fax.xhp\" name=\"faxes\"\>faxes\</link\>, letters , resumes and \<link href=\"text/swriter/01/01150000.xhp\" name=\"merge documents\"\>merge documents\</link\>, as well as long and complex or multi-part documents, complete with bibliographies, reference tables and indexes. 2002-02-02 02:02:02 helpcontent2 source\text\swriter\main0503.xhp 0 help par_id3147768 5 0 vi $[officename] Writer cho bạn có khả năng tạo cả tài liệu cơ bản, như bản ghi nhớ, \<link href=\"text/shared/guide/fax.xhp\" name=\"fax\"\>điện thư\</link\>, lá thư, sơ yếu lý lịch và \<link href=\"text/swriter/01/01150000.xhp\" name=\"trộn tài liệu\"\> tài liệu đã trộn\</link\>, lẫn tài liệu dài, phức tạp hay đa phần, cũng có thư tịch, bảng tham chiếu và chỉ mục. 2002-02-02 02:02:02 ___ The text "resumes and" (translated as « sơ yếu lý lịch và » is completely unreadable. It is fuzzy, and some characters are missing. The second red ring is another example of problem #1 above, but within the Help text, not only in titles or links. Since we have not had any of the Help translated before this release, do you think there might be display issues with our language? Vietnamese does test out Unicode support, although more commonly with the combined-diacritics characters. U+0110 is not unique to our language: it is used in some European languages. We have no idea what could be causing the unreadable text. [Note: User 1 also experienced white boxes instead of Vietnamese characters (not only U+0110, but all non-Latin-1 characters) in the screens following double-clicking on the install file. User 1 has installed previous builds, and has not experienced this problem with any pre-2.3 Vietnamese builds. I mention this in case it might be connected to this issue. I do not have screenshots as yet: when I do, I will report this as a separate issue.] [Platform-specific? I have checked my OSX 2.3 build, and this problem does not exist on my platform. I don't know at this stage if it exists on all Windows systems, or only on XP.] Please advise how we can start to address this Help display issue. It certainly doesn't make our Windows builds (by far the majority of our users use Windows) look professional. :( Clytie Siddall, Vietnamese Free Software Translation Team
OK, I'll only take the first issue here as the Summary says (and as our guidelines say: one issue per issue). Empty white boxes means that the font used on the machine doesn't support the character to be displayed. Please try this: 1. Select the paragraph with empty white box, paste it into other application - e.g. Notepad or something where you CAN write that letter. What happens? 2. Paste it into Writer and try to change fonts - do you see the correct letter in some font? 3. Try changing fonts for help - see *.css files in your installed_path/help/vi directory.
The reason I've reported them together is that I don't know if both things are part of one problem, or not. I can't see how I could be expected to know that. If we find that they are separate problems, I can create another bug. But for now, they could both be part of the same problem. Pavel, as I said in the bug report, the character U+0110 displays correctly in the OpenOffice.org 2.3 _interface_ for these users, and when _inputting_ in OpenOffice.org 2.3. It just doesn't display correctly in the Help of the same build. So this is not a missing-font issue. These same users can display that character in any number of other apps, and can display it on the interface of the same OpenOffice.org build (for example, the name of the menu Format starts with U+0110 in our language, and that displays correctly), and they can input it into OpenOffice.org 2.3: it's only in the Help of OpenOffice.org 2.3 that U+0110 does not display. If it were a missing font, there would be a lot more characters represented by white boxes. Regardless, I will request our users do as you said.
It's interesting looking at the Help stylesheet: even though Help displays correctly in my OpenOffice.org 2.3 Vietnamese build on OSX (Intel X11), it doesn't look good. The CSS file says: ___ /* +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++ + OPENOFFICE.ORG 2.0 HELP + + DEFAULT STYLESHEET + + WESTERN LANGUAGES + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++ + LAST CHANGES: 15-NOV-2004 + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++ */ body, p, h1, h2, h3, h4, h5, h6, .listitem, .listitemintable, .tablecontent, .tablecontentintable { font-family: "Bitstream Vera Sans",Arial,Helvetica,Lucida,Geneva,Helmet,sans-serif,"Andale Sans UI","Arial Unicode MS","Lucida Sans Unicode",Tahoma; } .code, .codeintable, .example, .exampleintable, .literal, .literalintable, .path, .pathintable { font-family: "Bitstream Vera Sans Mono",Cumberland,"Courier New",Courier,"Lucida Sans Typewriter","Lucida Typewriter",Monaco,Monospaced; margin-top: 1pt; margin-bottom: 1pt;} ___ so that definitely needs updating. I'm not even sure Bitstream Vera covers our whole character set, although I didn't find any missed characters in the Help. But it doesn't do it well. Recommended fonts for different languages are listed here: http://wiki.freedesktop.org/wiki/Software/Fonts As you can see, we have nominated Deja Vu as our best free font (they have worked with us on supporting our language), or the designed-for-Vietnamese urwvn GPL fonts. On OSX, Lucida Grande is far and away the best font for Vietnamese, but it's not a free font. Is Vietnamese suffering, in the Help, from using a Roman script, and thus being handled as a "Western" language? We require UTF-8 and a pan-Unicode font. How can we set Deja Vu or urwvn for OpenOffice.org Vietnamese Help?
Pavel, your suggestion (3) is spot on. User 2 tried changing the font in the Help css file, resulting in this screenshot: http://picasaweb.google.com/cumeo89/OpenOffice/photo?authkey=U- Vfl94gTj0#5110470952788242450 You can see he is delighted about this. :) So the font Bitstream Vera Sans (NOT recommended for Vietnamese) is the culprit. If OpenOffice.org is going to set a font for "Western" languages, it should be a font that covers more of the Unicode range more effectively, like Deja Vu Sans. It covers a lot more than Bitstream Vera Sans. Also, the Deja Vu font project works actively and continually on improving its range, where Bitstream Vera is not, AFAIK, currently maintained. If we can choose fonts per language for Help, we can _ensure_ each language is displayed correctly. The FreeDesktop page I quoted could be used as a reference for this. So, how soon can we fix this font error? Looking at part 2 of my bug, I'll ask the user if changing the font affects that problem, as well. If not, then it is indeed a separate problem, and I will report it separately.
clytie: great. Thus the fix is to provide back fixes *.css files. They are in the source, so fixing them in the source is the right way to do so. See http://documentation.openoffice.org/source/browse/documentation/helpcontent2/source/auxiliary/ vi/ Please attach new .css files that work for you here and I'll commit them.
OK, I'll attach the edited CSS file here. I've added the fonts we need (which also cover a very wide range) to the beginning of the fonts listed. I haven't changed anything else, but I think the documentation team should really review this file: there have been quite a few improvements in Unicode fonts in the last couple of years. Gentium is one of those improvements: I've added GentiumAlt because it also supports a very wide character range, including our language. I wasn't sure if you meant "edit the current CSS file" or "create a separate CSS file for Vietnamese": I've done the first. I can also do the second if it you like.
Created attachment 48257 [details] Updated CSS file to support Vienamese in Help
Thanks! Clytie, please also teste them on other systems or ask your users to test them on other systems. Reassign to Frank to add/review these CSS files.
added to hcshared12, I also adjusted the other *.css accordingly
Please verify in CWS hcshared12
ok in hcshared12.
Closing.