Fontconfig - Jul 2012 - Heads up: Droid fonts update in Rawhide

Hi,

I''ve just pushed new Droid font packages to Fedora Rawhide.
http://koji.fedoraproject.org/koji/buildinfo?buildID=330644

Droid are complex font families with a difficult upstream and the
following caveats apply:

A. I used a few hundred MiBs of Android git checkout as source. The fonts
are also available in the Google font directory but it does not permit
convenient checkout (one either needs to collect download URLs
file-by-file, or perform a full-repository multi-gig mercurial checkout),
its relationship with android as upstream is unclear, and it has been
known to cut-down fonts to limit their weight when used in CSS files. As
for other web sites, they are generally more convenient, but their
upstream status is unclear, and they love to zap licensing terms to
?simplify? their users'' lives (even in Google-sponsored sites). So I
concluded that what was good enough for Android was good enough for us.

B. The fonts follow Keith Packard''s ?one font per script? ideal but I
seriously question if fontconfig as it exists today is ready to process
such an ideal. Expect to hit bugs in fontconfig or in apps with
approximative fontconfig calls (the first generation of this package
triggered a Chromium bug; Android uses its own font and font fallback tech
so those fonts are not heavily tested in a fontconfig environment).
Fedora fontconfig files for Droid are available here:
http://pkgs.fedoraproject.org/gitweb/?p=google-droid-fonts.git;a=tree

C. I tried to dispatch the Arabic variants in the Latin family they were
designed to complement, but I may have misunderstood the design info
available online.

D. Lots of new scripts here. i18n and l10n teams probably need to take a
look to decide it that changes font defaults for some locales, and if
compts changes are needed.

E. If the package description does not correctly attribute the main
designers involved, please educate me and I''ll correct it.

F. I''ve zapped DroidSansFallbackFull DroidSansFallbackLegacy
DroidSansArabic DroidNaskh-Regular-SystemUI that seemed redundant. If they
 provide something missing in the other files, please tell me what it is
and I''ll fix the packages.

And that''s all for this notification. Needless to say for this level of
changes those packages will only be available in F18 after F18 QA and
won''t ever be pushed to previous Fedora versions.

Best regards,

-- 
Nicolas Mailhot

Hi Dave,

Thanks for the quick answer!
> On 15 July 2012 21:42, Nicolas Mailhot <nicolas.mailhot at
laposte.net>
> wrote:
>> A. I used a few hundred MiBs of Android git checkout as source.
>
> That''s the canonical source for Droid, yes.
>
> (The Roboto fonts in that repo has another canonical source,
> http://developer.android.com/design/style/typography.html)
Well that''s one of the unhelpful Google web sites. Its zip informs you:

"You may use the materials in this file without restriction to develop
your apps and to use in your apps."

I haven''t the faintest idea what that means legally. If I was mad
enough
to package another set of Google fonts, I''d source Roboto from android
git
like Droid, where it is clearly tagged with the Apache license.
>> its relationship with android as upstream is unclear
>
> They are separate projects and while formally have the same parent
> company, they may as well be different companies with no relationship
> beyond their libre license.
Nice clarification! (I suspected as much but the VCS histories were
unclear on when and why changes were propagated from one to the other)
>> C. I tried to dispatch the Arabic variants in the Latin family they
were
>> designed to complement, but I may have misunderstood the design info
>> available online.
>
> Please clarify ''dispatch'' :-)
Kufi with Sans (masquerading as the Arabic block of Droid Sans) and Naskh
with Serif the same way (see the long fontconfig ruleset I referenced)

http://www.29arabicletters.com/foundry/?m=1-1-1&fid=26
states Naskh was designed to complement Serif

and
https://code.google.com/p/chromium-os/issues/detail?id=17382
that chromium uses Kufi with Sans
>> E. If the package description does not correctly attribute the main
>> designers involved, please educate me and I''ll correct it.
>
> I''ll see if I can find out more about this.
That would be appreciated. I only found descriptions for the new Arabic
fonts.
>> F. I''ve zapped DroidSansFallbackFull DroidSansFallbackLegacy
>> DroidSansArabic DroidNaskh-Regular-SystemUI that seemed redundant. If
>> they
>> provide something missing in the other files, please tell me what it is
>> and I''ll fix the packages.
>
> The Fallback fonts have CJK glyphs and others character ranges not
> found in the other fonts. The Legacy one can probably be forgotten.
I should have indicated I kept DroidSansFallback (no idea if it''s
missing
something important compared to DroidSansFallbackFull and
DroidSansFallbackLegacy)
> The UI variants have adjusted vertical metrics to fit the Android
UI''s
> vertical space limitations.
Ok that means they can be ignored on a desktop.

