Hi, > On Mon, Aug 21, 2006 at 07:12:21PM +0900, tora wrote: >> 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: [...] >> Who can tell such a complex procedure to novice users?
Christian Lohmaier wrote: > No, I would suggest to use the Font-Installation wizard to install the > MS-Corefonts. I am afraid, i am not a lawyer, but copying a part of software is probably a violation of the End User License Agreement of the Windows. I am not sure, but maybe, no enterprise user copies font files from the Windows to Linux or Solaris platform. Just information. Copying a font file on the Explorer sometimes breaks the font file. To successfully copy font files, use a command prompt, cmd.exe, and cd to C:\WINNT\Fonts , and copy files from the special, tricked folder to somewhere else first, and then send them to wherever you want. >> 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. Yes, it might be another issue. With current implementation, both combo boxes in the dialog of Tools|Options|%PRODUCTNAME|Fonts list the fonts that have been installed in the computer. So it means that a user can replace one of the installed fonts with another one of the installed fonts. That does not make sense, does it? Here is just an idea. Replace the left combo box in the dialog of Tools|Options|%PRODUCTNAME|Fonts with a simple text field might be a quick solution to the confusion. A user would have to fill it with something - i.e. a font name. >> 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 OK, we could continue to discuss this topic further in another thread. >>>> - 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 Just an off topic. Thanks to the link, the phenomenon of the issue 67167 can be accountable. http://go-oo.org/lxr/source/gsl/psprint/source/fontmanager/fontmanager.cxx#2194 When the environment variable LANG is not set, the problem of the issue 67167 does not happen. /usr/openwin/lib/locale/ holds ethnic font files. >> 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. Yes, we would need some improvements. >> 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. Yes, those are bugs. >>> 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. [...] >> 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... Sure. >>>> [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. The problem might be a silent action by which OOo replaces unknown fonts with programmatically chosen fonts. How about adding a dialog that pops up when opening a document that includes unknown font names, saying "You are about to open a document that includes uninstalled fonts. %PRODUCTNAME will automatically use substituted fonts installed in your computer in place of the unknown fonts to render texts. If you want to tweak the automatic font substitution, go to the menu Format|xxx|yyy|zzz." followed by "[ ] This dialog will not be needed any longer." >>>> - 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. Exactly, the idea - virtual font name - would use the font-fallback system. > 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. I am sorry for the confusion, now i have noticed. What i wanted to say was a little bit different from the means for getting the same appearance among different platforms. The OpenDocument is a neutral file format that supports all platforms. Why don't we try to make its contents neutral, too? In other words, within a few years, we would have to move to more platform-independent world. Don't you think so? >>> 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. That could be avoidable if the font list had a note. Here is another topic that i would like to append. With current implementation, font name pull-down menu sorely lists font names and their appearances. StarSuite 8 Japanese is shipped with 15 Japanese font files. Some of them are TureType Collection (TTC), so there are, at told, 35 Japanese fonts available. The naming system of the TTC files, however, is not understandable. Fonts whose name begins with: - HG are fixed width fonts. - HGP are proportional width fonts. - HGS are proportional width fonts for Western letters and fixed one for Japanese characters. See snapshots in the page 16 of the following article that i wrote last year. http://www.nsug.or.jp/readme/no57/RM57-FA.pdf If the font name pull-down menu listed font names with short description, the menu would allow users to easily choose a desired font. With that description, we could append a short note saying either "This font is installed." or "This font is not installed and will be replaced with font xxx." >> 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? If possible, i had done it already. The reason why i cannot do that is the license of the open-source software. The font files are considered a part of the software. We cannot separate them from the software package. Here is a story behind the license. The software was developed by a vendor with the budget of the Information-technology Promotion Agency, Japan (IPA) http://www.ipa.go.jp/index-e.html , a subsidiary organization of the Ministry of Economy, Trade and Industry. It is a part of the government. They have to take care of the potential loss of font vendors. If they allow users to use the font files without any difficulty, font vendors would loose some revenue. The IPA is planning to release the font files separated from the software, but the action has not been done yet. >>>> - 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. Additionally, please consider the following user scenario: 1. Open a Microsoft Office document with OpenOffice.org on Linux or Solaris. 2. Insert some texts within existing texts. 3. Append some texts in the empty area. 4. Save the document into Microsoft Office file format and return it to the person who asked the user to edit it. Step 2 would have no problem. The inserted texts would be given a font name specified in the original document, i.e. a font in the Windows. Step 3 might have a problem. The appended texts would be given a font name available in his/her computer. The person in the step 4 would have a document with both Windows fonts and Linux/Solaris fonts. That would not be a good situation. Maybe, we would need to list both fonts: installed fonts and used fonts. And we would also mark them with either "Installed" or "Not installed." >> [...] >> 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. The concept of virtual font would be a new generation of office suites. Office documents could be more platform independent by avoiding use of platform dependent font names. Modifying font names on export could be practical solution until OOo gets share of the office suite market. > 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. You are right. Migration from Microsoft Office to OpenOffice.org on Windows is the first step. Migration from Windows to other platforms is the second one. It would be better if we could assist both migrations. ciao Tora --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
