[Upstream] Bold, Italics, and Bold Italics not in English on Fonts menu

[Scott Kitterman]

Binary package hint: openoffice.org

Using the current ooo packages for Feisty, open Writer, type a few characters, and then go to the Format --> Character menu. In the Font tab under Typeface, the options listed are:

Normal
cursiva
Negreta
Negreta cursiva

The system in question is en_US. I've had Feisty on this computer for some time and do not recall seeing this before (not certain I used the Font menu though).

[Alex Kavanagh (ajkavanagh)]

Yep, I've got this too, but mine is en_GB. Very strange, and I can't seem to fix it.

[David Tomaschik (matir)]

Same behavior here on Gutsy.

[Vlad Lungeanu (drvladl)]

I confirm it in OO.o 2.3.0 under Kubuntu Gutsy.

I have downloaded the original OO.o RPMs, converted them to DEBs with alien, and installed them (after uninstalling the Ubuntu version). The problem is gone, so the Ubuntu packages are definitely the cause.

[Chris Cheney (ccheney)]

Confirmed in upstream's openoffice.org 2.4.0~rc2.

[Bertilo (bertilow)]

This is probably not a bug in Openoffice.org. I see the same thing in several other programs, e.g. Gvim and Meld. Some programs somehow get the correct names, while others get "negreta cursiva". It's also different for different fonts. This bug has been around for at least two full years, maybe longer.

[Chris Cheney (ccheney)]

Added fontconfig to get comments from someone more knowledgeable with fontconfig to see if this is something wrong with it.

Chris

[Chris Cheney (ccheney)]

If this isn't a bug just in OpenOffice then it probably is also a bug in upstream fontconfig since it appears to affect OpenSuse users also.

Chris

[Hew (hew)]

Also present with en_AU. Hardy with OpenOffice.org 2.4.0-3ubuntu2.

[Steve Langasek (vorlon)]

I've had a look, the only font I'm seeing this for is FreeMono. Is that consistent with what others are seeing?

[Chris Cheney (ccheney)]

Steve,

Of the fonts I happen to have on my system, it happens for me on:

Agency FB
Arial
Arial Black
Arial Narrow
Bell MT
Berlin Sans FB
Berlin Sans FB Demi
Book Antiqua
Bookman Old Style
Brush Script MT
Californian FB
Calisto MT
Century Gothic
Century Schoolbook
Comic Sans MS
Courier New
Elephant
Franklin Gothic Book
Franklin Gothic Demi
Franklin Gothic Heavy
Franklin Gothic Medium
FreeMono
Garamond
Georgia
Gill Sans MT
Goudy Old Style
High Tower Text
Lucida Fax
Lucida Handwriting
Lucida Sans
Lucida Sans Typewriter
Magneto
Palatino Linotype
Perpetua
Perpetua Titling MT
Rockwell
Tahoma
Times New Roman
Trebuchet MS
Tw Cen MT
Tw Cen MT Condensed
Vemana2000
Verdana
Vivaldi

I am sure I am missing some due to not all of them having the second entry in spanish. eg

Vemana2000,Pothana2000:style=Regular,Pothana2000

The style shows up as "Pothana2000" not "Regular".

Yes, the vast majority of these fonts are not free fonts, but it is still an annoying bug, and can be seen via several of the fonts in msttcorefonts.

This smells like an off by one error somewhere since it seems to be shifting to the stylename one to the right as shown by fc-list, but it might be something else.

Chris

[Steve Langasek (vorlon)]

Ok, this is not inconsistent with what I'm seeing, since of all the fonts you list the only one I have installed is FreeMono. :)

And off-by-one error seems possible. I agree this is a fontconfig problem:

$ fc-match FreeMono
FreeMono.ttf: "FreeMono" "Normal"
$

Where "Normal" is Spanish, and should have been "Medium" in English.

[Steve Langasek (vorlon)]

$ fc-match -v FreeMono
Pattern has 32 elts (size 48)
 family: "FreeMono"(s)
 familylang: "en"(s)
 style: "Normal"(s)
 stylelang: "ca"(s)
 fullname: "Free Monospaced"(s)
 fullnamelang: "en"(s)
[...]
$