Thanks for the useful information!

Best regards,

-- 
Nicolas Mailhot

On 07/15/2012 06:01 PM, Nicolas Mailhot wrote:
>>> C. I tried to dispatch the Arabic variants in the Latin family they
were
>>> >> designed to complement, but I may have misunderstood the
design info
>>> >> available online.
>> >
>> > Please clarify ''dispatch'' :-)
> Kufi with Sans (masquerading as the Arabic block of Droid Sans) and Naskh
> with Serif the same way (see the long fontconfig ruleset I referenced)
> 
> http://www.29arabicletters.com/foundry/?m=1-1-1&fid=26
> states Naskh was designed to complement Serif
> 
> and
> https://code.google.com/p/chromium-os/issues/detail?id=17382
> that chromium uses Kufi with Sans
That may have been the case, but it is my personal understanding that we
should dispatch Naskh with both Sans and Serif.  Kufi is a horrible font for
body text.

behdad

> On 07/15/2012 06:01 PM, Nicolas Mailhot wrote:
>>>> C. I tried to dispatch the Arabic variants in the Latin family
they
>>>> were
>>>> >> designed to complement, but I may have misunderstood
the design
>>>> info
>>>> >> available online.
>>> >
>>> > Please clarify ''dispatch'' :-)
>> Kufi with Sans (masquerading as the Arabic block of Droid Sans) and
>> Naskh
>> with Serif the same way (see the long fontconfig ruleset I referenced)
>>
>> http://www.29arabicletters.com/foundry/?m=1-1-1&fid=26
>> states Naskh was designed to complement Serif
>>
>> and
>> https://code.google.com/p/chromium-os/issues/detail?id=17382
>> that chromium uses Kufi with Sans
>
> That may have been the case, but it is my personal understanding that we
> should dispatch Naskh with both Sans and Serif.  Kufi is a horrible font
> for
> body text.
So make kufi a separate family and keep the old droid sans arabic for
sans? Or is it also horrible in some way?

Regards,

-- 
Nicolas Mailhot

>
>> On 07/15/2012 06:01 PM, Nicolas Mailhot wrote:
>>>>> C. I tried to dispatch the Arabic variants in the Latin
family they
>>>>> were
>>>>> >> designed to complement, but I may have
misunderstood the design
>>>>> info
>>>>> >> available online.
>>>> >
>>>> > Please clarify ''dispatch'' :-)
>>> Kufi with Sans (masquerading as the Arabic block of Droid Sans) and
>>> Naskh
>>> with Serif the same way (see the long fontconfig ruleset I
referenced)
>>>
>>> http://www.29arabicletters.com/foundry/?m=1-1-1&fid=26
>>> states Naskh was designed to complement Serif
>>>
>>> and
>>> https://code.google.com/p/chromium-os/issues/detail?id=17382
>>> that chromium uses Kufi with Sans
>>
>> That may have been the case, but it is my personal understanding that
we
>> should dispatch Naskh with both Sans and Serif.  Kufi is a horrible
font
>> for
>> body text.
>
> So make kufi a separate family and keep the old droid sans arabic for
> sans? Or is it also horrible in some way?
BTW regardless of your answer here, with your former fontconfig maintainer
hat on, how do you make a font family masquerade as parts of two other
font families? If I understand the recipe you gave me for use in Fedora,
after Naskh has been morphed in Serif, it is not available anymore to
morph in Sans. That would be a useful operation to perform for cultures
which had not a western calligraphic separation culture

Regards,

-- 
Nicolas Mailhot

On 07/16/2012 02:00 AM, Nicolas Mailhot wrote:
> So make kufi a separate family and keep the old droid sans arabic for
> sans? Or is it also horrible in some way?
I''d say yes.

behdad

