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
Version-Release number of selected component: openoffice.org-core-2.4.0-4.1.fc9.i386
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.
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.
"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.
hmm, So, it's kind of WONTFIX (Impossible) Feature_Request...?
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.