Bug 431524 - List of fonts to be displayed in the font drop down menu when a particular language is selected
List of fonts to be displayed in the font drop down menu when a particular la...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
: i18n
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-05 04:47 EST by Ani Peter
Modified: 2016-07-31 21:31 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-05 07:15:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ani Peter 2008-02-05 04:47:27 EST
Description of problem:

While we open a file in oowriter and activate scim to select a language for
input, why should we have a list of fonts that do not belong or reflect any
changes to that particular language. ie, For example, lets say we select
Malayalam (ml) from SCIM, which means the input will be in malayalam, at this
time why do we need to have a long list of fonts which are not going to reflect
on Malayalam. Instead, can we have only those fonts in the drop menu list which
belongs to the inputing language or which can make any change to that language.
If we need to switch on to, lets say, Gujarati (gu) , then we again select
Gujarati from the scim and at that point of time, the font menu should be having
fonts pertaining to Gujarati. And finally, when we switch to English lets have
all the font related to the English language.

I do not know whether this is a valid feature or a good suggestion. Thought of
putting it in a bug so that we can have a discussion if its valid, else I would
really appreciate if you could let me know why cant this be implemented.

Hope I have made it clear.

Thanks
Ani

Version-Release number of selected component:
icu-3.8.1-4.fc9
Comment 1 Ani Peter 2008-02-05 04:58:59 EST
Version-Release number of selected component:
openoffice.org-core-2.4.0-4.1.fc9.i386
Comment 2 Caolan McNamara 2008-02-05 05:25:09 EST
How would OOo know what the current language selected in scim was. I don't think
there there is any broadcasting of the "active language", or is there ? 

OOo doesn't know anything really about scim, it just gets what text was entered
into it through gtk. Additionally at the moment OOo doesn't know in advance what
codepoints a font supports, it only finds out when it attempts to render some
given text in the selected font if the font doesn't support those codepoints,
though that's not a fundamental block.

Anything of that nature shouldn't be specifically built into e.g. OOo but should
be a general Desktop/gnome/gtk feature so that e.g. the same thinking could
cause e.g. firefox to switch languages for spellchecking automatically when the
"active language change" was broadcast, and then OOo and evolution could do the
same, assign the newly typed text to the language that was last broadcast. And
that's still kind of a mismatch to the current scim concept e.g. consider
different languages that share a common scim (or lack of scim) IM, i.e. English
and French or the direct unicode code point input engine for all languages. So
the language is orthogonal to the IM used to enter text, but if the IM
infrastructure had a mechanism to set the language and tell apps what it was,
then it could default the language to the most likely one that a given IM engine
is associated with if the user doesn't tell it any different.

There would still then be some misery in OOo as OOo only categorizes character
properties into "Western", "CJK" and CTL so further categorizing of fonts down
to what codepoints they support and mapping those to the last broadcast active
language would be needed, but I guess it would be eventually doable.

And maybe some fun open questions as to how far should such an IM language be
taken, just as language property for text entered into an app, or should it go
further and do crazy things like cause an app to swap a dialog from LTR to RTL
if a dialog was popped up in english, and then an arabic IM is selected.
Comment 3 Ankit Patel 2008-02-05 06:22:18 EST
I think it's a good feature request.

Definitely, scim IM doesn't have any feature to broadcast the language selected,
but I think this should be doable, once someone starts typing in his/her native
language with the help of scim/iiim or any other input method by reading the
codepoints of the characters entered and comparing it with the database, which
should be made based on the latest unicode chart.
Comment 4 Caolan McNamara 2008-02-05 06:40:02 EST
"by reading the codepoints of the characters entered and comparing it with the
database, which should be made based on the latest unicode chart." 

Now you're talking about selecting stuff *after* the text is entered and not
based on the current status of the IM but on the text itself that we receive. 

It is possible to get *some* answers for categorizing the text based on the
unicode code points. There is code in OOo to split into CJK/CTL/Western and
that's how the existing three sets of fonts and font sizes that you see in
format->character come from when started in a CTL/CJK locale or with
tools->options->languages enable CTL/CJK. That's a solid categorization, but
even there we already have the concept of "weak" characters like ", a space and
other whitespace and punctuation marks where the surrounding characters
categorization is used to figure out what font those "could be any category"
characters should be rendered in, e.g. what do you want to happen if you type
some english text a ' mark a space character and then some malayalam text, which
font should be used for the ' mark and the space character.

Boring down further to split the categories into sub-per-language-categories is
difficult because there are plenty of languages that share common unicode code
points, e.g. most western languages use about 95% the same characters, and the
CJK languages also have a *lot* of overlapping codepoints, so you cannot in
general know the language based on the entered code point, though you can make
some guesses and maybe for indic languages you could solidly be sure. 

As well we even have libtextcat which we use for making a *guess* as to the
language of an entered word, but only as a suggestion on right-clicking a
mis-spelled word.
Comment 5 Ankit Patel 2008-02-05 07:15:45 EST
hmm,

So, it's kind of WONTFIX (Impossible) Feature_Request...?
Comment 6 Caolan McNamara 2008-02-05 09:10:52 EST
For OOo alone unaided, I think its a WONTFIX as I can only think of
"never-quite-right" solutions. 

If there was a gtk/xdg sort of protocol/signal/standard to propagate a "current
input language" setting around the place I'd be happy to then have a look at
supporting OOo integration with such a feature.

Note You need to log in before you can comment on or make changes to this bug.