On 07/16/2012 02:37 AM, Nicolas Mailhot wrote:
> BTW regardless of your answer here, with your former fontconfig maintainer
> hat on, how do you make a font family masquerade as parts of two other
> font families? If I understand the recipe you gave me for use in Fedora,
> after Naskh has been morphed in Serif, it is not available anymore to
> morph in Sans. That would be a useful operation to perform for cultures
> which had not a western calligraphic separation culture
In the same recipe with match="scan", I *think* you can add multiple
families
and remove the original one, instead of replacing it.

behdad

Le Mer 25 juillet 2012 14:55, Behdad Esfahbod a ?crit :
> On 07/16/2012 02:00 AM, Nicolas Mailhot wrote:
>> So make kufi a separate family and keep the old droid sans arabic for
>> sans? Or is it also horrible in some way?
>
> I''d say yes.
Ok then I''ll take it the changes in
http://pkgs.fedoraproject.org/gitweb/?p=google-droid-fonts.git;a=tree
are ok for production use.

Need to find some brave arabic users to test your other suggestion

-- 
Nicolas Mailhot

Using lang-test pattern for scan doesn''t work as expected because it
only happens when creating caches.

On Thu, Jul 26, 2012 at 12:17 AM, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
>
> Le Mer 25 juillet 2012 14:55, Behdad Esfahbod a ?crit :
>> On 07/16/2012 02:00 AM, Nicolas Mailhot wrote:
>>> So make kufi a separate family and keep the old droid sans arabic
for
>>> sans? Or is it also horrible in some way?
>>
>> I''d say yes.
>
> Ok then I''ll take it the changes in
> http://pkgs.fedoraproject.org/gitweb/?p=google-droid-fonts.git;a=tree
> are ok for production use.
>
> Need to find some brave arabic users to test your other suggestion
>
> --
> Nicolas Mailhot
>
> _______________________________________________
> Fontconfig mailing list
> Fontconfig at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/fontconfig


-- 
Akira TAGOH

Hi,

Akira TAGOH wrote:
> Using lang-test pattern for scan doesn''t work as expected because
it
> only happens when creating caches.
That also struck me as odd -- the rules for DroidSansJapanese.ttf, 
right? I suppose one could use edits instead, to add or replace
''lang''
properties as needed for the later match, or use target="pattern"
rules
for that face.

In this case, I''m not sure if this is even necessary though, because I 
just dropped DroidSansJapanese.ttf in my font folder and it seemed that 
it didn''t advertise any of the ''zh*'' locales anyway.


Behdad Esfahbod wrote:
> In the same recipe with match="scan", I *think* you can add
multiple families
> and remove the original one, instead of replacing it.
Yes it is possible to append or replace multiple family names at scan 
time, so that "Droid Sans Japanese" becomes "Droid Serif,Droid
Sans"
which matches both, i. e.

   <match target="scan">
     <test name="family"><string>Droid Sans
Japanese</string></test>
     <edit name="family" mode="assign">
       <string>Droid Sans</string>
       <string>Droid Serif</string>
     </edit>
   </match>

will make the following possible:

sun2:~)fc-list Droid\ Serif file family
/export/pub/fonts/Droid/DroidSerif-Regular.ttf: Droid Serif
/export/pub/fonts/Droid/DroidSansJapanese.ttf: Droid Sans,Droid Serif

sun2:~)fc-list Droid\ Sans file family
/export/pub/fonts/Droid/DroidSans.ttf: Droid Sans
/export/pub/fonts/Droid/DroidSansJapanese.ttf: Droid Sans,Droid Serif

sun2:~)fc-list Droid\ Serif:lang=ja file family
/export/pub/fonts/Droid/DroidSansJapanese.ttf: Droid Sans,Droid Serif

sun2:~)fc-list Droid\ Sans:lang=ja file family
/export/pub/fonts/Droid/DroidSansJapanese.ttf: Droid Sans,Droid Serif

Although I think mode="append" is smarter here, because it''s
an easy way
of retaining compatibility with all places that directly refer to the 
locale-specific name and expect it to be enumerable with FcFontList.


As a side note, I do wonder why it might be useful to generate all these 
exact same family names at scan time. Shouldn''t
target="pattern"/alias
rules be able to do the same, like ''sans'' and
''serif'' already map to all
the different fonts for the different languages?

OK I understand that enumeration with FcFontList (for drop-down boxes 
and such) will then list the locale-specific variants, but -- without 
any particular experience with this font -- I think that''s what 
applications expect anyway -- or isn''t it?


Raimund






