Hi *, On Mon, Aug 21, 2006 at 07:12:21PM +0900, tora wrote: > Christian Lohmaier wrote: > > That is impossible You cannot even list every known font. There are > > billions of fonts out there.... > > Yes, that is impossible. > > 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: > > 1. Open an existing Microsoft Office document to convert it into > OpenOffice.org file format. > 2. Click on font name box. > 3. Type Ctrl-A to choose the font name. > 4. Type Ctrl-C to copy it. > 5. Go to Tools - Options - OpenOffice.org - Fonts. > 6. Enable an option for font replacement. > 7. Fill a font name box in the left side by typing Ctrl-V to paste it. > 8. Choose one of fonts in the right side to replaces a font in his/her > document with a font installed in his/her computer. > 9. Repeat steps 2 to 8 until all fonts are successfully replaced. > > Who can tell such a complex procedure to novice users?
No, I would suggest to use the Font-Installation wizard to install the MS-Corefonts. I admit that this might only work for western languages and not necessarily for CJK... > Most casual users do not know a text box left next to a rectangle > mark denoting pull down menu is editable. So most users of current > OOo cannot use the font replacement feature in the dialog of Tools - > Options - OpenOffice.org - Fonts because no candidate in his/her > document is listed. But that is another issue - could be solved by modifying the dialog or other means. > It would be helpful if the font name box in the left side could list > fonts specified in the document that he/she faces. OK, that is a good suggestion. Not listing random fonts that might be installed on OS XYZ, but fonts the user actually is lacking/using. > 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 > >> - Disclosing a real font name for rendering a preview text > > > > Indicating font-fallback and glyphfallback already has issues filed. > > > > But I don't know why you would only do this in a preview text. So maybe > > I got you wrong. > > 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. > 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. Font-Replacement is 1:1 mapping. When you don't have the replacement font installed, then you won't gain anything from that. OOo would still need to perform its own font-replacement. That's why the font-fallback lists need to be improved instead of predefining font-replacements. (I hope I could communicate my point) 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. > >> - Font file discovery procedure > > > > ?? more info please. > > OOo uses fontconfig now, so that should no longer be an issue, should > > it? > > On Linux, OOo seems to use /usr/sbin/chkfontpath and/or fontconfig? chkfotpath was the old way. It used a hardcoded list of font-path and chkfontpath if present. If chkfontpath was not available, it only used the built-in fonts. That is what caused most troubles. Now fontconfig should cover all this. (not sure whether chkfontpath is still used) > On Solaris, OOo looks for TTF files recursively under /usr/openwin . That is one of the hardcoded paths. (and it is not recoursive, but lists some dirs below that) http://go-oo.org/lxr/source/gsl/psprint/source/fontmanager/fontmanager.cxx#2181 > 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. > 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. > > 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. > > Oh, it looks good. I did not know that. > > officecfg/registry/data/org/openoffice/VCL.xcu > === > <node oor:name="msmincho" oor:op="replace"> > <prop oor:name="SubstFonts"> > > <value>hgmincholsun;hgmincholightj;ipamincho;sazanamimincho;kochimincho;mspmincho;hgminchoj;h > gminchol;minchol;mincho;hgheiseimin;heiseimin;minchou;msgothic;mspgothic;hggothic;hggothicb;hggothice;a > ndalesansui;gothic;arialunicodems;lucidaunicode</value> > </prop> > ...snip... > <prop oor:name="FontType"> > <value>CJK,CJK_JP</value> > </prop> > </node> > === > > Hmm, that must be revised ASAP. The Korean font mincho is included in > the list and is badly located prior to other Japanese fonts. When filing the issue make sure to explicitly mention what fonts shall be removed. I for example wouldn't know which ones of the above are korean ones... > >> [what to do when a font is not present/doesn't include all > >> characters] > >> In the case 2, some might want OOo not to render texts but to show > >> special > >> characters such as a rectangle or question mark meaning that no > >> appropriate > >> glyph is available. > > > > No, then you would get that whenever you import a document that was > > written on another computer, with different fonts set for the > > characters. > > It can be said that if a function finds something wrong, the function should > not try to correct it or even hide the mistake, otherwise no improvement will > be done forever. See above, that is another reason why OOo should indicate that it used a fallback. But not displaying characters at all is the wrong solution. That way you would be forced to manually find a suitable font that contains the characters just to read the document. IMHO it is much better if OOo just indicated for what stuff it did a fallback (maybe using highlighting with a tooltip showing the actual font used) instead of displaying "blocks" instead. > >> - 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. > > Please consider why OOo has Format - Page for choosing a sheet size instead > of File - Page setup. It is a simple reason. It is better for office suites > to handle documents regardless of the ability of physical printers. > Like that, fonts could be more ideal rather than what font files are installed > in user's computer. Don't you think so? No, I don't think so. Since then a two-page document might end up on three pages in another environment. Basically the "Virtual font name" in you proposal is nothing else than the inbuilt font-fallback. 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. So either I didn't understand what you meant with that virtual font-names or it is already covered by OOo's font-fallback. > > And since you can enter anything in the font-tab (i.e. set a > > non-installed font for your document) this can already be done. > > Most casual users do not know they can directly type in the font name box. > What they know is that they can click on the triangle mark to see a list > of fonts and to choose one of them. Yes. And offering a "virtual" font in that list will make them think that the font is installed and/or that their document will look the same on the other computer. (since the other computer lists the same font in the dropdown). But then imagine the surprise and anger when the document does *not* look the same because the two computers did have different fonts isntalled that are used instead of the virtual one. > >> How does it work? For example, a virtual font Mincho for Japanese > >> document > >> will be MS Mincho on Windows, Kochi Mincho on Linux. The same font > >> Mincho > >> for Korean document will be something on Windows, Micho on Linux. > > > > No, bad idea. > > You try to compensate lack of predefined font-replacement tables with > > that approach. Either you use the font that is installed and set into > > the document (and have the document look like it was intended) or you > > have to fall back on another font. > > To have virtual font names, we should make the predefined font-replacement > table more accurate. It would not be compensation but cooperations with > two features: predefined virtual font names and predefined font-replacement. See above, I don't think that will work. > Oh, I forgot to mention the fact underlying the Japanese office suite market. > Five basic fonts such as MS Mincho shipped with Microsoft Windows Japanese > are provided by one font vendor. The vendor also releases several fonts > using the same glyph and geometry data, naming HG Mincho on Solaris, > IPA Mincho for Linux and Windows shipped with an open source software. So if the fonts can be shipped with open-source software, then why not adding them to OOo or make them available using Font-OOo? > The original data of those fonts MS Mincho, HG Mincho, IPA Mincho, XX Mincho, > are maybe identical. That was the reason why someone in the Japanese > community proposed the virtual font system over multi-platforms. I still think that modifying the internal font-fallback list with that info is the better approach > >> - Fake font name for targeting platforms > >> > >> For interoperability, OOo could provide users with fake font names that > >> were not available on their computer but available on targeting > >> computers. > > > > Again: OOo cannot know what will be installed on another computer. > > As in Christof Pintaske's response, the number of well-known fonts are > limited. > So OOo could know that. > > The file VCL.xcu already lists well-known fonts, doesn't it? Yes. But I'm still not a fan of it. It will make my document look different even when I moved my linux-fonts to the windows-box since the export wrote a different font into the file.... I really don't like that idea/approach. > [...] > The recipients face broken text layout, garbage characters, and/or > missing glyphs and ask the sender to resend it. Consequently, the sender > reluctantly rewrite it with Microsoft Office. Can you accept this story? I see the problem, but providing a virtual font or modifying the font on export won't really help. Sure, they might get all the characters, but the layout might be messed-up nevertheless. Better use the same fonts from the beginning. If you already know that you gonna send your document to a MS-user, limit yourself to the MS-Fonts. Apart from that, your comparison is kindof unfair since you're comparing linux with windows. When writing your document with Microsoft Office on linux (using crossover office/wine) then you would face the same problems. An when creating the document with OOo on windows, you won't hit the problem. ciao Christian -- NP: Bush - Alien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
