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

Bug #105900 reported by Scott Kitterman on 2007-04-12
74
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Fontconfig
Fix Released
Medium
LibreOffice
Fix Released
Medium
OpenOffice
Won't Fix
Medium
fontconfig (Ubuntu)
High
Unassigned
libreoffice (Ubuntu)
Undecided
Unassigned
openoffice.org (openSUSE)
New
Undecided
Unassigned

Bug Description

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).

description: updated
Alex Kavanagh (ajkavanagh) wrote :

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

Changed in openoffice.org:
importance: Undecided → Low
status: New → Triaged
David Tomaschik (matir) wrote :

Same behavior here on Gutsy.

Vlad Lungeanu (drvladl) wrote :

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) wrote :

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

Changed in openoffice.org:
status: Triaged → Confirmed
Chris Cheney (ccheney) on 2008-03-18
Changed in openoffice:
importance: Undecided → Unknown
status: New → Unknown
Changed in openoffice:
status: Unknown → New

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.

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

Chris

Chris Cheney (ccheney) wrote :

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

Chris Cheney (ccheney) on 2008-04-12
Changed in fontconfig:
importance: Undecided → High
Hew McLachlan (hew) wrote :

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

Steve Langasek (vorlon) wrote :

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

Hew McLachlan (hew) wrote :
Chris Cheney (ccheney) wrote :

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) wrote :

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.

Changed in fontconfig:
status: New → Confirmed
Steve Langasek (vorlon) wrote :

$ 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) wrote :

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) wrote :

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) wrote :

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

78 comments hidden view all 122 comments

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

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.

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

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

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

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

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$

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.

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.

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).

85 comments hidden view all 122 comments
Chris Cheney (ccheney) wrote :

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

Changed in opensuse:
status: Unknown → In Progress
Chris Cheney (ccheney) on 2008-06-13
Changed in fontconfig:
milestone: none → ubuntu-8.10-beta
Changed in openoffice.org:
status: Confirmed → Triaged
Changed in openoffice:
status: New → Invalid
Changed in openoffice.org:
status: Triaged → Invalid
bwallum (rbw2) wrote :

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) wrote :

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) wrote :

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 McLachlan (hew) wrote :

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) wrote :

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) wrote :

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.

Ralph Janke (txwikinger) on 2008-06-17
Changed in fontconfig:
status: Confirmed → Triaged
Chris Cheney (ccheney) on 2008-10-28
Changed in fontconfig:
milestone: ubuntu-8.10-beta → later
Bertilo (bertilow) wrote :

"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) wrote :

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) wrote :

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) wrote :

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.

Changed in fontconfig:
milestone: later → ubuntu-9.04-beta
bwallum (rbw2) wrote :

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.

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.

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?

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) wrote :

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) wrote :

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.

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.

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.

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.

1 comments hidden view all 122 comments
Martin Pitt (pitti) wrote :

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.

Changed in fontconfig:
milestone: ubuntu-9.04-beta → none
Ralf Jung (ralfjung-e) wrote :

The problem persists in Jaunty

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

63 comments hidden view all 122 comments
Chris Cheney (ccheney) on 2010-04-23
Changed in fontconfig:
importance: Undecided → Unknown
status: New → Unknown
Changed in openoffice.org (openSUSE):
status: In Progress → Unknown
Changed in openoffice.org (openSUSE):
status: Unknown → In Progress
Changed in fontconfig:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in openoffice.org (openSUSE):
importance: Unknown → Medium
17 comments hidden view all 122 comments

Hi Behdad. Anything new on this?

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

17 comments hidden view all 122 comments

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

(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.

Changed in openoffice.org (openSUSE):
status: In Progress → Unknown
Changed in openoffice.org (openSUSE):
importance: Medium → Undecided
status: Unknown → New

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++)

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

Nothing to test now.

CCing potential testers.

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?

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.

Changed in fontconfig:
importance: Medium → Unknown

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++)

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

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?

Never mind, I believe I have a solution.

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

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

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

tags: added: patch

(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.

Changed in fontconfig:
importance: Unknown → Medium
31 comments hidden view all 122 comments

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.

4 comments hidden view all 122 comments
Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in openoffice:
importance: Undecided → Unknown
status: Invalid → Unknown
summary: - Bold, Italics, and Bold Italics not in English on Fonts menu
+ [Upstream] Bold, Italics, and Bold Italics not in English on Fonts menu
Broco (broco2002) wrote :

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.

Changed in df-libreoffice:
status: Confirmed → Fix Released

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

Changed in libreoffice (Ubuntu):
status: New → Fix Released
3 comments hidden view all 122 comments

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

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

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.

committed with 7587d1c9.

Changed in fontconfig:
status: Confirmed → Fix Released
26 comments hidden view all 122 comments

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.

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

Changed in openoffice:
importance: Unknown → Medium
status: Unknown → Won't Fix
Adolfo Jayme (fitojb) on 2014-09-17
no longer affects: openoffice.org (Ubuntu)
Displaying first 40 and last 40 comments. View all 122 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.