>
> On Thu, Jul 26, 2012 at 12:17 AM, Nicolas Mailhot
> <nicolas.mailhot at laposte.net> wrote:
>>
>> Le Mer 25 juillet 2012 14:55, Behdad Esfahbod a ?crit :
>>> On 07/16/2012 02:00 AM, Nicolas Mailhot wrote:
>>>> So make kufi a separate family and keep the old droid sans
arabic for
>>>> sans? Or is it also horrible in some way?
>>>
>>> I''d say yes.
>>
>> Ok then I''ll take it the changes in
>> http://pkgs.fedoraproject.org/gitweb/?p=google-droid-fonts.git;a=tree
>> are ok for production use.
>>
>> Need to find some brave arabic users to test your other suggestion
>>
>> --
>> Nicolas Mailhot
>>
>> _______________________________________________
>> Fontconfig mailing list
>> Fontconfig at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/fontconfig
>
>
>

-- 
Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346

On Thu, Jul 26, 2012 at 9:42 AM, Raimund Steger <rs at mytum.de>
wrote:
> That also struck me as odd -- the rules for DroidSansJapanese.ttf, right? I
> suppose one could use edits instead, to add or replace
''lang'' properties as
> needed for the later match, or use target="pattern" rules for
that face.
Yeah, it is. but doing the same thing on target="pattern"
doesn''t help
because it doesn''t take effects as expected when getting the real
substitute font, because, given that one wants to maintain those
families as Droid Sans and asking fontconfig for the substitute font,
DroidSansJapanese.ttf is still recognized as Droid Sans Japanese in
fontconfig. i.e. Droid Sans Japanese in the pattern won''t pick up
Droid Sans and vice versa.

That''s why it has to be done in target="scan" time to make
unified
font family. but once it''s unified, there are no way to exclude
particular glyphs for certain languages. what options we have so far
is to use a font or not.
> Yes it is possible to append or replace multiple family names at scan time,
> so that "Droid Sans Japanese" becomes "Droid Serif,Droid
Sans" which matches
Well, I see what Nicolas wants to do here. since Japanese characters
on Unicode''s CJK Unified Ideographs is a subset of Chinese characters,
I think he wanted to avoid picking Droid Sans Japanese up for Chinese
anyway.

So once integrating all of Droid fonts families into Driod *, it''s
hard to recognize variants later.

-- 
Akira TAGOH

Le Jeu 26 juillet 2012 09:32, Akira TAGOH a ?crit :
> Well, I see what Nicolas wants to do here. since Japanese characters
> on Unicode''s CJK Unified Ideographs is a subset of Chinese
characters,
> I think he wanted to avoid picking Droid Sans Japanese up for Chinese
> anyway.
Ideally, I''d like the target="scan" lang-specific rules to
generate a form
of simulated locl table. I know the current rules I use don''t do that,
but
I guess they are a sort of RFE on my part :)

I think Droid is a good showcase of the dead-end
selecting-lang-by-font-name is : if we don''t hide the various
lang-specific droid names to the user, it only takes two or three
droid-like families to make font selection totally unusable in most apps.

Best regards,

-- 
Nicolas Mailhot

Nicolas Mailhot wrote:
>
> Le Jeu 26 juillet 2012 09:32, Akira TAGOH a ?crit :
>
>> Well, I see what Nicolas wants to do here. since Japanese characters
>> on Unicode''s CJK Unified Ideographs is a subset of Chinese
characters,
>> I think he wanted to avoid picking Droid Sans Japanese up for Chinese
>> anyway.
But it wouldn''t be picked, even without ''lang'' rules,
at least it isn''t
on my machine. Even if I use target="scan" to assign a single family 
name to all Droid fonts, the ''lang'' of DroidSansJapanese.ttf
will still
only be ''ja'', and won''t be taken into account when
enumerating or
matching fonts for a different locale:

sun2:~)fc-list '':lang=ja'' file family | grep DroidSansJapanese
/export/pub/fonts/Droid/DroidSansJapanese.ttf: Droid Serif,Droid Sans

