This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 517789 - Droid Sans overrides default Japanese desktop font
Droid Sans overrides default Japanese desktop font
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: google-droid-fonts (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Nicolas Mailhot
Fedora Extras Quality Assurance
: FutureFeature
Depends On: 521697
Blocks: F12Target 520361
  Show dependency treegraph
 
Reported: 2009-08-17 04:12 EDT by Jens Petersen
Modified: 2012-08-22 09:46 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
WIP sans conf (1.05 KB, text/x-config)
2009-09-06 22:42 EDT, Behdad Esfahbod
no flags Details

  None (edit)
Description Jens Petersen 2009-08-17 04:12:48 EDT
Description of problem:
I was just testing a f12alpha spin and discovered that Droid Sans
seems to override the default Japanese desktop font.

How reproducible:
every time

Steps to Reproduce:
1. yum install google-droid-sans-fonts
2. login to gnome desktop 
3. run gucharmap
  
Actual results:
Most kanji glyphs are shown with Droid Sans.

Expected results:
Default Japanese IPA font to be used for Japanese characters.

Additional info:
Not sure why the Droid fonts were pulled into the spin.

This affects whole Japanese desktop and gdm, etc.
Comment 1 Jens Petersen 2009-08-17 04:20:40 EDT
This also affects Korean desktop but not Chinese apparently.
Comment 2 Jens Petersen 2009-08-19 08:33:41 EDT
(In reply to comment #0)
> Not sure why the Droid fonts were pulled into the spin.

Nevermind, Matthias told me it is from fedora-livecd-desktop.ks.

If we're going to install them by default I think
it should be done in @fonts not just for Desktop Live.
Comment 3 Jens Petersen 2009-08-31 04:05:47 EDT
(In reply to comment #2)
> If we're going to install them by default I think
> it should be done in @fonts not just for Desktop Live.  

I filed bug 520361 for this.

65-google-droid-sans.conf:
  <!-- CJK users should check this actually works for them -->
  <match target="scan">
    <test name="lang">
      <string>ja-jp</string>
    </test>
    <test name="family">
      <string>Droid Sans Japanese</string>
:
:

I guess the answer for ja is no. ;)

$ fc-match "lang=ja-JP"
DroidSansFallback.ttf: "Droid Sans" "Regular"
Comment 4 Nicolas Mailhot 2009-09-05 11:19:27 EDT
Droid packaging has not changed for months, I guess this is fallout from all the CJK rules restructuring in fontconfig (I did ask people to check droid too :()

Behdad: do you have an idea on how to restrict this rule properly to Droid Sans and Japanese ? It's not supposed to change the font for non-japanese and non-droid sans

(unless the desktop spin people did set the default font to droid sans, in which case all bets are off)
Comment 5 Behdad Esfahbod 2009-09-05 20:07:28 EDT
Nicolas, can you summarize what's going on?  I'm clueless.
Comment 6 Matthias Clasen 2009-09-05 22:20:45 EDT
Droid fonts are included on the desktop spin. They are not the default.
Comment 7 Behdad Esfahbod 2009-09-05 23:16:19 EDT
So, we do want them in the default install?  Why?

Nicolas, you can't match language on target="scan".  Lemme check your conf file and get back to you.
Comment 8 Nicolas Mailhot 2009-09-06 04:04:47 EDT
(In reply to comment #5)
> Nicolas, can you summarize what's going on?  I'm clueless.  

Droid is now installed on more systems and CJK users complain it replaces their default non-latin fonts. But the intent of droid's fontconfig rules is not to set those fonts as default. They should only select droid sans japanese if the font is droid sans and the language japanese, and only use droid sans fallback if the font is droid sans and the language something else.

So something is not working as expected
Comment 9 Jens Petersen 2009-09-06 22:28:42 EDT
(In reply to comment #7)
> Nicolas, you can't match language on target="scan".  Lemme check your conf file
> and get back to you.  

Thanks I think that summarizes the problem well then.
Comment 10 Jens Petersen 2009-09-06 22:29:52 EDT
(I might add that for ja desktop Droid replaces even Deja Vu.;)
Comment 11 Behdad Esfahbod 2009-09-06 22:41:38 EDT
This is what I wrote to Nicolas in email:

Hey,

Ok, lets see.  A few issues:

1. Why the seemingly random numbers for the conf files?

2. Should I add Droid fonts to default fontconfig config?  At least just the aliasing to/from generics?

3. You should also alias back "Droid Sans Japanese" and "Droid Sans Fallback" to "Droid Sans" now that we are renaming those.

4. You use "prefer", while you really should use "accept".  That's perhaps why the default Japanese font is affected.

5. Lets understand what target="scan" is: It is applied to patterns scanned from the font (that is, what fc-query returns), and can modify it.  So any lang you match there is the languages found in the font, not the user-specified language.

6. The renaming is easy.  The reordering harder, since now we have three fonts all named "Droid Sans" and we don't have any way to address them separately. I checked the coverages, Fallback and Sans overlap a bit.  If we could just delete the lang="ja" from Fallback's coverage, we were mostly done.  But that's currently not possible for a stupid reason.  I filed a bug about that.

In the mean time, this is the solution I came up with: we force a fixed order on the three, by modifying their version tag.  So, Japanese gets the highest version number, 3, and Sans gets 2, finally Fallback gets 1.  This means, when Fontconfig is matching Droid Sans, it tries Japanese first, if the language coverage is enough (ie, we are looking for Japanese), it's matched, otherwise Sans is tried, and finally Fallback.  Voila.  Attached config file for that. A bit hacky to override the version tag, but I can't think of a better solution right now.

7. Given this scheme, and for RPM font tagging to work correctly (that is, to tag with "Droid Sans" instead of "Droid Sans Japanese"), we need to switch the RPM hook from calling fc-query to call fc-scan instead.  The arguments are the same, the latter also applies the configuration rules.  That should do it, except for a but that I just fixed, so next fontconfig release will have it. Can you communicate the change with Panu?

Cheers,
behdad
Comment 12 Behdad Esfahbod 2009-09-06 22:42:26 EDT
Created attachment 359939 [details]
WIP sans conf
Comment 13 Nicolas Mailhot 2009-09-07 01:53:23 EDT
(In reply to comment #11)

> 1. Why the seemingly random numbers for the conf files?

They're not random, droid sans is at 65 because of its wide coverage & CJK otherwise it would have a lower number since it is a high visibility font. If you have a better ordering suggestion I'm all ears. It's not easy to check font priorities, the system is a bit of a blackbox (fc-match is supposed to do it, but no font packager really understands it and it only prints the order for the fonts fond on system hiding the font names that may be defined in the conf files but are not available)

> 2. Should I add Droid fonts to default fontconfig config?  At least just the
> aliasing to/from generics?

I'd rather not, it's a complex font to configure and it'd be easier if droid changes are kept in a single package (that can be updated in previous releases if i18n wants it without involving the fontconfig package)

> 3. You should also alias back "Droid Sans Japanese" and "Droid Sans Fallback"
> to "Droid Sans" now that we are renaming those.

That's a really good idea, I don't know why I didn't before, I probably was just afraid of the whole thing

> 4. You use "prefer", while you really should use "accept".  That's perhaps why
> the default Japanese font is affected.

That's because we use prefer for the other fonts too. I could change it but I'd rather limit the drift from the patterns used elsewhere (or else please confirm accept is sufficient and safe for the other fonts too)

> 5. Lets understand what target="scan" is: It is applied to patterns scanned
> from the font (that is, what fc-query returns), and can modify it.  So any lang
> you match there is the languages found in the font, not the user-specified
> language.

The problem is we want to change the name found in the font. Is there a way to match the user-specified language and change the name in the font?

> 6. The renaming is easy.  The reordering harder, since now we have three fonts
> all named "Droid Sans" and we don't have any way to address them separately. I
> checked the coverages, Fallback and Sans overlap a bit.

That's expected Fallback is just a bunch of medium-quality glyphs to fill holes (I suspect a generic Ascender pile of Glyphs thy also use for other fonts). BTW google did an update to the japanese and fallback files those past days, I just pushed it.

> If we could just
> delete the lang="ja" from Fallback's coverage, we were mostly done.  But that's
> currently not possible for a stupid reason.  I filed a bug about that.
> 
> In the mean time, this is the solution I came up with: we force a fixed order
> on the three, by modifying their version tag.  So, Japanese gets the highest
> version number, 3, and Sans gets 2, finally Fallback gets 1.  This means, when
> Fontconfig is matching Droid Sans, it tries Japanese first, if the language
> coverage is enough (ie, we are looking for Japanese), it's matched, otherwise
> Sans is tried, and finally Fallback.  Voila.  Attached config file for that. A
> bit hacky to override the version tag, but I can't think of a better solution
> right now.

Thanks! I'll look at it in the evening

> 7. Given this scheme, and for RPM font tagging to work correctly (that is, to
> tag with "Droid Sans" instead of "Droid Sans Japanese"), we need to switch the
> RPM hook from calling fc-query to call fc-scan instead. The arguments are the
> same, the latter also applies the configuration rules.  That should do it,
> except for a but that I just fixed, so next fontconfig release will have it.
> Can you communicate the change with Panu?

That's not a problem the part that defines the hook is in fontpackages-devel I can change it at any time without involving Panu. Though the same hook will be called for every font not just Droid. Also, is it something you want to push to pre-rawhide releases? (will only affect rebuilt packages)

BTW there is an interesting aspect I forgot to mention in my mail: we repaint the three fonts as droid sans, and droid sans is in the generic "sans" priority stack. Will that affect the priority of "droid sans japanese" and "droid sans fallback" in this stack too? I'm not quite sure what the correct behaviour would be.
Comment 14 Nicolas Mailhot 2009-09-07 07:19:37 EDT
(In reply to comment #13)
> (In reply to comment #11)

> > 2. Should I add Droid fonts to default fontconfig config?  At least just the
> > aliasing to/from generics?
> 
> I'd rather not

However, now that I think of it, users requested several times that we do a very similar thing for Arial (use Arial Unicode to extend Arial, transform Arial Narrow and Arial Black in proper sub-styles of Arial), and this should be included in fontconfig's default rules since the fonts themselves are user (not distro) installed
Comment 15 Behdad Esfahbod 2009-09-07 14:26:54 EDT
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #11)
> 
> > > 2. Should I add Droid fonts to default fontconfig config?  At least just the
> > > aliasing to/from generics?
> > 
> > I'd rather not
> 
> However, now that I think of it, users requested several times that we do a
> very similar thing for Arial (use Arial Unicode to extend Arial, transform
> Arial Narrow and Arial Black in proper sub-styles of Arial), and this should be
> included in fontconfig's default rules since the fonts themselves are user (not
> distro) installed  

The Vista version of those fonts should work since I assume they have WWS names too.
Comment 16 Nicolas Mailhot 2009-09-07 14:32:36 EDT
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)

> > However, now that I think of it, users requested several times that we do a
> > very similar thing for Arial (use Arial Unicode to extend Arial, transform
> > Arial Narrow and Arial Black in proper sub-styles of Arial), and this should be
> > included in fontconfig's default rules since the fonts themselves are user (not
> > distro) installed  
> 
> The Vista version of those fonts should work since I assume they have WWS names
> too.  

Sure but there are quite a lot of users that still use the previous versions that do not have the fixed naming metadata
Comment 17 Nicolas Mailhot 2009-09-07 15:28:58 EDT
(In reply to comment #13)

> > 7. Given this scheme, and for RPM font tagging to work correctly (that is, to
> > tag with "Droid Sans" instead of "Droid Sans Japanese"), we need to switch the
> > RPM hook from calling fc-query to call fc-scan instead. The arguments are the
> > same, the latter also applies the configuration rules.  That should do it,
> > except for a but that I just fixed, so next fontconfig release will have it.
> > Can you communicate the change with Panu?
> 
> That's not a problem

Sorry I confused it with scriptlets, the fc-query part is Panu-side indeed.
Filled bug #521697 to track the rpm part

However, if I understand the logic correctly, you want to replace fc-query with
fc-scan to take into account fontconfig rules. That's a great idea *except* the
package fontconfig files won't be installed in the build root at this time !

So if that's really the intention, fc-scan needs to grow an argument so we can
pass it a set of additional fontconfig files (or a directory containing
fontconfig files) explicitely
Comment 18 Nicolas Mailhot 2009-09-07 18:15:03 EDT
Anyway I pushed
https://koji.fedoraproject.org/koji/buildinfo?buildID=130936

it should have all the fixes that do not depend on changes in rpm (that only matter at package resolution time, not once it's installed)

CJK users: please test it does the correct thing for you
Comment 19 Nicolas Mailhot 2009-09-08 14:54:16 EDT
(In reply to comment #13)
> (In reply to comment #11)

> > 3. You should also alias back "Droid Sans Japanese" and "Droid Sans Fallback"
> > to "Droid Sans" now that we are renaming those.
> 
> That's a really good idea, I don't know why I didn't before, I probably was
> just afraid of the whole thing

BTW we use two different patterns for aliasing right now:

1. "use font Y to complete font X" (for a font which is installed bug with limited coverage):
 
  <alias>
    <family>X</family>
    <default>
      <family>Y</family>
    </default>
  </alias>

2. "use font Y when asked for font X" (for fonts that may not be installed)

  <alias binding="same">
    <family>X</family>
    <accept>
      <family>Y</family>
    </accept>
  </alias>

Which pattern is more appropriate for this case?

Also, can we use the same logic to fixup at fontconfig level fonts with bad naming metadata (all the stuff that fails WWS and takes ages to be fixed in the font files upstream)? For example would the following pattern be something that could be generalised? Or do you have objections/better ideas?

  <match target="scan">
    <test name="family">
      <string>Letters Laughing</string>
    </test>
    <test name="style">
      <string>at their Execution</string>
    </test>
    <edit name="family">
      <string>Letters Laughing at their Execution</string>
    </edit>
    <edit name="style">
      <string>Regular</string>
    </edit>
  </match>

  <alias>
    <family>Letters Laughing at their Execution</family>
    <default>
      <family>Fantasy</family>
    </default>
  </alias>

  <!-- Not sure at all about this but something is needed for backwards compat -->
  <alias>
    <family>Letters Laughing</family>
    <style>at their Execution</family>
    <default>
      <family>Letters Laughing at their Execution</family>
      <style>Regular<style>
    </default>
  </alias>
Comment 20 Jens Petersen 2009-09-09 06:05:18 EDT
(In reply to comment #18)
> CJK users: please test it does the correct thing for you  

I tested google-droid-fonts-20090906-2.fc12 in rawhide
and still overriding Japanese fonts.
Comment 21 Nicolas Mailhot 2009-09-09 06:45:13 EDT
Jens, when you say "overriding Japanese fonts" what do you mean? What is your testing protocol? Does the behaviour change if your remove the droid fontconfig symlink in /etc/fonts/conf.d?

The original post mentions gucharmap, but I don't think it's the right application to test the CJK language-specific overrides we do in fontconfig rules. You need an app that displays complete text (not just some individual glyphs) and sets the japanese language (tests under the en_US locale are not valid)

Droid itself does not even try to do something specific for japanese anymore
Comment 22 Behdad Esfahbod 2009-09-10 11:31:37 EDT
(In reply to comment #19)
> (In reply to comment #13)
> > (In reply to comment #11)
> 
> > > 3. You should also alias back "Droid Sans Japanese" and "Droid Sans Fallback"
> > > to "Droid Sans" now that we are renaming those.
> > 
> > That's a really good idea, I don't know why I didn't before, I probably was
> > just afraid of the whole thing
> 
> BTW we use two different patterns for aliasing right now:
> 
> 1. "use font Y to complete font X" (for a font which is installed bug with
> limited coverage):
> 
>   <alias>
>     <family>X</family>
>     <default>
>       <family>Y</family>
>     </default>
>   </alias>
> 
> 2. "use font Y when asked for font X" (for fonts that may not be installed)
> 
>   <alias binding="same">
>     <family>X</family>
>     <accept>
>       <family>Y</family>
>     </accept>
>   </alias>
> 
> Which pattern is more appropriate for this case?

The latter.


> Also, can we use the same logic to fixup at fontconfig level fonts with bad
> naming metadata (all the stuff that fails WWS and takes ages to be fixed in the
> font files upstream)? For example would the following pattern be something that
> could be generalised? Or do you have objections/better ideas?
> 
>   <match target="scan">
>     <test name="family">
>       <string>Letters Laughing</string>
>     </test>
>     <test name="style">
>       <string>at their Execution</string>
>     </test>
>     <edit name="family">
>       <string>Letters Laughing at their Execution</string>
>     </edit>
>     <edit name="style">
>       <string>Regular</string>
>     </edit>
>   </match>
> 
>   <alias>
>     <family>Letters Laughing at their Execution</family>
>     <default>
>       <family>Fantasy</family>
>     </default>
>   </alias>

This is a good idea, yes.


>   <!-- Not sure at all about this but something is needed for backwards compat
> -->
>   <alias>
>     <family>Letters Laughing</family>
>     <style>at their Execution</family>
>     <default>
>       <family>Letters Laughing at their Execution</family>
>       <style>Regular<style>
>     </default>
>   </alias>  

I wouldn't bother about the style part here.
Comment 23 Nicolas Mailhot 2009-09-10 14:42:40 EDT
(In reply to comment #22)
> (In reply to comment #19)
> > (In reply to comment #13)
> > > (In reply to comment #11)
> > 
> > > > 3. You should also alias back "Droid Sans Japanese" and "Droid Sans Fallback"
> > > > to "Droid Sans" now that we are renaming those.
> > > 
> > > That's a really good idea, I don't know why I didn't before, I probably was
> > > just afraid of the whole thing
> > 
> > BTW we use two different patterns for aliasing right now:
> > 
> > 1. "use font Y to complete font X" (for a font which is installed bug with
> > limited coverage):
> > 
> >   <alias>
> >     <family>X</family>
> >     <default>
> >       <family>Y</family>
> >     </default>
> >   </alias>
> > 
> > 2. "use font Y when asked for font X" (for fonts that may not be installed)
> > 
> >   <alias binding="same">
> >     <family>X</family>
> >     <accept>
> >       <family>Y</family>
> >     </accept>
> >   </alias>
> > 
> > Which pattern is more appropriate for this case?
> 
> The latter.
> 
> 
> > Also, can we use the same logic to fixup at fontconfig level fonts with bad
> > naming metadata 

> This is a good idea, yes.

Thank you for the opinion!
 
> 
> >   <!-- Not sure at all about this but something is needed for backwards compat
> > -->
> >   <alias>
> >     <family>Letters Laughing</family>
> >     <style>at their Execution</family>
> >     <default>
> >       <family>Letters Laughing at their Execution</family>
> >       <style>Regular<style>
> >     </default>
> >   </alias>  
> 
> I wouldn't bother about the style part here.  

Well I certainly need to specify the style of the font to be remapped (since there are other "Letters Laughing" weird styles that need to be mapped at different font families). In that particular case, since "Letters Laughing at their Execution" will have a single style, I guess I could pass on the target style. But what about when you try to remap fonts from the "4 styles" area which have been needlessly split into separate families ? Say, you have an A. font set with R,B,I,BI and an A. Narrow font set also with R,B,I,BI If you write

 <alias>
   <family>A. Narrow</family>
   <style>Bold</family>
   <default>
     <family>A.</family>
   </default>
 </alias>  

won't that clobber A. Bold? Surely you do need to specify the target style in that case

 <alias>
   <family>A. Narrow</family>
   <style>Bold</family>
   <default>
     <family>A.</family>
     <style>Narrow Bold</family>
   </default>
 </alias>

(too lazy to check how the WWS spec says the "Narrow" qualifier should be written nowadays)

Actually what I was not sure about is that

   <default>
     <family>A.</family>
     <style>Narrow Bold</family>
   </default>

will be treated as a single font, not a list but I suppose a list in this context would be stupid, so surely fontconfig will treat it as a single-font pattern, right?
Comment 24 Nicolas Mailhot 2009-09-13 15:35:30 EDT
Well, I tried it in an actual package and fontconfig errors on the style lines

Fontconfig warning: "/etc/fonts/conf.d/65-senamirmir-washra.conf", line 43: unknown element "style"
Fontconfig warning: "/etc/fonts/conf.d/65-senamirmir-washra.conf", line 46: unknown element "style"

  <alias binding="same">
    <family>Ethiopic WashRa SemiBold</family>
    <style>Bold</style> ⇐ 43
    <accept>
      <family>Ethiopic WashRa</family>
      <style>DemiBold</style> ⇐ 46
    </accept>
  </alias>

Behdad: how is one supposed to alias a specific style in fontconfig?

In the meanwhile I also pushed a tweaked droid package that takes Behdad's latest advice into account. I'd be surprised if it had any effect on japanese priority, but who knows.

http://koji.fedoraproject.org/koji/buildinfo?buildID=131757

Someone please test on a CJK system (and report back, detailing the test he used if it does not work)
Comment 25 Jens Petersen 2009-09-14 04:18:14 EDT
(In reply to comment #24)
> http://koji.fedoraproject.org/koji/buildinfo?buildID=131757

google-droid-fonts-20090906-4.fc12

> Someone please test on a CJK system

I just tried and no change unfortunately.

> (and report back, detailing the test he used if it does not work)

Test:
1) LC_CTYPE=ja_JP.UTF-8 gucharmap
2) search for '和'

Cases:
A) with google-droid-sans-fonts installed
B) without google-droid-sans-fonts

Results:
A) glyph rendered in Droid Sans
B) glyph rendered in IPAPGothic

(Of course if you are running a running a japanese desktop
(or use LANG instead of LC_CTYPE) you will see whole desktop
(application) change too.)
Comment 26 Jens Petersen 2009-09-14 04:34:29 EDT
A simpler test is probably just:

$ LANG=ja_JP.UTF-8 fc-match lang=ja
DroidSansJapanese.ttf: "Droid Sans" "Regular"

So at least it is using DroidSansJapanese now for Japanese,
but we don't want to make it the default font for Japanese.

$ LANG=ja_JP.UTF-8 fc-match sans:lang=ja
DroidSansJapanese.ttf: "Droid Sans" "Regular"
$ LANG=zh_CN.UTF-8 fc-match sans:lang=ja
DroidSansJapanese.ttf: "Droid Sans" "Regular"
$ LANG=ja_JP.UTF-8 fc-match sans:lang=zh
uming.ttc: "AR PL UMing HK" "Light"
$ LANG=zh_CN.UTF-8 fc-match sans:lang=zh
uming.ttc: "AR PL UMing HK" "Light"
$ LANG=zh_CN.UTF-8 fc-match lang=zh
DroidSansFallback.ttf: "Droid Sans" "Regular"
Comment 27 Nicolas Mailhot 2009-09-14 05:06:09 EDT
Well, assuming you have no other fontconfig file referencing droid on-system, I guess that it all a fontconfig problem for Behdad. The droid package does not declare any japanese-specific rule, so the "if japanese, use me first" rules in the ipa packages should take precedence (didn't check they were actually there, I just know they're not in droid)

Does it change if you try 
LANG=ja_JP.UTF-8 fc-match lang=ja_JP or
LANG=ja_JP.UTF-8 fc-match lang=ja-JP ?

I don't think ja is a complete fontconfig locale, and fontconfig does not allow matching on a partial locale sanely (ie it matches any substring, does not really parse the format, so would trip on en-ja or jas-foo etc)
Comment 28 Jens Petersen 2009-09-14 20:25:26 EDT
(In reply to comment #27)
> Does it change if you try 
> LANG=ja_JP.UTF-8 fc-match lang=ja_JP or
> LANG=ja_JP.UTF-8 fc-match lang=ja-JP ?

No, they also give:
DroidSansJapanese.ttf: "Droid Sans" "Regular"
Comment 29 Jens Petersen 2009-09-24 22:35:45 EDT
I have commented out google-droid-*-fonts from Desktop Live .ks
and moving this to F12Target.
Comment 30 Nicolas Mailhot 2009-09-26 06:27:48 EDT
Reassigning to Behdad, since any progress on this bug depends on him (I'll happily take the bug back once he tells us how to make the fontconfig rules work as expected)
Comment 31 Behdad Esfahbod 2009-09-28 14:48:18 EDT
Lets get back to this after f12...
Comment 32 Jens Petersen 2010-02-03 19:37:55 EST
Shouldn't we have lang="zh" for Droid Sans Fallback
and lang="ja" for Droid Sans Japanese in the font .conf?
Comment 33 Jens Petersen 2010-02-03 19:38:56 EST
or ja-JP etc...
Comment 34 Nicolas Mailhot 2010-02-04 06:13:22 EST
(In reply to comment #32)
> Shouldn't we have lang="zh" for Droid Sans Fallback
> and lang="ja" for Droid Sans Japanese in the font .conf?    

They are not exposed as-is, they're merged in a single "Droid Sans" from the user POW. The problem is that it messes the priority of the CJK bits (we need to distinguish the name exposed to the user and the priorities assigned to each bit that is used to compose the synthetic font)

Can probably be fixed by splitting instructions in separate files with different priorities, but this is not-obvious to do and I need to find the time to play with it some more.
Comment 35 Bug Zapper 2010-03-15 08:46:24 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 36 Jens Petersen 2010-05-06 04:42:49 EDT
(Just noticed the discussion about Droid on fedora desktop list...)

This looks fixed to me in F13 with all the fonts .conf locale fixes
we have done, including's dropping binding="same".

Maybe someone else could also verify?
Comment 37 Akira TAGOH 2010-05-10 04:47:42 EDT
confirmed. this issue however has just been hidden with the renaming the config file to 65-0- thing. this change could be required for Chinese fonts as well, and others perhaps since both are put in the same priority 65 and Droid Sans appears prior to wqy-*-fonts because of the alphabetical order. this is still not good since wqy-zenhei-fonts is the default font for Simplified Chinese.

FWIW having the enough coverage would be nice. but why don't you change the priority to 66 or the lower priority than 65? the priority thing affects how to determine the default font for languages. before giving the higher priority we should have discussion and have agreements for that in the community IMHO. it could be fixed in other fonts, but want to avoid chasing on the priority without the right thing. this is why I want to see more restrict priority policy but anyway.
Comment 38 Jens Petersen 2010-07-22 01:54:41 EDT
Can we close this?
Comment 39 Nicolas Mailhot 2010-09-23 13:44:53 EDT
(In reply to comment #38)
> Can we close this?

Please keep it open, I do not despair of finding a way to conditionalise Droid Sans CJK someday (I try it every other month, so far no luck)

I hope that now Behdad's working for Google it will be easier to coax him in making Droid work perfectly :)

As you noted, the worst side-effect has been hidden by the fontconfig cleanups in other packages
Comment 40 Akira TAGOH 2010-11-12 03:00:50 EST
+1 to nim-nim's comment. if we can have the certain solution on this issue, that would be nice rather than just closing by hiding the issue. guess moving back the status may be good.
Comment 41 Akira TAGOH 2011-05-24 08:38:18 EDT
We should added a FutureFeature tag to avoid auto-closing by the Bug Zapper accidentally. moving back to rawhide again.
Comment 42 Fedora Admin XMLRPC Client 2011-06-20 17:54:40 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 43 Richard Shaw 2011-06-20 19:54:22 EDT
Hello everyone. I wanted to introduce myself as I'm the new maintainer for this package. 

I'm a relatively new packager but I've been using linux since RH6. I mainly took this package because it's needed by some MythTV themes, so unfortunately I don't have a lot of linux font experience so I may need some direction.

If someone could update me to the current situation for this bug I'd appreciate it. 

Thanks,
Richard
Comment 44 Fedora Admin XMLRPC Client 2011-06-23 17:08:20 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 45 Mike FABIAN 2012-08-22 09:46:55 EDT
(In reply to comment #26)
> A simpler test is probably just:
> 
> $ LANG=ja_JP.UTF-8 fc-match lang=ja
> DroidSansJapanese.ttf: "Droid Sans" "Regular"

I think there is a colon missing in front of “lang=ja”.
On Fedora 17 I get:

    $ LC_ALL=ja_JP.UTF-8 fc-match 
    DroidSansJapanese.ttf: "Droid Sans" "Regular"

I.e. I still see the problem on Fedora 17.
Adding the “lang=ja” changes nothing because of the missing colon:

    $ LC_ALL=ja_JP.UTF-8 fc-match lang=ja
    DroidSansJapanese.ttf: "Droid Sans" "Regular"

But when using “:lang=ja” “VL PGothic” is selected, no matter
what the locale is:
    
    $ LC_ALL=ja_JP.UTF-8 fc-match :lang=ja
    VL-PGothic-Regular.ttf: "VL PGothic" "regular"

    $ LC_ALL=en_GB.UTF-8 fc-match :lang=ja
    VL-PGothic-Regular.ttf: "VL PGothic" "regular"

    $ fc-match :lang=ja
    VL-PGothic-Regular.ttf: "VL PGothic" "regular"

> So at least it is using DroidSansJapanese now for Japanese,
> but we don't want to make it the default font for Japanese.
> 
> $ LANG=ja_JP.UTF-8 fc-match sans:lang=ja
> DroidSansJapanese.ttf: "Droid Sans" "Regular"
> $ LANG=zh_CN.UTF-8 fc-match sans:lang=ja
> DroidSansJapanese.ttf: "Droid Sans" "Regular"
> $ LANG=ja_JP.UTF-8 fc-match sans:lang=zh
> uming.ttc: "AR PL UMing HK" "Light"
> $ LANG=zh_CN.UTF-8 fc-match sans:lang=zh
> uming.ttc: "AR PL UMing HK" "Light"
> $ LANG=zh_CN.UTF-8 fc-match lang=zh
> DroidSansFallback.ttf: "Droid Sans" "Regular"

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