Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Font fallback is inconsistent on different computers|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||ACCEPTED ---||QA Contact:|
|Target Milestone:||AOO PleaseHelp|
|Issue Type:||FEATURE||Latest Confirmation in:||---|
Description freemant 2005-03-30 04:53:41 UTC
Environment: Win2K Pro (or XP) Traditional Chinese edition. Traditional Chinese is selected as the default in Control Panel. To see the problem: 1. Open Writer (or Calc). 2. Select an English font (eg, Arial). 3. Enter any Chinese character. 4. The char appears as a square on most computers but appears as a Chinese on some (fewer) other computers. On a computer that it appears as a square, the fallback font should be a Chinese font because I can see the char appearing fine say in Notepad. It means the OOo is preventing the font fallback mechanism in Win2K. Is this intentional? From issue 45128 I believe that the intented behavior is to fallback, but it is not happening on many of our computers. In fact, I've tried linking Arial to a Chinese font (MingLiu) but it has no effect in OOo. It works only if I link an non-existing font such as Terminal. But on some smaller number of computers, no matter what font I select, it can still be displayed as Chinese. It means somehow font fallback is working on those computers. I've checked the font linking on both computers and they are the same. I've tried these tests on both OOo 1.1.2, 1.1.3 and 1.9.69. The version doesn't matter at all.
Comment 1 christof.pintaske 2005-04-05 08:54:01 UTC
cp->hdu: I guess there is always room for improvement. Please have a look, once time permits again.
Comment 2 firstname.lastname@example.org 2005-04-05 14:40:36 UTC
From the description it looks as if you mean what we call "glyph fallback". If different systems have the same fonts the glyph fallback is consistent. Only if one font which would be needed for glyph fallback is available on one system but not on the other system then the systems behaving differently cannot be avoided. OOo depends on its own tables to implement glyph fallback and font fallback and doesn't use font linking available on some systems yet. Supporting a platform's native font linking is easy for simple applications because they don't bother with WYSIWIG issues like printing, PDF export, EPS export etc... I'll use this task as a "feature task" to support a platform's native font linking.
Comment 3 freemant 2005-04-06 02:13:12 UTC
Would you explain a bit more in details? Are you saying that on those computers that can display the Chinese char in Arial has more fonts that support Chinese? This is a very serious problem for us: A user can set the font to Arial and he doesn't see any problem with it as he can see the Chinese just fine. But when he sends the file to others, some will only see squares.
Comment 4 freemant 2005-04-06 04:13:12 UTC
I find that if a computer has Japanese fonts (MS Gothic, MS Mincho), then it can display Chinese even if the font is say Arial.
Comment 5 email@example.com 2005-04-06 13:29:23 UTC
> Are you saying that on those computers that can display the Chinese char in Arial has more fonts > that support Chinese? No, those computers just have the fonts needed for glyph fallback (e.g. Arial Unicode, Code2001, Cyberbit, MS Gothic, MS Mincho, etc.). > This is a very serious problem for us: A user can set the font to Arial and he doesn't see any > problem with it as he can see the Chinese just fine. But when he sends the file to others, some > will only see squares. Since even fonts with exactly the same name can behave differently (e.g. there are versions of Tahoma with and without Hebrew support) this is a general problem. The easiest solution is to have the same versions of the same fonts on both systems. For viewing documents the same way the author wrote them exporting them to PDF is also a good idea.
Comment 6 freemant 2005-04-07 03:48:51 UTC
Thanks for the reply. Since I have the MingLiU font which does contain Chinese glyphs, why OOo is not falling back to it?
Comment 8 ocmitvinrro 2010-10-23 15:39:09 UTC
Created attachment 72606