sun2:~)fc-list '':lang=zh'' file family | grep DroidSansJapanese
>
> Ideally, I''d like the target="scan" lang-specific rules
to generate a form
> of simulated locl table. I know the current rules I use don''t do
that, but
> I guess they are a sort of RFE on my part :)
>
> I think Droid is a good showcase of the dead-end
> selecting-lang-by-font-name is : if we don''t hide the various
> lang-specific droid names to the user, it only takes two or three
> droid-like families to make font selection totally unusable in most apps.
That''s what I wonder. Imagine someone created a document in a word 
processor on Android, or maybe on Windows. Would they be able to 
directly choose ''Droid Sans Japanese'' etc. out of their
selector? If
not, then you''re right and it makes sense to hide the name. If yes,
then
fontconfig should enumerate the original full name, and maybe provide 
the usual 2-way fallback from/to ''Droid Sans''.

Raimund


-- 
Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346

On Thu, Jul 26, 2012 at 5:57 PM, Raimund Steger <rs at mytum.de>
wrote:
> But it wouldn''t be picked, even without ''lang''
rules, at least it isn''t on
> my machine. Even if I use target="scan" to assign a single family
name to
> all Droid fonts, the ''lang'' of DroidSansJapanese.ttf will
still only be
> ''ja'', and won''t be taken into account when
enumerating or matching fonts for
> a different locale:
>
> sun2:~)fc-list '':lang=ja'' file family | grep
DroidSansJapanese
> /export/pub/fonts/Droid/DroidSansJapanese.ttf: Droid Serif,Droid Sans
>
> sun2:~)fc-list '':lang=zh'' file family | grep
DroidSansJapanese
Aha. you''re right. so just getting rid of testing lang from
DroidSansJapanese and DroidSansFallback may works then.
> That''s what I wonder. Imagine someone created a document in a word
processor
> on Android, or maybe on Windows. Would they be able to directly choose
> ''Droid Sans Japanese'' etc. out of their selector? If not,
then you''re right
> and it makes sense to hide the name. If yes, then fontconfig should
> enumerate the original full name, and maybe provide the usual 2-way
fallback
> from/to ''Droid Sans''.
They can. speaking of Android, their API is capable to open a font
with the aliases, the specific family name and from the file as apps
can has a font in their assets. though they don''t use fontconfig to
find out the substitute font.

-- 
Akira TAGOH

On Thu, Jul 26, 2012 at 9:42 AM, Raimund Steger <rs at mytum.de>
wrote:
> Although I think mode="append" is smarter here, because
it''s an easy way of
> retaining compatibility with all places that directly refer to the
> locale-specific name and expect it to be enumerable with FcFontList.
Ah, I got what you mean here. yes, definitely. apparently one don''t
need to have the substitution rule like:
  <alias binding="same">
     <family>X</family>
     <accept><family>Y</family></accept>
  </alias>

So

<match target="scan">
  <test
name="family"><string>X</string></test>
  <edit name="family"
mode="append"><string>Y</string></edit>
</match>

should be so smart in this case.

-- 
Akira TAGOH

Akira TAGOH wrote:
> On Thu, Jul 26, 2012 at 9:42 AM, Raimund Steger <rs at mytum.de>
wrote:
>> Although I think mode="append" is smarter here, because
it''s an easy way of
>> retaining compatibility with all places that directly refer to the
>> locale-specific name and expect it to be enumerable with FcFontList.
>
> Ah, I got what you mean here. yes, definitely. apparently one
don''t
> need to have the substitution rule like:
>    <alias binding="same">
>       <family>X</family>
>       <accept><family>Y</family></accept>
>    </alias>
>
> So
>
> <match target="scan">
>    <test
name="family"><string>X</string></test>
>    <edit name="family"
mode="append"><string>Y</string></edit>
> </match>
>
> should be so smart in this case.
>
Yes. The main differences I see are that

(1) if family Y isn''t a "real" family, or if Y
doesn''t support the
''lang'' in the pattern, then the <alias> rule will not
return the family
in FcFontList. The target="scan" rule will do that.

(2) if family Y *is* a real family, then the <alias> rule might cause 
its language to be ignored (at least without any additional rules) if 
someone uses FcFontMatch to ask for Y with strong binding, as that will 
override ''lang''. Conversely, if someone expects to *always*
get Y
regardless of language when asking for it, they won''t be able to do it 
with the target="scan" rule. (This has the potential to cause some
user
frustration I think.)

(3) with the target="scan" rule, target="font" edits, which
some people
use to apply final twiddling to the font returned by FcFontMatch, can 
test for family Y as well.

