Hi, thanks Tora and Christian for looking into this topic. The root cause of all these issues is that some fonts that are required to display a document as intended are not available on a system.
> That is impossible You cannot even list every known font. There are > billions of fonts out there.... One could make the "fake fontlist" configurable. Of course this has to be designed very carefully to avoid disappointment: The is conflict potential when a font name shows up but the corresponding font is just not available. >> What a current OpenOffice.org user has to do after migration from >> Microsoft Office on Windows to OpenOffice.org on one of the UNIX >> variants is: >> [snipped instructions for the Font Replacement dialog] The font replacement dialog should not be needed for a situation like this. The one exception is when the VCL.xcu/fontconfig/... based fallback does not suffice. This should only happen, when e.g. company XYZ has a private font "XYZscript", someone outside the company needs to work on the document and doesn't have the original font but just a similar one. > No, I would suggest to use the Font-Installation wizard to install the > MS-Corefonts. +1 >> It would be helpful if the font name box in the left side could list >> fonts specified in the document that he/she faces. Good idea. The same caveat about offering fonts that are not available applies, though. >> Here is another idea. The dialog File - Properties could have a tab >> for fonts like Adobe Reader. The dialog would lists font names used >> in the document with real font name for rendering texts side by side. > > Yes, another concrete suggestion - although I probably wouldn't put it > into the File|Properties dialog but maybe integrate it into the Stylist > or somewhere in the Format-Menu Good idea. Please file issues. >> >> - Disclosing a real font name for rendering a preview text >> > >> > Indicating font-fallback and glyphfallback already has issues filed. http://www.openoffice.org/issues/show_bug.cgi?id=7235 >> Users cannot understand the reason why appearance of his/her document >> is ugly when automatic font replacement, font fallback, or glyph fallback >> is occurred wrongly. There is no way to diagnose the phenomenon with >> current OOo. > > Yes, I agree, therefore I support the issues that request an indication > that font/glyph fallback has occured. Yup. >> In fact, the current implementation of replacement and/or >> fallback system sometimes works wrongly. > > Yes, but then again this would be a bug in the current implementation > that should be fixed (i.e. the fallback lists should be adapted > accrodingly to produce better results) instead of adding a predefined > and hardcoded list of Font-Replacements. The predefined and hardcoded lists are really bad and almost unmaintainable, because the effort to add a new font properly is proportional to the number of known fonts: http://www.openoffice.org/issues/show_bug.cgi?id=68846 And the file format invites CVS merge conflicts, which are quite hard to resolve: http://www.openoffice.org/issues/show_bug.cgi?id=33371 > Since the font-fallback list can only cover the more commonly used > fonts, your suggestion from above (offer the fonts of the currently > opened document in the dropdown of the fontreplacment dialog) makes > perfectly sense. This way the user can easily define replacements for > the less-common fonts that maybe only she and her correspondance uses. +1 >> >> - Font file discovery procedure >> [...] > Now fontconfig should cover all this. (not sure whether chkfontpath is > still used) AFAIK chkfontpath etc. are still used if fontconfig is not available. >> On Solaris, OOo looks for TTF files recursively under /usr/openwin . >[...] >> For Solaris, that is no good. Japanese users never use Korean, Chinese >> fonts nor other ethnic ones in general, but OOo on Solaris unexpectedly >> find all font files under /usr/openwin and occupies the pulldown menu >> of fonts with the fonts that never be used. Uninstalling the packages >> related to such ethnic fonts, however, harms the stability of Sun Java >> Desktop system. > > OK, then it seems that the list of fontdirs is not useful at all and > either they should be removed completely or configurable. Or file an issue for PL to search only in the locale specific font paths... >> Additionally, on Solaris 9 and 10 with OOo 2.0.3, artificial bold and/or >> italic rendering system works improperly. Specifying bold and/or italic >> typeface on Japanese characters results in finding other ethnic font >> files. See issue 67167, issue 67197, and issue 65173. > > Then these are bugs again that should not be hidden by manual > font-overrides. Yup. I'll look into these issues. >> > No - see VCL.xcu. There are already several language-specific >> > replacement lists. >> > If you want to improve that list, file an issue and provide the fonts >> > that should be used instead. Yes. On the other hand I outlined above the unmaintainability of VCL.xcu in its current format. And considering the the immense efforts that QA has to do to test scenarios which are impacted by a VCL.xcu change, modifications in this area require so much more effort and time than just editing a few font names. If only issue 68846 (VCL.xcu format change) was ready... >> >> - Virtual font name >> >> [...] >> >> The virtual font names would be Arial, Courier, Helvetica, >> >> Times,... for Western, Mincho, Gothic, PMincho (Proportional one), >> >> PGothic for CJK,... and so on. >> > >> > Bad idea IMHO. What would that be good for anyway? >> > OOo doesn't ship fonts, so these documents will look different on every >> > computer, depending on the fonts installed. >> >> Different look among different platforms is unacceptable in the Japanese >> office suite market. The broken text layout due to lack of font >> availability is ranked in the top 10 reasons why users hesitate to >> migrate from Microsoft Office on Windows to OpenOffice.org on other >> platforms. What can be done to display a font exactly the same as on the originator's computer, if the font is just not available? I think fallbacks are the best solution to this unsolvable problem. > You would not be able to prevent the documents from looking differently > when the fonts are not installed. You need the same fonts on every > computer that should display the document. Unfortunately this is the only real solution. > I still think that modifying the internal font-fallback list with that > info is the better approach +1 [...many other interesting points snipped...] -- Herbert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