Well, ok, fontconfig *knows* that the language it's using for the style isn't English, and displays it anyway (?)

[Steve Langasek (vorlon)]

FWIW, Catalan is the first language, alphabetically by country code, for which there's a style name. So it seems likely that this is the cause, rather than an off-by-one error.

[Chris Cheney (ccheney)]

Yes, that seems consistent with what I am seeing as well, a quick glance at one of the other fonts shows this:

Pattern has 31 elts (size 32)
        family: "Lucida Fax"(s)
        familylang: "en"(s)
        style: "normal"(s)
        stylelang: "da"(s)
        fullname: "Lucida Fax"(s)
        fullnamelang: "da"(s)
[...]

[Chris Cheney (ccheney)]

As you mentioned on IRC it may be a good idea to bounce this to upstream, since it appears to actually be a fontconfig bug, not an OpenOffice.org bug.

Thanks,

Chris Cheney

[Mfabian (mfabian)]

OpenOffice shows some the styles of some fonts in non-English
languages.

[Mfabian (mfabian)]

Created an attachment (id=207981)
oo-font-style-name-non-english.png

In the oowriter menu go to “Format” → “Character”,
then select the font “Arial” and look at the available Typefaces.

[Mfabian (mfabian)]

Created an attachment (id=207985)
fontforge-arial-italic-font-information.png

Font information of the Arial-ItalicMT font
according to fontforge.

[Mfabian (mfabian)]

Created an attachment (id=207988)
arial-font-styles-in-gedit.png

[Mfabian (mfabian)]

Created an attachment (id=208312)
fc-family-list-faces.c

Test program. Compile with:

gcc -g -O0 -Wall -o fc-family-list-faces fc-family-list-faces.c -lfontconfig

[Mfabian (mfabian)]

Output of the test program:

mfabian@magellan:~/c$ ./fc-family-list-faces arial
i=0 file=/usr/share/fonts/truetype/arialbi.ttf family=Arial familylang=en weight=200 slant=100 style=Negreta cursiva stylelang=ca
i=1 file=/local/fonts/vista/ariali.ttf family=Arial familylang=en weight=80 slant=100 style=Cursiva stylelang=ca
i=2 file=/usr/share/fonts/truetype/ariali.ttf family=Arial familylang=en weight=80 slant=100 style=Cursiva stylelang=ca
i=3 file=/usr/share/fonts/vista/ariali.ttf family=Arial familylang=en weight=80 slant=100 style=Cursiva stylelang=ca
i=4 file=/usr/share/fonts/vista/arialbi.ttf family=Arial familylang=en weight=200 slant=100 style=Negreta cursiva stylelang=ca
i=5 file=/local/fonts/vista/arialbi.ttf family=Arial familylang=en weight=200 slant=100 style=Negreta cursiva stylelang=ca
mfabian@magellan:~/c$

[Mfabian (mfabian)]

As one can see in the output of the fontconfig test program,
we get the style names translated in Catalan, *although* the
test program explicitly requested them in English:

 pattern = FcPatternBuild (NULL,
      FC_FAMILY,
      FcTypeString,
      (unsigned char *) argv[1],
/* FC_STYLE, */
/* FcTypeString, */
/* "Italic", */
      FC_SLANT,
      FcTypeInteger,
      100,
      FC_STYLELANG,
      FcTypeString,
      "en", ← style requested in English
      NULL);

Requesting the style "Italic" (commented out above) or
the slant value of 100 works, it really limits the the
fontset created from this pattern with

    fontset = FcFontList (NULL, pattern, objectset);

to only the slanted versions.

But requesting a language for the style does *not* work. Requesting an
non-existing language for the style, e.g. "xx" or "de" (The styles of
Arial have no German translation) results in an empty result. But
requesting "en" or any other language where translations of the style
exist doesn’t limit the result to the requested language.

I guess it should, therefore this looks like a fontconfig bug to me.

[Mfabian (mfabian)]

The fc-list shows similar behaviour to my test program:

