Request for review and advice on wqy-bitmap-fonts fontconfig settings
by Qianqian Fang
hi
I am quite new as a Fedora package maintainer. I submitted
a few Chinese font packages to Fedora, and luckily, Jens Petersen
has been extremely patient and guided me through
package submission processes. I am glad that these fonts are
now serving the Chinese Fedora users and we got quite good
feedbacks from them.
Today, I would like to ask for your help to create a robust
fontconfig file for wqy-bitmap-fonts. This font was installed
by default in Fedora 8 for Chinese users. It recently caused
some problems displaying Latins for non-Chinese users.
Please see bug #381311 for more details.
https://bugzilla.redhat.com/show_bug.cgi?id=381311
I will describe my goals, the achieved results and the
problems.
===================================
1. Motivations and goals
As an active developer and Linux user for couple of years,
I strongly feel that there is a consensus among most Chinese users
(both Mainland and Taiwan) for font rendering. These consensus
can be summarized as the followings:
1. given the fact that most Chinese vector font rendering are
quite blurry on nearly all Linux distributions, plus the fact that
there is
no free Chinese fonts with high quality hinting, hand-tuned
bitmap glyphs are preferred for on screen display of Chinese characters
2. Latin glyphs has low stroke density and autohinting is becoming
sufficient, using vector glyphs of these non-CJK characters is preferred
3. ideally, the requirement #1 should be locale independent (maybe
exclude ko/ja
users, if it conflicts with their consensus); requirement #2 is virtually
true for most modern Linux desktops nowadays (for non-CJK locales)
The following two pictures may shine some light on what
a normal Chinese user considers as a "good" font rendering:
* under non-Chinese locales (use en_US as an example)
[can not be achieved for now, used post-processing]
http://wenq.org/gallery/albums/userpics/10002/confopt_preferred_rendering...
* under Chinese locales (use zh_TW as an example)
[achieved on F8 with wqy-bitmap-fonts 0.9.9-1]
http://wenq.org/gallery/albums/userpics/10002/confopt_preferred_rendering...
the main features include:
A. when rendering Hanzi for generic aliases (i.e. sans/serif/mono):
A.1: if font sizes are common on screen, such as 8pt-12pt, use bitmap
Chinese font
A.2: for sizes above or below, use the first preferred vector Chinese font
B. when rendering non-Hanzi (or non-CJK) glyphs, use the preferred fonts
determined by fontconfig
C. when a specific Chinese font was chosen, exclusively use this font
for all covered characters
===================================
2. Default rendering of Hanzi on F8 without wqy-bitmap-fonts
Without installing wqy-bitmap-fonts, the screenshots of F8 is shown below:
* under non-Chinese locales (use en_US as an example)
http://wenq.org/gallery/albums/userpics/10002/confopt_F8_no_wqy-bitmap_en...
unsatisfactories:
1) no bitmap fonts were used for screen-sized Hanzi
2) garbled text with a mixture of Japanese and Chinese fonts (the headings)
3) Hanzi glyphs are blurry, getting worse for large blocks of text
* under Chinese locales (use zh_TW as an example)
http://wenq.org/gallery/albums/userpics/10002/confopt_F8_no_wqy-bitmap_zh...
unsatisfactories:
1) generally looks OK if Uming is installed
2) for mono, the Latins in Uming were used, rather than Dejavu/Vera
3) for serif, no bitmap glyphs because UKai has no embedded bitmaps
===================================
3. Hanzi rendering on F8 with 85-wqy-bitmapsong.conf
The devel. of wqy-bitmap-fonts started from expanding the embedded
bitmap fonts
in Uming (both originated from firefly-bitmap-font) 3 years ago. After
3 years development at wenq.org, our project website, we have completed
all bitmap glyphs for CJK Basic (U4E00-U9FA5) and CJK Extension A
(U3400-U4DB5), covering 27,484 characters at 4 point sizes, nearly
twice of the Uming's embed bitmaps (only ~15,000 characters). In addition,
80% of the old firefly(uming) glyphs were fine-tuned. The improvements are
quite significant, making the font a popular choice among Chinese users.
The following sample shows the difference between uming and
wqy-bitmap-fonts:
http://wenq.org/gallery/albums/userpics/10002/confopt_wqy-bitmap_vs_uming...
In package wqy-bitmap-fonts, we provided a default fontconfig file,
85-wqy-bitmapsong.conf (see attachment). Using this file, we raised
the priority of wqy-bitmap-fonts for rendering Hanzi, while trying to
keep it
lower than the default sans/serif/mono Latin fonts. With this
file, Chinese users are able to get the preferred rendering as
shown above, i.e.
http://wenq.org/gallery/albums/userpics/10002/confopt_preferred_rendering...
however, for English locales, it did not seem to improve the situation, nor
make it worse (at least with my copy)
http://wenq.org/gallery/albums/userpics/10002/en_US_with_wqy-bitmap-fonts...
I do noticed that this file has side effects, the bug thread (#381311)
as an example,
however, so far I have not yet been able to identify the exact cause.
These reports
are rather random and mostly non-repeatable. Debugging fontconfig outputs
constantly gives me confusing results. My guess is that we might use some
fragile fontconfig syntax and are not consistently executed over
different systems.
===================================
4. Questions
That's all I want to learn from you: do you see a robust implementation
of fontconfig font selection mechanism to achieve my goals above?
if yes, how? if no, to whom should I file bug reports to?
I apologize for the long email, I wish you read to this line before
giving up.
thank you so much and looking forward to hearing back from you.
Qianqian
16 years
Re: Bunch of new Fonts added to wishlist
by Nicolas Mailhot
Le Lun 26 novembre 2007 15:25, Sarantis Paskalis a écrit :
> As you saw already, these are packaged as mgopen-fonts. The mgopen
> project, however, does not seem to be making any progress beyond the
> first release of the fonts.
Same thing as what happened to Vera. The various people wanting to
make the fonts evolve need to agree on a new FLOSS upstream like it
happened to DejaVu. IMHO we should not package all the MGOpen
derivatives before a clear new upstream emerges.
>> GFS Didot
>> GFS Bodoni
>> GFS Neohellenic
>> GFS Artemisia
>> GFS Theokritos
>> GFS Olga
>> GFS Didot Classic
>> GFS Porson
>> GFS Baskerville
>> GFS Bodoni Classic
>> GFS Gazis
>> GFS Solomos
>> GFS Porson
>> GFS Complutum
>
> I plan to package the above some time if noone beats me to it.
Already done but now the packages await review (half of them at least).
> When the
> tetex->TeXLive dust settles, I plan to also package the TeX-related
> bindings.
If you know tex please do Computer Modern Unicode - he's stuck waiting
for someone that understands tex to write a specfile that allows
building it from Fedora TEX in Fedora fontforge.
> A side question: Does anyone have experience about packaging the same
> font both for X11 and TeX? Do I need to include the same font files
> twice? Create soft/hard links for efficiency? Require one (X11) for
> the other (TeX)?
As I already answered bitmap and core X11 fonts users : the wiki is
open for new guidelines, as long as they respect our general packaging
policy
http://fedoraproject.org/wiki/SIGs/Fonts/Packaging/Policy
Regards,
--
Nicolas Mailhot
16 years
Re: Core fonts packaging guidelines writer WANTED
by Nicolas Mailhot
Le Jeu 29 novembre 2007 11:09, Hans de Goede a écrit :
> And here is the problem again, if some people want to see things
> changed (mainly see the requires upon mkfontdir / mkfontscale removed)
To restore historical accuracy the broken package had no mkfontdir
dependencies through no particular action of mine, you proposed to add
them, and when I pointed out this would conflict with the work I'm
doing and that there were other solutions (that you already knew of)
you went in full-blown "screw the SIG if I break things hard enough it
will do the work my apps need" mode.
[again apologies for the flame spileage I hoped answers would be
limited to contructuve proposals]
--
Nicolas Mailhot
16 years
Re: Core fonts packaging guidelines writer WANTED
by Nicolas Mailhot
Le Jeu 29 novembre 2007 11:09, Hans de Goede a écrit :
> Nicolas Mailhot wrote:
> And here is the problem, when you write "the level of abuse we've seen
> from core font users lately" below, I guess you mean mainly me, and I
> apologize as I indeed have wrongly blamed the font SIG for the current
> breakage.
My aim was not to blame anyone, and while particularly excessive your
reaction is fairly representative of the core font community so far.
(ignore changes, let things rot, blame others when they finish
breaking, and expect them to do the maintenance work in your stead).
> However the above alinea starting at "Do not fall ..." is simply not
> acceptable, there are 2 and only 2 options here:
> 1) Leave core font packages as they are, as that has worked well for
> years,
It hasn't worked well, the difference is that the magic fairies that
kept them working finaly left after numerous warnings enough was
enough, leaving the people who claimed there was no problem handle the
whole core fonts mess (since no one else used them anymore).
Like every other component of the distribution core fonts need
maintenance to keep working. The environment changes, if you want to
freeze it just install a Fedora 1 to 7 system. One of the changes is a
large group of users, OLPC, (that do actual work for the distro future
unlike frozen-in-time legacy apps) requested making core fonts
optional. Another is xfs was dumped. Yet another is the xorg version
we use changed, and the new version does not register core font
directories the same way. There are others I'm probably forgetting
now.
As a result leaving things as they are is not an option. Install
pre-fedora 8 core font packages in Fedora 8 and you'll see how well
they work in a current environment.
Do you really want me to comment on your choice of (quoting) "the new
guidelines are broken in that they do not offer a solution to the
problem this creates, so I say ignore them until this bug in the
guidelines gets fixed."?
(in other words intentionaly push the one solution you know conflicts
so someone else gets to document and fix the stuff your minority is
using)
Well I don't want to waste more time on this, my mail was addressed to
people who are actually willing to do some work to restore core fonts
to a maintained state. Please stand up. You'll get all the help the
Fonts SIG can extend to help you make your beloved legacy apps work.
I apologise to the lists for the flame spillovers.
--
Nicolas Mailhot
16 years
Core fonts packaging guidelines writer WANTED
by Nicolas Mailhot
Hi,
As most of you know server-side fonts accessed through the core X11
protocol (aka core fonts) were superceded by client-side
(fontconfig...) fonts in the past years.
We've finally acknowledged this fact in Fedora 8 by removing xfs and
the brutal check that killed user X sessions if more fonts were
misconfigured (the dreaded "can not find font 'fixed'"). IIRC this was
an OLPC request and I fully support this decision.
As a result the burden of keeping core fonts working moved from the
distribution as a whole to the group of people maintaining and using
the small group of legacy applications that still use them.
It seems this change was not integrated properly and several core font
packages slipped in Fedora 8 in a broken state without anyone noticing
(not through evil intent, just because the affected packages are old
and
crufty and the people that stridently defend core fonts use were
doing something else). For the calendar-impaired, that was before the
Fonts SIG started its activities.
To fix this situation, I call for one or several core font users to
rise to the occasion:
A. Please join the fonts SIG
http://fedoraproject.org/wiki/SIGs/Fonts
B. Please write well-though core fonts packaging guidelines consistent
with the objectives of people already doing fonts work for other font
backends. That means in particular not having core font utilities
dependencies in font packages
http://fedoraproject.org/wiki/PackagingDrafts/FontsPolicy#no-handler-deps
Several possible technical solutions have already been posted on the
list, such as:
1. pre-generating fonts.* files at %build time or
2. duplicating the solution used for the fontconfig backend. That means:
a. dynamically generating fonts.* files in conditionnal scriptlets
(if core font tools are present on system), and
b. have one package responsible for walking the configured core font
directories and re-generating fonts.* files when installed, and make
core font apps depend on it (so things still work if a core font
using app is installed after fonts packages are)
There may be other solutions, it's up to the core fonts community to
choose one.
Do not fall in the facility of brutaly making font packages depend on
mkfontdir, as a lot of font packages are not exposed only via the core
X11 protocol and most of their users do not want the core font stack
installed. (OLPC is such a group).
C. Please discuss your guidelines on the Fonts SIG list and among core
fonts users so we have consensus. Then get your guidelines
officialised
D. Please audit all the existing core fonts packages and make them
conform to the resulting core font guidelines, so we don't get
accidental breakage like right now
Anyone stepping in to do this will have my complete support, and I
hope the one of the whole distribution.
Otherwise Jens has indicated he may end up writing core fonts
packaging guidelines, but frankly given the level of abuse we've seen
from core font users lately I'd understand if he passed. And in the
end core fonts users would be better served by guidelines written by
less busy people who actually use the core fonts backend.
This will be my last statement on the subject. Thank you for your
attention.
--
Nicolas Mailhot
16 years
Re: [Fedora-legal-list] Re: Bunch of new Fonts added to wishlist
by Sarantis Paskalis
On Mon, Nov 26, 2007 at 10:13:03AM -0500, Tom spot Callaway wrote:
>
> On Mon, 2007-11-26 at 15:58 +0100, Nicolas Mailhot wrote:
> > >> Kerkis
> > >
> > > There is a Kerkis package for TeX (tetex-font-kerkis). Nowadays, the
> > > author of this font publishes TTF and OTF files, quite suitable for
> > > on-screen display. The license, however, is a bit ambiguous, possibly
> > > even a removal candidate. http://iris.math.aegean.gr/kerkis/ (see the
> > > License subsection).
> >
> > This one should have been passed through fedora-legal before
> > inclusion.
>
> Definitely. That license is waaaay too vague as is.
>
> We'd need to know if:
>
> 1. Modification is permitted
> 2. Redistribution is permitted (this is implied, but not explicitly
> granted)
> 3. Redistribution in embedded documents is permitted
>
> That's just for starters. The commercial copyright "advertising" clause
> is also painfully vague.
>
> Someone motivated (and likely, fluent in greek), should email the
> copyright holders and suggest that they either clarify their license, or
> consider relicensing it with an established free license (e.g. the OFL).
I will contact the author to clarify the above. Thanks for the
guidelines.
-- Sarantis
16 years
Re: Low-Vision Fonts GPL'd--Can we consider for F-9?
by Nicolas Mailhot
Please CC the fonts list on fonts stuff
Le lundi 26 novembre 2007 à 13:55 -0500, Tom "spot" Callaway a écrit :
> On Mon, 2007-11-26 at 13:02 -0500, Janina Sajka wrote:
> > This is a heads up and RFE. PerhapsGnome is the appropriate path to
> > introduce this specialized font--but perhaps F-9 might simply want to
> > take it up directly?
>
> Sure, why not? If gnome picks it up, we can always have it obsolete
> this.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=399881
Some quick comments (I'm knee-deep in my own packaging right now)
– upstream forgot the font embedding GPL exception. Not a blocker but
users will complain
– I'm not too fond of multisource spec files, separate packages are
usually more flexible and easier to maintain
Regards,
--
Nicolas Mailhot
16 years
Re: Bunch of new Fonts added to wishlist
by Nicolas Mailhot
>> Kerkis
>
> There is a Kerkis package for TeX (tetex-font-kerkis). Nowadays, the
> author of this font publishes TTF and OTF files, quite suitable for
> on-screen display. The license, however, is a bit ambiguous, possibly
> even a removal candidate. http://iris.math.aegean.gr/kerkis/ (see the
> License subsection).
This one should have been passed through fedora-legal before
inclusion. Everyone please do not package any font with a new license
without getting its license approved on
http://fedoraproject.org/wiki/SIGs/Fonts/Legal
--
Nicolas Mailhot
16 years
