Le Ven 27 juillet 2012 12:42, Akira TAGOH a écrit :
> <match target="scan">
> <test="family" ignore-blanks="yes">
> <string>Droid Sans Fallback</string>
> <edit name="lang" mode="assign">
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.
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
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.
I've just pushed new Droid font packages to Fedora Rawhide.
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:
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
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.
Most of you aware regarding liberation license problem we are facing from
long time. Looks like time came when we can get rid of it.
Google has recently released google-croscore fonts.
- These are from same vendor ascendar with OFL license and more glyph
coverage than existing liberation.
- Existing shape in liberation and same as croscore since from the
- Use base of croscore fonts and apply enhancements available in
liberation and call new entity liberation 2.0
1. Liberation license issues will get resolved
2. Liberation user community will get enhanced fonts. i.e. more language
Need help from legal for doing licensing stuff, dunno how we can crack
licensing of Liberation SansNarrow.
Now that Android has left git.kernel.org (and its gitweb) has anyone got a
better solution than cloning several gigs of android git to check if Droid
has been updated upstream?
BTW: looking at the aforementionned repo clone it looks like Google added
new script-specific droid bits so I guess trying to make a single
composite font out of them in fontconfig will get yet more complicated. If
anyone has suggestions on how to evolve
I'm all ears
I'm going to submit the feature proposal for f18 that
someone around here may be interesting.
P.S. I'm wondering if I should submit a separate feature for
enabling autohint by default or do it without the feature
page or just postpone...
After some time procrastinating I've finally bumped STIX fonts to 1.1.0 in
This is a major update (1 years and a half work upstream IIRC)
Gone is the huge pile of files only TEX macros could beat some sense in,
the new font layout finally approaches sanity. The cons being that if
you've used the old font names in documents, you're in trouble. I've tried
to limit the breakage through fontconfig aliasing (but that only works for
apps smart enough to use fontconfig).
Please report problems (if any).
For the aforementioned reasons, I don't intend to push this update to
current and past releases.
After some procrastination time I've bumped STIX fonts to 1.1 in Rawhide.
This is a major release (1 year and a half work upstream IIRC)
The font layout and naming has been changed to something approaching
sanity, and the complexfont piles only TEX ma
just corrected the template of the locale-specific overrides rule at https://fedoraproject.org/wiki/Fontconfig_packaging_tips
There are no changes of the behavior though, in next release of fontconfig, it will warns if <test> elements contains multiple values, this change has been made because of the unreliable/non-intuitive behavior. for alternatives, if one wants to test the lang, you can use compare="contains" instead. otherwise you'll need to put more <match>es then.
I'll post the list of the packages here later what packages needs to be updated for that and also will file a bug too.