Bug 39971 - Indian languages not listed in the languages combobox in font styles
Summary: Indian languages not listed in the languages combobox in font styles
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
(See in Summary)
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-10 01:49 UTC by Shriramana Sharma
Modified: 2013-11-22 12:00 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Indian languages in a context menu (22.25 KB, image/jpeg)
2013-11-01 12:21 UTC, Urmas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shriramana Sharma 2011-08-10 01:49:11 UTC
Sanskrit is one of the important languages for India and nearby regions. While it is not commonly in use for worldly life, the majority of the religious and some old secular literature of India is in Sanskrit. 

Sanskrit is also written in many scripts of India including Devanagari, Gujarati, Bengali, Oriya, Kannada, Telugu and Malayalam and some minority scripts like Grantha and Sharada which have been accepted for encoding in Unicode.

Ergo texts composed using these scripts can easily be containing Sanskrit language material.

Sanskrit has its own ISO 639 codes san and sa: http://www.sil.org/iso639-3/codes.asp?order=639_3&letter=s

Despite all this, LibreOffice does not provide Sanskrit in the list of languages. There are only two languages starting in San: Sango and Santali:

Sami *
Sango
Santali
Sardinian *

Please include Sanskrit in the list of languages so Sanskrit language text may be identified properly.
Comment 1 Jaganadh G 2011-11-22 08:26:56 UTC
This feature is still missing in LibreOffice 3.4 too
Comment 2 Björn Michaelsen 2011-12-23 12:27:27 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 3 Florian Reisinger 2012-08-14 14:02:47 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 4 Florian Reisinger 2012-08-14 14:03:43 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 5 Florian Reisinger 2012-08-14 14:08:18 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 6 Florian Reisinger 2012-08-14 14:10:22 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 7 Shriramana Sharma 2012-08-14 14:39:59 UTC
This bug still exists. I have confirmed in version: Version 3.7.0alpha0+ (Build ID: 5af60dc

If I enter a Sanskrit language text in Devanagari script, and right-click it and go to Tools > Language > For *, I do see Sanskrit now but even if I click on it, the language indicated in the status bar stays at Hindi.

And under Right-click > Character > Font > Language, there is still no Sanskrit.
Comment 8 Florian Reisinger 2012-08-15 11:40:35 UTC
Has it been translated into that language? If no, the community didn't. I am very sorry for that
Comment 9 Shriramana Sharma 2012-08-15 14:45:46 UTC
Perhaps I wasn't clear enough. I'm not complaining that the LibreOffice interface is not available in the Sanskrit language. I fully understand that the community has to do that translation. I am saying that I am not able to markup text as Sanskrit, whatever be the interface language.

Steps to reproduce:

1. Load up LibreOffice -- whatever be the interface language.

2. Type some Sanskrit language text:

धर्मक्षेत्रे कुरुक्षेत्रे समवेता युयुत्सवः

3. Select the text

4. Via Tools > Language > For Selection or Right click > Character > Font > Language -- try to select Sanskrit.

Observed effect:

Sanskrit language is available in the Tools menu entry (in 3.7alpha but not in 3.5 release) but clicking it has no effect and the status bar still indicates Hindi as the language. Sanskrit language is not even listed in the right click Character dialog (in any version).
Comment 10 Steve White 2013-09-26 22:36:46 UTC
I am confirming this for LibreOffice 3.6.2.2 and 4.0.2.2, and explaining a partial fix.   Unfortunately, the fix doesn't do very much.

Not only is Sanskrit missing, but also Hindi, Bengali, Malayalam, Kannada, Oriya, Tamil, Marathi, Sinhala,  ... I guess all Indic languages are missing...
But also Thai is gone.

The immediate problem can be overcome, in my case by installing package
      libreoffice-l10n-hi
Installing any one of the "CTL" (Complex Text Layout) language packages will change the Character Formatting dialog, so that it has a menu containing all these South Asian scripts. 

But what to do is completely unclear.  This document
    https://help.libreoffice.org/Common/Languages_Using_Complex_Text_Layout
talks specifically about Hindi and Thai, but only says to select them from the menu.  It doesn't say what to do *to get those languages onto the menu*.

This needs to be plainly documented somewhere, preferably near where the user observes the problem.

Unfortunately, setting the language for Sanskrit is a bit of a disappointment.  The language selector seems to have no effect regarding font display.  (Probably it only affects spelling and hyphenation.)

In particular, many consonant combinations are written as ligatures in Sanskrit, but not in Hindi, although they are both written in the Devanagari script.

In this case, setting the language to Sanskrit should pass the OpenType language tag 'SAN ' to the font rendering libraries, which would activate features particular to Sanskrit.

So long as your underlying libraries can handle Indic font shaping, this should be an easy fix.
Comment 11 Shriramana Sharma 2013-11-01 08:26:14 UTC
Looks like I myself had formerly reported this against OOo (https://issues.apache.org/ooo/show_bug.cgi?id=87484) and they just closed it as "IRREPRODUCIBLE" -- I suppose that means something like "WORKSFORME".
Comment 12 Shriramana Sharma 2013-11-01 10:03:44 UTC
[By error, the first few lines of this post was included as a separate comment. Sorry for that.]

Looks like I myself had formerly reported this against OOo 2.4.0 (https://issues.apache.org/ooo/show_bug.cgi?id=87484) and they just closed it as "IRREPRODUCIBLE" -- I suppose that means something like "WORKSFORME". Now I don't care to follow-up the bug on the OOo tracker -- it's LibO for me all the way. 

So I'll just clarify the bug here.

If you have some text, Format Menu or right click > Character > Font > Language should give you the language tag to apply to the text. Currently, in this combobox, Indian languages are not mentioned.

Note that this also applies to Styles and Formatting > Default Style (or any style) > Right-click > Modify > Font > Language.

While Tools > Language > For Selection/Paragraph/All Text seems to list some known languages corresponding to the script of the selected text, if the required language is not visible in this and we click More, from "For Selection/Paragraph" we are taken to the same Font dialog which again does not provide the Indian languages. 

OTOH from "For All Text" we are taken to the Tools > Options > Language Settings > Languages where we are apparently allowed to select the "Default language for documents".

Under this there are three comboboxes -- Western, "Asian" and "CTL". I am not sure what is the rationale between the separation of "Asian" vs "CTL" -- both Asian and non-Asian scripts require CTL IIUC. And the Asian and CTL comboboxes are disabled in the absence of any language packs.

As Steve says if I install any one language pack (to be precise, at least the libobasis4._-__ package) for an Indian language (I tried Tamil and he tried Hindi so I guess the rest would be same too) the CTL combobox in the Tools > Options dialogue gets enabled and also the font dialog is upgraded to show a separate "Western text font" from a "CTL font", in which the combobox providing the language of the CTL font includes names of Indian languages. Still the combobox for the "Western text font" does not provide the names of Indian languages. 

The whole Western text font vs CTL font is a quite silly segregation -- I am not sure what it is in aid of. It seems to be copied from Microsoft Office. Even when I was using MS Office 2003 I used to either remove all langpacks so this extra field gets removed or otherwise I had to bear the burden of specifying my desired font twice. Lots of fonts (Sanskrit 2003 is an excellent example for Devanagari, and of course the FreeFont family for all Indic scripts and more) provide for both English/European and Indic, especially because lots of people who write about Indian literature etc would like to seamlessly switch between the two scripts. In this situation, what is the big usefulness in providing the "Western text" font vs "CTL font" bifurcation? I don't see the point in marking the same span of text with two fonts while only one is actually going to be used in the end at one time. If a font doesn't provide for two scripts, it is not a big deal to switch between fonts for the respective text spans. For instance, if one were to switch between Latin and Cyrillic where (assuming) the default font one uses for Latin doesn't provide for Cyrillic text, one has to switch anyway. How is the "Western" vs "CTL" situation any different?

If at all one wishes to provide per-script font selection capability, one should go the full way through and do something like Firefox, which provides for font selection per script -- not some developer-imposed segregation between "Western" and "CTL" scripts.

Next, why should I be required to install a langpack to get the list of full languages? I have never used the LibO interface in any language other than English but I heavily use LibO to input Indian language text -- why is the one connected to the other?

Further, note that ISO 15919 (http://en.wikipedia.org/wiki/ISO_15919) is an international standard which permits the transliteration of Indian script text into Latin script extended with diacritics. This is widely used by scholars who aren't necessarily Indians and who can't even read the native Indian scripts to store, quote and research texts written in Indic languages. In this case the script is a "Western" script but the language is an Indian language. So why the unnecessary connection between script and language? Let the software not try to be more intelligent than the user! And let us not have blind imitation of Microsoft Office idiosyncrasies in LibO.

I like LibO very much and wish to see it improve. Hence I have made the above frank comments re the current situation. Please do not take them amiss. Thank you for all your excellent work on LibO!
Comment 13 Urmas 2013-11-01 10:40:33 UTC
Those languages uses their own script and their own fonts which are not applicable to normal text. Therefore there are 2 fonts.
Comment 14 Shriramana Sharma 2013-11-01 11:07:00 UTC
(In reply to comment #13)
> Those languages uses their own script and their own fonts which are not
> applicable to normal text. Therefore there are 2 fonts.

Excuse me -- did you read my detailed report? And by your wording "fonts which are not applicable to *normal* text" do you mean to imply that the text I am typing in LibO in an Indian language in an Indian script is not "normal" text?!!!! From where do you get that? This is a viewpoint so skewed and biased towards users who have never had cause to use other than the Latin script that I am quite *un*pleasantly surprised to see that it would be practised in a global project such as LO.

My points:

1) a user need not install a language pack to type text in that language/script

-> hence the full language list should always be provided in the font dialog irrespective of whether an Indic language pack is installed or not

2) the Western vs Asian vs CTL segregation of fonts is skewed and outdated

-> whether an Indic language pack is installed or not, there should be only one font family/style/size/language combination selectable for a given span of text
Comment 15 Urmas 2013-11-01 11:57:58 UTC
> a user need not install a language pack to type text in that language/script

The user needs to check a single box in options.

> the Western vs Asian vs CTL segregation of fonts is skewed and outdated

This is an objective truth based on those scripts design.
Comment 16 ⁨خالد حسني⁩ 2013-11-01 11:59:32 UTC
(In reply to comment #12)
> [By error, the first few lines of this post was included as a separate
> comment. Sorry for that.]
> 
> Looks like I myself had formerly reported this against OOo 2.4.0
> (https://issues.apache.org/ooo/show_bug.cgi?id=87484) and they just closed
> it as "IRREPRODUCIBLE" -- I suppose that means something like "WORKSFORME".
> Now I don't care to follow-up the bug on the OOo tracker -- it's LibO for me
> all the way. 
> 
> So I'll just clarify the bug here.
> 
> If you have some text, Format Menu or right click > Character > Font >
> Language should give you the language tag to apply to the text. Currently,
> in this combobox, Indian languages are not mentioned.
> 
> Note that this also applies to Styles and Formatting > Default Style (or any
> style) > Right-click > Modify > Font > Language.
> 
> While Tools > Language > For Selection/Paragraph/All Text seems to list some
> known languages corresponding to the script of the selected text, if the
> required language is not visible in this and we click More, from "For
> Selection/Paragraph" we are taken to the same Font dialog which again does
> not provide the Indian languages. 
> 
> OTOH from "For All Text" we are taken to the Tools > Options > Language
> Settings > Languages where we are apparently allowed to select the "Default
> language for documents".
> 
> Under this there are three comboboxes -- Western, "Asian" and "CTL". I am
> not sure what is the rationale between the separation of "Asian" vs "CTL" --
> both Asian and non-Asian scripts require CTL IIUC. And the Asian and CTL
> comboboxes are disabled in the absence of any language packs.

Asian here should have been CJK. It is misleading and probably should be renamed. Please open a separate bug for this.

> As Steve says if I install any one language pack (to be precise, at least
> the libobasis4._-__ package) for an Indian language (I tried Tamil and he
> tried Hindi so I guess the rest would be same too) the CTL combobox in the
> Tools > Options dialogue gets enabled and also the font dialog is upgraded
> to show a separate "Western text font" from a "CTL font", in which the
> combobox providing the language of the CTL font includes names of Indian
> languages. Still the combobox for the "Western text font" does not provide
> the names of Indian languages. 
> 
> The whole Western text font vs CTL font is a quite silly segregation -- I am
> not sure what it is in aid of. It seems to be copied from Microsoft Office.
> Even when I was using MS Office 2003 I used to either remove all langpacks
> so this extra field gets removed or otherwise I had to bear the burden of
> specifying my desired font twice. Lots of fonts (Sanskrit 2003 is an
> excellent example for Devanagari, and of course the FreeFont family for all
> Indic scripts and more) provide for both English/European and Indic,
> especially because lots of people who write about Indian literature etc
> would like to seamlessly switch between the two scripts. In this situation,
> what is the big usefulness in providing the "Western text" font vs "CTL
> font" bifurcation? I don't see the point in marking the same span of text
> with two fonts while only one is actually going to be used in the end at one
> time. If a font doesn't provide for two scripts, it is not a big deal to
> switch between fonts for the respective text spans. For instance, if one
> were to switch between Latin and Cyrillic where (assuming) the default font
> one uses for Latin doesn't provide for Cyrillic text, one has to switch
> anyway. How is the "Western" vs "CTL" situation any different?

While I basically agree, this “segregation” is embedded in the office document formats as well as the UI of other popular office suites (as you noted). You can select the same font for all three categories and still be able to use different language settings for each which would allow you to utilize locale-specific features in the font, which I think is a good thing (what I actually don’t like about this, is just three categories, why I can’t select specific font settings for every script). Manually changing the font for different text spans is the antipattern of properly styling the text, we should help avoid it not force it even more.

> If at all one wishes to provide per-script font selection capability, one
> should go the full way through and do something like Firefox, which provides
> for font selection per script -- not some developer-imposed segregation
> between "Western" and "CTL" scripts.

I fully agree, but I’m not sure how can this be reflected in the file formats we use (not that I know much about them), but again please open a separate bug for this.

> Next, why should I be required to install a langpack to get the list of full
> languages? I have never used the LibO interface in any language other than
> English but I heavily use LibO to input Indian language text -- why is the
> one connected to the other?
> 
> Further, note that ISO 15919 (http://en.wikipedia.org/wiki/ISO_15919) is an
> international standard which permits the transliteration of Indian script
> text into Latin script extended with diacritics. This is widely used by
> scholars who aren't necessarily Indians and who can't even read the native
> Indian scripts to store, quote and research texts written in Indic
> languages. In this case the script is a "Western" script but the language is
> an Indian language. So why the unnecessary connection between script and
> language? Let the software not try to be more intelligent than the user! And
> let us not have blind imitation of Microsoft Office idiosyncrasies in LibO.
> 
> I like LibO very much and wish to see it improve. Hence I have made the
> above frank comments re the current situation. Please do not take them
> amiss. Thank you for all your excellent work on LibO!

Please try to break this down to specific bug reports instead of lumping everything in a big essay that very few will read and be able to extract useful info from.
Comment 17 Urmas 2013-11-01 12:21:22 UTC
Created attachment 88473 [details]
Indian languages in a context menu
Comment 18 ⁨خالد حسني⁩ 2013-11-22 12:00:39 UTC
See also bug 42123.