Hi,
Thank you for your comments.
I forgot to mention about target users. I would like to discuss
features from novice user's point of view.
I am a software engineer and can understand your points, but I
cannot tell all casual users how to do that.
>> - Listing unknown font names in the font name substitution dialog
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?
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.
It would be helpful if the font name box in the left side could list
fonts specified in the document that he/she faces.
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.
>> - 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. In fact, the current implementation of replacement and/or
fallback system sometimes works wrongly.
>> - 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?
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.
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.
I have not yet given a "Go" sign for Japanese OOo 2.0.3 official release
due to those bugs.
>> - Language tuned predefined font name substitution
>>
>> Current implementation has a predefined list of font substitution,
>> but the list is generally defined regardless of the language in
>> which a document is written.
>
> 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.
>> - Font file discovery procedure
>>
>> With current implementation, OOo always finds a font file to render texts.
>> That would be controversial. Please consider the following two facts:
>>
>> 1) Assume that a font name specified in a document is MS Micho and you
>> computer has a font named Kochi Mincho. You might want OOo to
>> automatically use Kochi Mincho for MS Mincho to render texts.
>
> Use Font-Replacement. This is exactly for things like that.
>
>> 2) Manually filling a font name box with a nonexistent font name like a
>> single letter x or some letters like "Hello World" sounds no sense,
>> but current OOo chooses a font in any way to render texts.
>>
>> 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.
>> - Virtual font name
>>
>> This is an idea by someone in the Japanese community. Users specify
>> virtual
>> font names in their document and OOo will automatically choose appropriate
>> physical font files installed in their computer. The virtual font names do
>> not depend on users' platform. Exchanging document files between different
>> computer environments or platforms is being demanded. So, we can try not
>> to
>> rely on physical font names when authoring documents.
>>
>> 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?
> 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.
>> 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.
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.
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.
>> - 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?
>> - Font name replacement in an export filter
>>
>> For interoperability, OOo could have a capability of replacing font names
>> specified in a document with corresponding font names that are available
>> on targeting platforms.
>
> See above. This again sounds like a bad idea to me. This will again
> result in documents being formatted differently. Especially when you
> talk about:
>
>> For instance, when saving a document in one of the Microsoft Office file
>> formats, a font name Kochi Mincho available on Linux could be
>> automatically
>> replaced with MS Mincho available on Windows.
>
> Microsoft Office and not other target-formats such as html or other
> target-platforms, then I cannot agree.
This idea comes from marketing strategy, not technical one. If you want
to convince potential users to migrate from Microsoft Office to OpenOffice.org,
you might have to give a good impression to them that users will not be
face a problem with interoperability.
So, this feature would be needed in the export filters for only Microsoft
Office file formats that has been dominating over the Japanese office suite
market.
Guess what platform is the most used one in the Japanese PC market?
It is Windows 98 second edition.
Actually, Windows 98 second edition sometimes cannot shows Japanese texts
in the file initially prepared with OpenOffice.org on Linux or Solaris,
or makes a text layout broken because of unknown font names.
In the many sites where migration from Windows to Linux has been done,
there is becoming a big problem: lack of interoperability with Windows.
They have to save their OpenOffice.org document into Microsoft Office
format and send it to their contacts as an e-mail attachment.
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?
> So apart from the "OOo should indicate when it uses a fallback
> font/glyph fallback and tell what font it uses instead", I don't think
> that any of the other stuff is necessary.
Now we are at the starting point...
> ciao
> Christian
ciao
Tora
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