mfabian@magellan:~$ fc-list Arial:style=Italic:stylelang=en
Arial:style=Cursiva,kurzíva,kursiv,Πλάγια,Italic,Kursivoitu,Italique,Dőlt,Corsivo,Cursief,Kursywa,Itálico,Курсив,İtalik,Poševno,nghiêng,Etzana
mfabian@magellan:~$ fc-list Arial:style=Italic:stylelang=ca
Arial:style=Cursiva,kurzíva,kursiv,Πλάγια,Italic,Kursivoitu,Italique,Dőlt,Corsivo,Cursief,Kursywa,Itálico,Курсив,İtalik,Poševno,nghiêng,Etzana
mfabian@magellan:~$ fc-list Arial:style=Italic:stylelang=de
mfabian@magellan:~$

i.e. requesting a certain stylelang in the pattern doesn’t
limit the result to the requested stylelang, only if the
stylelang doesn’t exist at all the result becomes empty.

[Mfabian (mfabian)]

The reason why this problem doesn’t show up in Gnome applications
is apparently the following code in pangofc-fontmap.c niear line 1918
in function pango_fc_family_list_faces:

       if (weight <= FC_WEIGHT_MEDIUM)
  {
    if (slant == FC_SLANT_ROMAN)
      {
        has_face[REGULAR] = TRUE;
        style = "Regular";
      }
    else
      {
        has_face[ITALIC] = TRUE;
        style = "Italic";
      }
  }
       else
  {
    if (slant == FC_SLANT_ROMAN)
      {
        has_face[BOLD] = TRUE;
        style = "Bold";
      }
    else
      {
        has_face[BOLD_ITALIC] = TRUE;
        style = "Bold Italic";
      }
  }

i.e. the 4 basic faces get special treatment, probably because Pango
wants to translate them on its own using gettext.

A font which had a more exotic style, say "Condensed" translated
in many languages would probably show the problem reportedd
here in Gnome as well.

(Qt has problems with fonts with many styles anyway, see bug #369466
and bug 330658 for example).

[Chris Cheney (ccheney)]

The openSUSE guys wrote test programs showing the problem and also tracked down why it works in Gnome so yes this is definitely an upstream fontconfig bug.

Chris

[bwallum (rbw2)]

Here's a screenshot of the problem. It is still with me using

Linux Kernel: 2.6.24-18-generic
Gnome: 2.22.2
OO: 2.4.0

[Chris Cheney (ccheney)]

bwallum,

Yes, this is a known problem with fontconfig library. It is not actually a problem with OpenOffice, other Gnome applications don't show this problem since they don't use the fontconfig names directly instead they translate the names themselves.

Chris

[Bertilo (bertilow)]

A known problem? If it's known, then why hasn't it been fixed?

As far as I can tell, it's been known for at least four (4!!) years! Who's sitting on the code? Who's bug is it?

[Hew (hew)]

If it had been fixed, then it wouldn't be a problem, and you wouldn't know about it! :-)

As you can see from this report, it hasn't been around for four years, but it is marked as high priority, so we are well aware of the issue. However, please feel free to make a positive contribution to the bug report; I'm sure the developers would welcome a patch that resolves the issue.

[Chris Cheney (ccheney)]

This bug has only been open in launchpad for about a year. I told the Novell guys about it a couple months ago at the GoOOCon meeting and they were able to track down that it was a flaw in fontconfig library not in OOo itself. It doesn't show up often since most fonts don't have translated style names and it doesn't show up at all under Gnome since they do translations of style names in their own library not using the information from the fonts.

So this bug probably has been around as long as fontconfig has been but at least as far as I can see it hasn't been reported for much more than a year.

[Scott Kitterman (kitterman)]

Note: I'm the original reporter of this bug.

I still have a Dapper Kubuntu box and it does not exhibit this problem. I don't recall seeing it in Edgy when I had that. Whatever the root cause, it was new in the Feisty timeframe and has not been around forever.

[Bertilo (bertilow)]

"Importance: High" + "Milestone: later" seems to be a strange combination. I would help if I could, but my coding skills are really not up to this. I couldn't find anything about this in the actual fontconfig bug database at "bugs.freedesktop.org". Hasn't anyone told them?

[Chris Cheney (ccheney)]

Well it is too late to be fixed for Intrepid (8.10) since that is released in under 2 days. There are no milestones for Jaunty yet so I had to set it to later.

[lengo (pcunger)]