The <alias> rule is more lightweight because it doesn''t affect
the
cache, so I usually prefer that, but it''s probably less of an issue for
distribution-provided fonts.


Raimund



-- 
Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346

On Fri, Jul 27, 2012 at 6:05 PM, Raimund Steger <rs at mytum.de>
wrote:
> (2) if family Y *is* a real family, then the <alias> rule might cause
its
> language to be ignored (at least without any additional rules) if someone
> uses FcFontMatch to ask for Y with strong binding, as that will override
> ''lang''. Conversely, if someone expects to *always* get Y
regardless of
> language when asking for it, they won''t be able to do it with the
> target="scan" rule. (This has the potential to cause some user
frustration I
> think.)
Not really. I managed to do it with mode="prepend" instead of
mode="append" for this case.

So my conclusion so far for unifying font families is:

1. basically this can be done in target="scan".
2. better use mode="append" in <edit> for virtual fonts. this
saves
one to have substitution rule in <alias>.
3. better use mode="prepend" in <edit> for real font
substitution. it
ensure keep the family name in the query to the result.

just attached the example.

Well, I personally don''t like to use Droid Fallback for Japanese. so
want to add more rules like the following to avoid it:

<match target="scan">
  <test="family" ignore-blanks="yes">
    <string>Droid Sans Fallback</string>
  </test>
  <edit name="lang" mode="assign">
    <minus><name>lang</name>
      <langset><string>ja</string></langset>
    </minus>
  </edit>
</match>

-- 
Akira TAGOH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: google-droid-fonts-sans-fontconfig.conf
Type: application/octet-stream
Size: 4405 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/fontconfig/attachments/20120727/e8da1573/attachment.obj>

Le Ven 27 juillet 2012 12:42, Akira TAGOH a ?crit :
> <match target="scan">
>   <test="family" ignore-blanks="yes">
>     <string>Droid Sans Fallback</string>
>   </test>
>   <edit name="lang" mode="assign">
>     <minus><name>lang</name>
>       <langset><string>ja</string></langset>
>     </minus>
>   </edit>
> </match>
Thanks a lot for the experimenting. I take it that the most complete
config version you produced is the patch you sent separately, not the
version attached to this mail?

Just to be clear: it''s perfectly OK if the droid sans foo names subsist
inside fontconfig, the aim is only to cull them from the font selection
dropdowns in GUI apps

Another complex fontconfig substitution scenario that needs investigating
is automatic use of PT Sans Caption instead of PT Sans at small sizes, to
simulate a modern smart font automatically in fontconfig apps

(see the documentation for caption on https://www.adobe.com/type/opentype/)

It''s quite nice that after years of having a nice composing framework,
but
not enough floss fonts to exercise it, the problem is now to catch up with
the possibilities offered by recent font projects.

Best regards,

-- 
Nicolas Mailhot

On Fri, Jul 27, 2012 at 9:04 PM, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
> Thanks a lot for the experimenting. I take it that the most complete
> config version you produced is the patch you sent separately, not the
> version attached to this mail?
Attached here is one of them. what I sent you separately is a complete patch.
> Just to be clear: it''s perfectly OK if the droid sans foo names
subsist
> inside fontconfig, the aim is only to cull them from the font selection
> dropdowns in GUI apps
Well, as it still keeps the original name as the family name, both
name may appears there. it may depends on how applications deal with
the multiple values in FcPattern.
> Another complex fontconfig substitution scenario that needs investigating
> is automatic use of PT Sans Caption instead of PT Sans at small sizes, to
> simulate a modern smart font automatically in fontconfig apps
Aha. interesting.
> It''s quite nice that after years of having a nice composing
framework, but
> not enough floss fonts to exercise it, the problem is now to catch up with
> the possibilities offered by recent font projects.
>
> Best regards,
>
> --
> Nicolas Mailhot
>
-- 
Akira TAGOH

On Fri, July 27, 2012 12:42, Akira TAGOH wrote:
> On Fri, Jul 27, 2012 at 6:05 PM, Raimund Steger <rs at mytum.de>
wrote:
>> [...]
>> ''lang''. Conversely, if someone expects to *always*
get Y regardless of
>> language when asking for it, they won''t be able to do it with
the
>> target="scan" rule. (This has the potential to cause some
user
>> frustration I
>> think.)
>
> Not really. I managed to do it with mode="prepend" instead of
> mode="append" for this case.
But how would you do that (I mean, getting DroidSans.ttf just by its name
regardless of locale)? I just tried the following:

  <match target="scan">
    <test name="family"><string>Droid Sans
Japanese</string></test>
    <edit mode="prepend" name="family">
      <string>Droid Sans</string>
    </edit>
  </match>

Now what I''m getting is:

wlm2s092:~)LC_CTYPE=ja fc-match ''Droid Sans''
DroidSansJapanese.ttf: "Droid Sans" "Regular"

