Bug 245744

Summary: Font selector always points to the same font
Product: [Fedora] Fedora Reporter: Akira TAGOH <tagoh>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: eng-i18n-bugs
Target Milestone: ---Keywords: i18n, Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-06-27 13:26:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
a document file that contains Japanese, Korean and Hindi. none

Description Akira TAGOH 2007-06-26 13:19:19 UTC
Description of problem:
When typing various languages on the same instance of OOo, the font selector
always points to the same font that is the default font for current locale. it
introduces a confusion because that font doesn't actually contains any glyphs
for other languages say.

Version-Release number of selected component (if applicable):
2.2.1-18.3.fc8

How reproducible:
always

Steps to Reproduce:
1.run oowriter with LANG=ja_JP.UTF-8
2.open an attached document
3.moving the cursor around the characters and see what the font selector points to
  
Actual results:
it depends on the locale OOo is running on and the default font for that locale.
on the fresh installed Rawhide box, it shows me Sazanami Gothic or like a
localized font name "さざなみゴシック"

Expected results:
it should displays the real font that is using for the rendering.

Additional info:

Comment 1 Akira TAGOH 2007-06-26 13:19:19 UTC
Created attachment 157897 [details]
a document file that contains Japanese, Korean and Hindi.

Comment 2 Caolan McNamara 2007-06-26 13:48:34 UTC
I've gone to extraordinary measures to do just the opposite :-)

We always display the fontname that is set in the character properties for the
text in question. The default style will point to the default font for the
locale of the document in question, and the locale of blank doc you are given to
start with is that of the system locale. You change them with format->character.

If we cannot find a font that some text wants to use, or if that font does not
have the appropriate glyphs, we then substitute them. There just isn't a UI for
showing that some text is being rendered in a substituted font so you don't know
for what text this has happened.

Things are complicated a little in that OOo splits the world into 3 categories
of CJK, CTL and Western. Where each category can have a different font, but
there is no implementation of a different font for every different language and
autodetection of the language in use and auto-swap to that language's default
font. Nor is there an implementation of "show me where the font has been
substituted"

We don't show the "real" font for substituted text because the "canonical" font
for text is what the document's properties *want* the text to be rendered in,
e.g. "Times New Roman" for an imported .doc.

If you start a new document and then type text, it will use the font that is set
for the default style and that's the font that you want that text to be rendered
in. If it happens not to be possible then the font is substituted.

Comment 3 Akira TAGOH 2007-06-27 06:54:37 UTC
Hmm, once that is set into the character properties, the behavior what you
mentioned makes sense. that way would probably be safe and useful feature to
modify such documents to not break it, particularly if one's required to bring
it back.
However what otherwise you are saying sounds like a stall. "default" is really
convenient word, isn't it? but OOo doesn't shows me the font as "default" and
that is correct behavior as long as I type characters that is comfortable for
the locale OOo is currently running on, and it's obviously the real fontname
being used for characters.

Also the important thing is, whether this behavior works well or not really
depends on how it finds the substitute fonts. this means OOo may makes the
incompatible documents and other applications that supports OpenDocument format
or other format OOo supports may be unable to display it correctly since all the
character properties has the same font name. you may want to suggest to change
the font name explicitly in this case. but how come OOo do that automatically
even though OOo knows that it's a substitute font?

FWIW Word looks sane at this point. they change the font at the font selector
when typing something that the current font doesn't have and choose the suitable
one then.

Presumably this is the sort of the usability bug.  Sorry for reopening BTW.


Comment 4 Caolan McNamara 2007-06-27 07:46:46 UTC
We have three categories CJK/CTL/Western, text is broken into those 3 categories
and the font for each is separately set. See
tools->options->openoffice.org->language settings->languages->enhanced language
support if it is not already visible. Then format->character shows the three
fonts in use for each category.

On startup the system locale is determined, and the
/usr/lib*openoffice.org/share/registry/data/org/openoffice/VCL.xcu is loaded and
the locale entry is examined for the appropriate set of LATIN_TEXT, CTL_TEXT and
CJK_TEXT. We take the first entry in each and ask fontconfig if it is available,
and if not what fontconfig suggests as the replacement. This set of fonts is put
as the three default fonts, at this stage we *are* able to set the values to the
true fonts that are in use, not the original name we looked up. Hence we have
the "Liberation" font as the default LATIN font in e.g. an en_US locale as
that's what fontconfig will suggest for "Times New Roman"

At this point when you type characters, the fonts to use are already set in the
default style. So if you type CJK chars the CJK font is used for them. If the
CJK font cannot handle them then the substitution kicks in, the UI will always
tell you what the font set in the properties is. We don't change the properties
of text when the font set in the properties can't display the characters.

Honestly, I can't see that there is a problem here. 
We will always display the font that is set in the properties for the category
of text under the cursor. that's a good thing.
We will use fontconfig to substitute missing glyphs if the font can't display
them, that's a good thing.