Chris Cheney wrote: " . . . and it doesn't show up at all under Gnome since they do translations of style names in their own library not using the information from the fonts."

Sorry Chris, but I just installed OOo 3.0 (downloaded from Sun) in Ubuntu 8.04 and I have the same problem. It certainly does seem to show up under Gnome.

[Chris Cheney (ccheney)]

lengo,

I said in Gnome, not in an random app running under Gnome. OOo 3.0 is not a Gnome app, and so yes I have no doubt you still see this problem under OOo 3.0, but the bug is in fontconfig not in OOo. Gnome and true gnome apps have their font names translated but not by fontconfig which is why they work.

[bwallum (rbw2)]

Just to say thanks, Chris, for persevering. It took me a while to understand that OOo is ok and that the fontconfig module(not an OOo module) is where the bug lies.

It really is an eyesore though and the casual user will automatically assume that OOo is at fault. The sooner this bug is well and truly squashed the better. I look forward to it being cleared in 9.04.

I have noticed some changes over the past year. The problem seems to be now confined to certain fonts, e.g. Times New Roman and Verdana. Other fonts are ok, e.g. UnDotum, are ok.

[David Rankin (drankinatty)]

Devs,

    In the latest release of OpenOffice from http://download.opensuse.org/repositories/GNOME%3a/Community/openSUSE_11.0 , the font dialog shows the typeface options in Spanish or Portugese?? It should be English for my setup and has always been english until this latest update to:

OpenOffice_org-3.0.0.3.6-1.1

    See the following screenshot showing the problem:

http://www.3111skyline.com/download/openSUSE_bugs/110/ooo/spanish-in-dialog.jpg

    Let me know if I can send anything else that would help. Thanks.

[Pmladek (pmladek)]

I have reproduced it. The steps are the following:

1. Get the MS fonts, for example by the steps at
http://www.benkevan.com/blog/installing-microsoft-fonts-on-opensuse-110/
2. Start oowriter
3. Open the "Styles and Formatting" dialog, it is the 1st icon on the 2nd toolbar,
   next to the combo box to select the styles
4. Press right mouse button on the "Heading" style and select "Modify"
5. Select the tab "Font"
6. Select the font "Times New Roman"

Result: you get the dialog from the screenshot
http://www.3111skyline.com/download/openSUSE_bugs/110/ooo/spanish-in-dialog.jpg

BTW: The used OOo build is from
http://download.opensuse.org/repositories/OpenOffice.org:/STABLE/openSUSE_11.0/

Hmm, the strings are read from fontconfig. Just try the command:

   fc-list

It seems that the style is localized only for few fonts.

Well, the description is still understandable => P3.

Mike, do you have an idea what function to search for?

[katanablade (luisisidor)]

First of all, my apologies if this is not the right place to place this question. Kind of new in linux - ubuntu world. I have tried looking for answers with no luck.
I am running Ubuntu 8.10 and openOffice 3.0. The problem is that fonts in OOo menu are not shown. They basically disappeared.
I have tried changing the applications font with no luck. Attaching a screenshot so you guys know what I mean.
Any help will be greatly appreciatted.

[bwallum (rbw2)]

Hi katanablade. the first thing to say is some of the icons look like a mac, have you got the right version? The next thing is try the Ubuntu forums, they will respond much quicker and I have always found them really helpful. Try the Absolute Beginners forum, they are very active. http://ubuntuforums.org/forumdisplay.php?f=326

Good luck

[katanablade (luisisidor)]

