Apache OpenOffice (AOO) Bugzilla – Issue 17320
Bitstream Vera Sans not used in Setup
Last modified: 2004-01-28 13:25:54 UTC
Install (internal) OOo 1.1 SRX645__m14s1.8665. => GUI font is not Bitstream Vera Sans (Vera.ttf) This worked in CWS mh11rc. You can also try a current SO inhouse version: 1. run setup with parameter -dontdeletetemp 2. cancel setup 3. remove /tmp/sv001.tmp/soui.ttf 4. cp Vera.ttf /tmp/sv001.tmp 5. /tmp/sv001.tmp/setup et voila, also SO falls back to something else (probably "Luxi Sans"). With this small 'trick' an old SO setup srx645_m6-1.8639 displayed nice Vera Sans. Probably broken due to issue 15238: > ---- Additional Comments From Kevin B. Hendricks 2003-06-30 18:01 PDT --- > I have also added Luxi Sans in the vcl/source/gdi/fontcfg.cxx and > vcl/source/gdi/outdev3.cxx right before Bitstream Vera Sans so that the > installation should be readable as well. This de facto disables the use of Bitstream Vera Sans for the Setup.
Set 'Target Milestone' to 'OOo 1.1.1'.
cp->us: i think this is a feature to have a proper setup for latin-2 language installation. Why do you think it is required that setup comes up with Vera ?
Why is it required to have "Vera" at all? I know that there is probably no requirement nailed down. But for consitency reasons perhaps? 1. Run the setup from an already installed OOo 1.1 (in order to modify, repair or remove the installation). It comes up with Vera. 2. OOo application window uses Vera (depending on the locale) Why shouldn't the initial Setup use Verra also? Couldn't we establish a locale depending use of Vera in initial Setup, like we already do for korean or chinese in SO/OOo. In this case define "Lucida Sans" or what ever for Latin2 languages and make "Vera Sans" the (western) default. This would also lead to consistency with VCL.xcu and makes it easier to manage these files. source/gdi/fontcfg.cxx: [412] #define FALLBACKFONT_UI_SANS_KOREAN "SunGulim;Gulim;Roundgothic;Arial Unicode MS;Lucida Sans Unicode;Tahoma;Andale Sans UI" [413] #define FALLBACKFONT_UI_SANS_CHINESE "Andale Sans UI;Tahoma;Arial Unicode MS;Kai;Ming;Interface User;Geneva;WarpSans;Dialog;Swiss;Lucida;Helvetica;Charcoal;Chicago;MS Sans Serif;Helv;Times;Times New Roman;Interface System"
This is a small step for a developer but YOU have to test it each time we have to add a language. Whereas now it just works. Is there really demand to spend time on this ?
I am convinced that QAing of this issue would become easier or more transparent, if the setup would use the same fallback mechanism than the Office. No doubt!
.
the setup must not use the configuration so there's no chance to use the same mechanism. The setup will die after 1.1. So the pleasure of having Vera instead of Luxi for latin-1 setup versions has a forseeable future. Even less as the Linux distros will provide rpms anyway.
us->cp: you know of the importance of OOo and that there is no second chance for a good first impression. Furthermore we will probably have to live a long one year and a half with this milestone and thus with this setup. I'd prefer a fix.
cp->ssa: we need to have font configuration entries for latin-2 languages in fontcfg and vcl.xcu (use vera for latin1 and lucidux for latin2). please have a look at it.
fontcfg and outdev3 now distinguish check for latin2 languages and will only in this case use luxi sans before vera sans. other (western) languages will use vera sans but no luxi. Fixed in CWS vcl7pp1r2.
Please check in vcl7pp1r2.
Verified in cws. Also ok in master srx645_m27s1-1.8738. Changing Resolution to FIXED in order to set issue as VERIFIED.
Issue verified.
Closing resolved/verified OOo 1.1.1 issue.