If the Font selector always points to the same font regardless of CTL/CJK or
Western text, then the font has been set to be the same for all those three
categories. So check your three fonts when you startup OOo and tell me what they
are, and what locale you have run OOo from ?

Perhaps what you really want is that when in a CJK locale you want to set a
different default CTL and Western font, but that has the obvious problem that
there's no general way to know what would be a good CTL or Western font to set
for those categories when running in a CJK locale. Honestly there is no bug here
AFAICS.

Comment 5 Akira TAGOH 2007-06-27 12:43:15 UTC
(In reply to comment #4)
> At this point when you type characters, the fonts to use are already set in the
> default style. So if you type CJK chars the CJK font is used for them. If the
> CJK font cannot handle them then the substitution kicks in, the UI will always
> tell you what the font set in the properties is. We don't change the properties
> of text when the font set in the properties can't display the characters.

Ok, I see. what I really want is, to change the properties of text when the font
set in the properties can't display the characters. but *only* when those
properties are created. For reading the existing document and looking at them,
I'm assuming those was correct on where it was created. but not here say.
because I or someone just doesn't have those fonts here/there.  So changing the
font in the properties allows to have the proper font set in the properties when
I'm creating any documents just now say.

> Honestly, I can't see that there is a problem here. 
> We will always display the font that is set in the properties for the category
> of text under the cursor. that's a good thing.
> We will use fontconfig to substitute missing glyphs if the font can't display
> them, that's a good thing.

OOo displays the font that can't display them without a substitute font, and
fontconfig actually chooses the different font and gives us substitute missing
glyphs. that's a bad thing, I mean.

> If the Font selector always points to the same font regardless of CTL/CJK or
> Western text, then the font has been set to be the same for all those three
> categories. So check your three fonts when you startup OOo and tell me what they
> are, and what locale you have run OOo from ?

さざなみ明朝 a.k.a. Sazanami Mincho for Western, さざなみゴシック a.k.a.
Sazanami Gothic for CJK and さざなみゴシック for CTL here. as I wrote in the
steps to reproduce, I'm running OOo on ja_JP.UTF-8 locale.
However I don't think it would really helps. I suppose Hindi should be
categorized in CTL though, Hangul and Japanese is categorized in CJK. since the
default font in the default style here is Sazanami Gothic, current OOo always
points to Sazanami Gothic for them, though, doesn't it?

> Perhaps what you really want is that when in a CJK locale you want to set a
> different default CTL and Western font, but that has the obvious problem that
> there's no general way to know what would be a good CTL or Western font to set
> for those categories when running in a CJK locale. Honestly there is no bug here
> AFAICS.

Not really. I'm not sure how OOo deals with the font properties internally
though, OOo should be able to know if it's a substitute font or a font what OOo
queried to fontconfig. is it possible to put that real font into the properties
when typing something then? I'm not fully understanding what's the problem if
doing so instead of just using the font from three categories, Western, CJK and CTL.

Comment 6 Caolan McNamara 2007-06-27 13:26:55 UTC
"what I really want is ... to change the properties of text when the font
set in the properties can't display the characters. but *only* when those
properties are created"

Unfortunately for your POV it's already too late when the font is found not to
handle the new glyphs. These properties are not created on keystroke, but belong
to the character style for the text, and this comes by default from the
paragraph style, and that exists before any text is typed. All the base
properties exist when the document is initially created. There is no capacity
for deferring this until the first keystroke in a new document and then
triggering off the category/language-guess/missing-glyphs-detected of those
letters. There's no difference from OOo's POV between editing existing text and
creating new text, all the properties are set already.

There's no automatic language guessing and anything hooked off that to then
replace the current font with a better font for that language. And to replace
the current selected font with the "what it is being substituted with font" is
just the wrong thing to do, esp. as there is no proper way to distinguish
between the editing-existing-document and writing-new-document case. 

Future versions of OOo will have some language guessing support, and it may then
be possible to hijack that and provide an additional feature/macro which could
use detecting the language of the new text as typed to look up in a table of
fonts what to force the new text to use. That table could then be filled in by
querying fontconfig for the best font for each language. I'd be really dubious
about whether that feature would really fly very well, though it might work for
the majority of CJK/CTL cases.

Unfortunately, if you want to have different text in the same CJK category to
have different fonts set in their properties then you have to select the
affected text and set the desired font for it. Doing it automatically when the
current font doesn't have glyphs would break editing existing documents.
Language guessing may provide a future way out of this, but would be tricky. 

This is an edge case when writing text that is all within the same category but
then turns out to need different fonts to display it all. I don't feel like I'm
doing a good job of being convincing :-( but I cannot fix this, I don't even
believe there is something to fix. But feel free to raise it on oo.org upstream
if you want to get a wider developer point of view on it, maybe there's a second
opinion on it.