Thanks for the tip. I'll try the recommended forum.
With regards to the icons, just playing and customizing the GUI (basically so my wife won't complain she can't find things- she's used to macs). The version is right.

[David Rankin (drankinatty)]

This bug is still marked as "NEED". Is that to me? I have read the comments and I don't see anything else I can provide. Let me know if I'm missing something.

[Kyoshida (kyoshida)]

No, it's NEEDINFO'ed to Mike Fabian. If you log in to bugzilla, you'll see at the top of this page in the Related People section, the 'Info Provider' is Mike Fabian. That's who has been requested to provide info.

[tesluk (tesluk)]

Similar happened to me in Windows XP, with OpenOffice writer font menu showing:
  Normal
  cursiva
  Negreta
  Negreta cursiva
instead of the usual Italic, Bold, etc.
The fix was in Regional and Language Options / Advanced / Language for non-Unicode Programs
It had been changed to Spanish (possibly when I was in Mexico last month). Changed it back to English, reboot, and voila! all normal again.

[Martin Pitt (pitti)]

Dropping milestone, nobody is assigned to that bug. If you think it should be fixed in Jaunty, please get it assigned to someone and target it to jaunty. Adding milestones to a non-release task without an assignee doesn't make much sense.

[Ralf Jung (ralfjung-e)]

The problem persists in Jaunty

[Kyoshida (kyoshida)]

*** Bug 479292 has been marked as a duplicate of this bug. ***

[Hvogel (hvogel)]

.

[Mark Russell (marrusl)]

Hi Behdad. Anything new on this?

[Freedesktop (freedesktop)]

Not yet, got stuck with harfbuzz hacking. I'll give fontconfig another push soon.

[2-pmladek (2-pmladek)]

*** Bug 457427 has been marked as a duplicate of this bug. ***

[Pgajdos-f (pgajdos-f)]

(In reply to comment #10)
> *** Bug 457427 has been marked as a duplicate of this bug. ***

Ok, so reopening this bug and reassign to me.

[Pgajdos-f (pgajdos-f)]

Upstream bug:
http://bugs.freedesktop.org/show_bug.cgi?id=27765

[Pgajdos-f (pgajdos-f)]

Following patch (first try, naive, not upstreamable, ...) should workaround the problem, at least for fc-match. Could you please test?

M17N/fontconfig

In case that this is not enough: could you please tell me how is fontconfig used by *office?

Thanks

Index: fontconfig-2.8.0/src/fcmatch.c
===================================================================
--- fontconfig-2.8.0.orig/src/fcmatch.c
+++ fontconfig-2.8.0/src/fcmatch.c
@@ -413,6 +413,40 @@ FcFontRenderPrepare (FcConfig *confi
  }
  else
      v = FcValueCanonicalize(&FcPatternEltValues (fe)->value);
+
+ /* This is workaround only!! */
+ if (fe->object == FC_STYLE_OBJECT)
+ {
+ FcPatternElt *le, *sle;
+ FcValue lang, stlang;
+ FcValueList *stlangs, *sts;
+ int l;
+
+ if ((le = FcPatternObjectFindElt(pat, FC_LANG_OBJECT)))
+ lang = FcValueCanonicalize(&FcPatternEltValues(le)->value);
+ else
+ { /* I think it is not needed. */
+ lang.type = FcTypeString;
+ lang.u.s = (const FcChar8 *)"en";
+ }
+ sle = FcPatternObjectFindElt(font, FC_STYLELANG_OBJECT);
+ stlangs = FcPatternEltValues(sle);
+ sts = FcPatternEltValues(fe);
+ l = 0;
+
+ do
+ {
+ stlang = FcValueCanonicalize(&stlangs->value);
+ if (FcLangCompare(stlang.u.s, lang.u.s) < FcLangDifferentLang)
+ break;
+ sts = FcValueListNext(sts);
+ l++;
+ } while ((stlangs = FcValueListNext(stlangs)));
+
+ lang = FcValueCanonicalize(&sts->value);
+ v.u.s = lang.u.s;
+ }
+
  FcPatternObjectAdd (new, fe->object, v, FcFalse);
     }
     for (i = 0; i < pat->num; i++)

[Pgajdos-f (pgajdos-f)]

This patch is causing some crashes, I am working on it, but in home:pgajdos/fontconfig from now.

Nothing to test now.

[Pgajdos-f (pgajdos-f)]

CCing potential testers.

[Pgajdos-f (pgajdos-f)]

You can download modified fontconfig from

http://download.opensuse.org/repositories/home:/pgajdos/openSUSE_Factory/x86_64/

where fc-match now works for me as intended and I didn't see any application crashing during (short) session in VirtualBox.

This has not resolved original problem though. Pida, could you please point me to the piece of code, where fontconfig library is called?

[2-pmladek (2-pmladek)]

The related code should be in the libreoffice-libs-gui source package in vcl/unx/source/fontmanager

You might also try to search the LibreOffice sources via
http://opengrok.go-oo.org/. Then you might look at http://cgit.freedesktop.org/libreoffice/build/plain/bin/modules2.txt to find related source package. The file modules2.txt lists the top directories per source tarball, e.g. vcl is in libs-gui.

[Pgajdos-f (pgajdos-f)]

Hi again,

the workaround for fc-match:

--- fontconfig-2.8.0.orig/src/fcmatch.c
+++ fontconfig-2.8.0/src/fcmatch.c
@@ -413,6 +413,56 @@ FcFontRenderPrepare (FcConfig *confi
        }
        else
            v = FcValueCanonicalize(&FcPatternEltValues (fe)->value);
+
+ /* This is workaround only!! */
+ if (fe->object == FC_STYLE_OBJECT)
+ {
+ FcPatternElt *le, *sle;
+ FcValue lang, stlang, style;
+ FcValueList *stlangs, *sts, *en_style;
+ int l;
+
+ /* Try to learn lang from pat. */
+ if ((le = FcPatternObjectFindElt(pat, FC_LANG_OBJECT)))
+ lang = FcValueCanonicalize(&FcPatternEltValues(le)->value);
+ else /* FC_LANG_OBJECT not found in pat. I think it can't happen. */
+ {
+ lang.type = FcTypeString;
+ lang.u.s = (const FcChar8 *)"en";
+ }
+
+ sle = FcPatternObjectFindElt(font, FC_STYLELANG_OBJECT); /* element of font containing */
+ sts = FcPatternEltValues(fe); /* styles translations associated to font */
+ /* langs of styles translations */
+
+ en_style = 0;
+ if (sle) /* style elt can be present, stylelang no (e. g. fc-match Times) */
+ { /* if so, sts list contain only one value, so we can jump to style = .. */
+ stlangs = FcPatternEltValues(sle);
+ l = 0;
+
+ do /* Find style corresponding to lang(.u.s). */
+ {
+ stlang = FcValueCanonicalize(&stlangs->value);
+ if (FcLangCompare(stlang.u.s, lang.u.s) < FcLangDifferentLang)
+ break;
+ if (FcLangCompare(stlang.u.s, "en") < FcLangDifferentLang)
+ en_style = sts; /* Will be used when translation not found for lang. */
+ sts = FcValueListNext(sts);
+ l++;
+ } while ((stlangs = FcValueListNext(stlangs)));
+ }
+
+ if (sts) /* Style translation was found for lang.u.s. */
+ style = FcValueCanonicalize(&sts->value);
+ else if (en_style) /* Not found, try English. */
+ style = FcValueCanonicalize(&en_style->value);
+ else /* Nor English found, take first one. */
+ style = FcValueCanonicalize(&FcPatternEltValues(fe)->value);
+
+ v.u.s = style.u.s;
+ }
+
        FcPatternObjectAdd (new, fe->object, v, FcFalse);
     }
     for (i = 0; i < pat->num; i++)