wlm2s092:~)LC_CTYPE=en fc-match ''Droid Sans''
DroidSans.ttf: "Droid Sans" "Regular"

To get DroidSans.ttf by its original family name when running in locale
''ja'', when that rule is in place, it is necessary to apply an
additional
''lang=en'' to the pattern.

wlm2s092:~)LC_CTYPE=ja fc-match ''Droid Sans:lang=en''
DroidSans.ttf: "Droid Sans" "Regular"

(Actually I didn''t observe any changed behavior compared to
"append" in
this case.)

Now of course this seems to be what we want, otherwise it would be a bad
"composite font".

But I''m just saying that an application that uses
XftFontOpenName(...,"Droid Sans") and XftDrawString* to draw some
ASCII
content, might draw only empty boxes when running in a ''ja''
locale where
it gets "Droid Sans Japanese" instead, but work fine in an
''en'' locale.

Well, I do realize that''s a pretty far-fetched example and with Pango
that
shouldn''t be a problem anyway.

Otherwise I think your configuration should work fine. Because of the
mode="prepend", the GTK picker even hides the original family names
(at
least my old GTK 2.18 picker does). But as you said, that might depend on
applications. (Still I don''t think that future Fedora users would
completely freak out if they happened to spot a ''Droid Sans
XYZ'' string in
a picker somewhere, but that''s just my opinion.)

(I gather the ''fontversion'' properties are used to apply an
additional
precedence to the Droid variants, so that removing ''ja'' from
''Droid Sans
Fallback'' would be unnecessary when the latter has a lower version, and
vice versa?)

Raimund



-- 
Worringer Str 31 Duesseldorf 40211 Germany +49-179-2981632 icq 16845346

On Fri, Jul 27, 2012 at 11:01 PM, Raimund Steger <rs at mytum.de>
wrote:
> But I''m just saying that an application that uses
> XftFontOpenName(...,"Droid Sans") and XftDrawString* to draw some
ASCII
> content, might draw only empty boxes when running in a
''ja'' locale where
> it gets "Droid Sans Japanese" instead, but work fine in an
''en'' locale.
I don''t think we can do something in fontconfig for that case. it has
similar issue on XFontStruct vs XFontSet.
> (I gather the ''fontversion'' properties are used to apply
an additional
> precedence to the Droid variants, so that removing ''ja''
from ''Droid Sans
> Fallback'' would be unnecessary when the latter has a lower
version, and
> vice versa?)
As long as DroidSansJapanese.ttf is installed right.

-- 
Akira TAGOH

On Fri, Jul 27, 2012 at 02:04:52PM +0200, Nicolas Mailhot
wrote:
> 
> Le Ven 27 juillet 2012 12:42, Akira TAGOH a ?crit :
> 
> > <match target="scan">
> >   <test="family" ignore-blanks="yes">
> >     <string>Droid Sans Fallback</string>
> >   </test>
> >   <edit name="lang" mode="assign">
> >     <minus><name>lang</name>
> >       <langset><string>ja</string></langset>
> >     </minus>
> >   </edit>
> > </match>
> 
> Thanks a lot for the experimenting. I take it that the most complete
> config version you produced is the patch you sent separately, not the
> version attached to this mail?
> 
> Just to be clear: it''s perfectly OK if the droid sans foo names
subsist
> inside fontconfig, the aim is only to cull them from the font selection
> dropdowns in GUI apps
> 
> Another complex fontconfig substitution scenario that needs investigating
> is automatic use of PT Sans Caption instead of PT Sans at small sizes, to
> simulate a modern smart font automatically in fontconfig apps
Fonts with more than one optical design can (and should) use OpenType
size feature[1]. A good example for such fonts is the Latin Modern
family, which are badly handled by fontconfig.

[1] http://www.microsoft.com/typography/otspec/features_pt.htm#size

Regards,
 Khaled