[Pgajdos-f (pgajdos-f)]

I am thinking about better solution -- get working patterns with FC_STYLELANG specified.

[Pgajdos-f (pgajdos-f)]

However, this is not related to this bug at all. I will try explain, what I have found and what would help in my opinion.

First, for each font we have defined four lists:
FAMILY .. family name in different languages
FAMILYLANG .. languages corresponding to entries in FAMILY
STYLE .. style name in different languages
STYLELANG .. languages corresponding to entries in STYLE

As far as I can see, STYLE and STYLELANG are handled in fontconfig similar way as FAMILY and FAMILYLANG respectively. But, these two pairs are handled differently by Office:

FcResult eFamilyRes = rWrapper.FamilyFromPattern( pFSet->fonts[i], &family );
FcResult eStyleRes = rWrapper.FcPatternGetString( pFSet->fonts[i], FC_STYLE, 0, &style );

This is in my opinion wrong, because I believe FamilyFromPattern() chooses the name in right language, but FcPatternGetString(..,FC_STYLE,0,..) takes the _first_ element from the list.

If all from the above is true, then all what remains is to implement StyleFromPattern() function (very similar to FamilyFromPattern()) and change one line in countFontconfigFonts().

Could someone with better experience with Office patching and building to try this out?

[Pgajdos-f (pgajdos-f)]

Never mind, I believe I have a solution.

[Pgajdos-f (pgajdos-f)]

Created an attachment (id=411219)
Patch against libs-gui/vcl/unx/source/fontmanager/fontconfig.cxx.

[Pgajdos-f (pgajdos-f)]

Kendy, could you please have a look at this patch and could you please reassign this to right person?

[Mmeeks-i (mmeeks-i)]

I'll forward to the dev mailing list ... thanks Petr ! :-) Caolan would want a look I think.

[Pgajdos-f (pgajdos-f)]

(In reply to comment #24)
> I'll forward to the dev mailing list ... thanks Petr ! :-) Caolan would want a
> look I think.

Definitely. Take this as very first try. I didn't test it much while I don't have time for that now, maybe later this week.

[Freedesktop (freedesktop)]

From a mail I sent today:

This is how I think this should be fixed:

Add a new element FC_NAME_LANG="namelang".

In FcFreeTypeQuery, perhaps set FC_NAME_LANG to the intersection of
FC_FAMILY_LANG and FC_STYLE_LANG. Or maybe don't. Not going to use this
directly.

In FcConfigDefault, if FC_NAME_LANG is empty, fill it in from default locale
language. Then if FC_FAMILY_LANG is empty, copy it from FC_NAME_LANG. Same
for FC_STYLE_LANG and FC_FULLNAME_LANG. This way, FC_NAME_LANG is how the
user will request names in a particular language.

In FcFontRenderPrepare, when deciding what FC_FAMILY and FC_STYLE to choose,
choose the first one that has a _LANG equivalent present in the query
pattern's respective _LANG element.

That should do it.

[Removed by request (removed2831044)]

Upstreamed as fdo#40946.

[Broco (broco2002)]

Just an info:
This affects other languages, too (at least German), as seen in the link posted here:
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/105900/comments/80
I can confirm this bug for Ubuntu (8.10 - 11.04) and OpenOffice.org (3.0 - 3.3) as well as in Libreoffice (3.3.3 package 1:3.3.3-1ubuntu2).
I cannot confirm this bug for any Version of OpenOffice.org/LibreOffice in Windows (XP and 7).

In gedit (German languagepack) only the "italic" entry ("Kursiv" in German) is wrong --> "cursiva", "bold" is correct ("Fett").
So i guess this bug lies mainly in the ttf-mscorefonts-installer.

[Removed by request (removed2831044)]

Upstream fix in 3.4, which is released as Ubuntu package already => Fix Released

[Akiro (akiro)]

the proposed patch:
http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=bz27765

[Akiro (akiro)]

updated a bit to add *lang object to the pattern like the original behavior.

[Akiro (akiro)]

I guess we should change the code for FcFontList() too.

[Akiro (akiro)]

updated fclist.c too:
http://cgit.freedesktop.org/~tagoh/fontconfig/commit/?h=bz27765

[Akiro (akiro)]

The patch will change the behavior compared to current one. particularly with:
http://cgit.freedesktop.org/~tagoh/fontconfig/tree/src/fcdefault.c?h=bz27765#n196
http://cgit.freedesktop.org/~tagoh/fontconfig/tree/src/fclist.c?h=bz27765#n382

the result on LANG=ja_JP say will looks like:
(On fontconfig-2.9.0)
/usr/share/fonts/wqy-zenhei/wqy-zenhei.ttc: 文泉驛點陣正黑,WenQuanYi Zen Hei Sharp,文泉驿点阵正黑:style=Regular

(with patch)
/usr/share/fonts/wqy-zenhei/wqy-zenhei.ttc: WenQuanYi Zen Hei Sharp,文泉驛點陣正黑,文泉驿点阵正黑:style=Regular

Anyway, that should be trivial.

[Akiro (akiro)]

committed with 7587d1c9.

[Hmuelle (hmuelle)]

openSUSE 11.0 is end of life, issue should be tracked upstream regarding c#24.
Closing upstream.

If bug still exists in newer and still supported version of openSUSE please report a new bug against this version.

[Pgajdos-f (pgajdos-f)]

As far as I remember, the patch from comment 22 is upstreamed yet.