Re: [Fwd: Droid fallback CJK and fontconfig?]
by Qianqian Fang
hi Nicolas
As we discussed last time, I've sent email asking for official confirmation
and clarifications of the license in the font metadata. I am now waiting
to hear back from them (message attached).
The Han glyphs in Droid fallback pretty much follow the Han-unification
as in the unicode documentations. That means they look very much close
to what Chinese mainland users preferred. The style is Heiti, which is like
ttf-wqy-zenhei and is essentially a sans-serif style. There are 16,502 Hanzi
in the CJK basic block, which is the union of GB2312 and Big5 charsets.
Because this font is targeted at memory-limited devices, there are
15,524 Han glyphs were composed by references, the rest are stand-alone
outline glyphs which can not be decomposed into components.
It contains no embedded bitmaps, but the outline quality is very good.
I believe most zh_* users will be very happy if this font will be used
as desktop font (the current zh_* font on Fedora is wqy-bitmapfont
which is also using the Han-unification forms). It may be a little bit
difficult for Japanese and Korean users though.
As this font does not provide the full coverage to all CJK glyphs,
in the mean time, I believe the current national standards and
regulations in mainland China prefer GBK (same as CJK unified ideographs),
or even GB18030 (CJK basic+CJK Ext. A) coverage, so, I've planned to extend
this font to at least GBK charset. That means to complete about 4500
glyphs. I and a friend are now working on an online tool to allow
people to compose new glyphs from existing Droid components.
It is almost working, you can browse the following link for a sample
output: (need to view with firefox 3.x)
http://wenq.org/enindex.cgi?ViewGlyph#SFD/Droid/%E8%85%AA
the GUI is at http://wenq.org/enindex.cgi?BezierGlyph
but it only has Chinese instructions so far.
Once the license is sorted out, we will start promoting this project
among the Chinese users, and make our way toward a more complete
CJK font with this extension. I also planned to look into the reference
glyphs and seek the possibility of further compression of the font.
Similar to the current ttf-wqy-zenhei settings, Chinese users will also be
happy to see a mono-spaced face co-existing with the regular face in
ttc form.
Qianqian
Joe Onorato wrote:
> Hi Qianqian,
>
> I'll follow up with the people responsible for fonts.
>
> -joe
>
>
>
> On Mon, Nov 17, 2008 at 11:09 PM, Qianqian Fang <fangqq(a)gmail.com
> <mailto:fangqq@gmail.com>> wrote:
>
> hi Joe
>
> A few weeks ago, I posted a question on android-discussion group,
> asking about the droid font licenses:
>
> http://groups.google.com/group/android-discuss/browse_thread/thread/3c608...
> <http://groups.google.com/group/android-discuss/browse_thread/thread/3c608...>
>
> I really appreciate your feedback and confirmation on the license
> matter.
>
> As I am an maintainer for an open-source font project, I also
> maintain a few CJKV font packages for Fedora. Recently, I
> mentioned my plan of making derived fonts from Droid
> font family at fedora's font list, the people in charge appeared
> to be very careful, and warned me to obtain a more "official"
> clarification on the license before taking further actions. You
> can see our discussions at
>
> https://www.redhat.com/archives/fedora-fonts-list/2008-November/msg00009....
>
> We both felt that the best way to make the clarifications is to state
> it in the metadata section of the font, there are dedicated
> "License Description"
> and "License Info URL" fields in the name table to specify the
> font licenses:
>
> http://partners.adobe.com/public/developer/opentype/index_name.html
>
> I am wondering if it is possible for android team to update the font
> files and clarify the licenses. In this way, people's confusion on
> the fonts
> and the sdk package will completely go away.
>
> If you or your team member do have the plan to make this
> change, I would be appreciated if you can let me know when
> the updated fonts are pushed into svn, so I can mobilize my
> team to start planned works around these fonts.
>
> thank you so much for your time and looking forward to your reply.
>
> Qianqian
>
>
Nicolas Mailhot wrote:
> Hi,
>
> As you probably know Google has released a Droid font set as part of its
> Android platform. While the font licensing is being clarified
> https://bugzilla.redhat.com/show_bug.cgi?id=472635
> (Fedora packaging blocker) I've taken a quick look at the font files.
>
> The set includes a huge "Droid Sans Fallback" font with CJK coverage.
> Could the CJK folks take a look at it and tell me how this font should
> be treated: as Japanese-only, Chinese-only, Korean-only before/after
> current CJK defaults, etc? Han unification means someone will probably
> not be happy about it.
>
> I've uploaded preliminary droid packages there
> http://nim.fedorapeople.org/fontpackages/
>
> so people can check them out.
>
> Regards,
>
>
> ------------------------------------------------------------------------
>
> --
> Fedora-i18n-list mailing list
> Fedora-i18n-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-i18n-list
15 years
Re: [Fwd: Droid fallback CJK and fontconfig?]
by Qianqian Fang
Just a few more words about default Chinese font settings.
There seem be a distinct dividing line among the Chinese
users for their font preferences: on one side of the line,
they really prefer sharp-looking bitmaped Chinese glyphs, while,
the other side have strong preference in the smooth-looking of
AA-ed vector rendering. The contradictions between these two
groups can be constantly felt in almost all Chinese Linux
forums.
Using Ubuntu as an example, when Ubuntu 8.04 set wqy-zenhei
as the default Chinese Sans font, it has the embedded bitmaps turned
on by default. There was a strong rally against using the
embedded bitmaps, because they like the vector form of
ZenHei. I have to put instructions on our front page to tell
people how to turn off the bitmaps. After a 400-participant
survey, somebody proved that vector-preferred users are about
3:1 to the bitmap ones
http://forum.ubuntu.org.cn/viewtopic.php?f=8&t=120639 (in Chinese)
So, in 8.10, the bitmaps in ZenHei was turned off. Now,
the CN forum of ubuntu is flooded with complains of
losing their "sharp-looking glyphs", and asking how to turn
on the bitmaps. I had to make another sticky post at our website
to teach people how to turn it back on.
What I want to say is, these two groups both have significant
number of supporters. As the current settings on Fedora is
the bitmap way. I would anticipate some disturbance among
the users for the font style switching from one to the other
if we decide to use Droid(or derivatives) as the default.
Hope the font-selector tool can be released timely to help
sorting out the font preference chaos:
https://wiki.kubuntu.org/font-selector
Nicolas Mailhot wrote:
> Hi,
>
> As you probably know Google has released a Droid font set as part of its
> Android platform. While the font licensing is being clarified
> https://bugzilla.redhat.com/show_bug.cgi?id=472635
> (Fedora packaging blocker) I've taken a quick look at the font files.
>
> The set includes a huge "Droid Sans Fallback" font with CJK coverage.
> Could the CJK folks take a look at it and tell me how this font should
> be treated: as Japanese-only, Chinese-only, Korean-only before/after
> current CJK defaults, etc? Han unification means someone will probably
> not be happy about it.
>
> I've uploaded preliminary droid packages there
> http://nim.fedorapeople.org/fontpackages/
>
> so people can check them out.
>
> Regards,
>
>
> ------------------------------------------------------------------------
>
> --
> Fedora-i18n-list mailing list
> Fedora-i18n-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-i18n-list
15 years
Droid fallback CJK and fontconfig?
by Nicolas Mailhot
Hi,
As you probably know Google has released a Droid font set as part of its
Android platform. While the font licensing is being clarified
https://bugzilla.redhat.com/show_bug.cgi?id=472635
(Fedora packaging blocker) I've taken a quick look at the font files.
The set includes a huge "Droid Sans Fallback" font with CJK coverage.
Could the CJK folks take a look at it and tell me how this font should
be treated: as Japanese-only, Chinese-only, Korean-only before/after
current CJK defaults, etc? Han unification means someone will probably
not be happy about it.
I've uploaded preliminary droid packages there
http://nim.fedorapeople.org/fontpackages/
so people can check them out.
Regards,
--
Nicolas Mailhot
15 years
Re: where's the wish list for F11?
by Nicolas Mailhot
Le vendredi 21 novembre 2008 à 10:00 -0500, sean darcy a écrit :
> But can't this be done without making an rpm package ( which may or may
> not raise legal issues).
Installing anything via an rpm will be just as legal (or not) as
installing it by other means
> I'm looking for something much simpler: I go buy/get a font; I open
> fonts-filesystem/system-config-fonts/whatever ; I point it to the font (
> Type1, TT, etc); and the font is installed.
So you're asking for a font-specific installation method.
Why not add a clipart-specific one? And a templates-specific one? And a
palette-specific one?
This quickly ends up an unmanageable mess wasting the time of everyone
involved.
You already have a limited user-level font installation method for
casual users (or had, a bug is open to resurect it). Anything more
complex, such as a system-wide method needing to replicate all the work
we already do in rpm, is a waste of resources.
> Making an rpm package of the font first seems to make this more involved
> than it needs to be.
The key word here is seems. Like many other "shortcuts", trying to avoid
making an rpm will end up a lot more work unless you really know what
you're doing (which you only will after having made a few rpms).
--
Nicolas Mailhot
15 years
Re: FWN article on web font surveys
by Nicolas Mailhot
Hi Nicu,
Thank you for taking the time to reply.
To avoid repeating the very unpleasant 1h30 exchange I had with infra
yesterday after sending my message to fedora-news, I know my
limitations. I don't have the capabilities, time, or means to set up
servers in the stead of infra, rewrite apps in the stead of developpers,
write articles in the stead of article writers.
There is not an army of me. There is one (overbooked). Please help.
--
Nicolas Mailhot
15 years
Re: where's the wish list for F11?
by Nicolas Mailhot
Le vendredi 21 novembre 2008 à 12:28 +0100, Dominik 'Rathann'
Mierzejewski a écrit :
> On Friday, 21 November 2008 at 11:34, Nicolas Mailhot wrote:
> > But anyway you're invited like everyone else on the list to review,
> > comment on and complete the current font packaging guideline change
> > proposal on
> > http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation
>
> It looks mostly sane (I applied some grammar and punctuation fixes, I hope
> you don't mind),
Thank you for the review and the fixes, I don't mind at all, quite the
contrary, you're very welcome. Please post any remarks you may have
about the packages themselves, that's where the long-term value is.
> but I don't like the naming of "rpm-fonts-filesystem". This
> has nothing to do with rpm itself, hence it shouldn't look like a subpackage
> of rpm. Instead, I suggest "fonts-filesystem".
I fear that by the time I had written the macros, templates, specs, wiki
pages, and all, my inspiration had quite dried out. I don't like
rpm-fonts much, but I feel fonts would be too generic a name for the
base package. If anyone has great naming ideas, I'm all ears.
--
Nicolas Mailhot
15 years
Re: where's the wish list for F11?
by Nicolas Mailhot
Le vendredi 21 novembre 2008 à 10:40 +0100, Dominik 'Rathann'
Mierzejewski a écrit :
> On Friday, 21 November 2008 at 03:07, sean darcy wrote:
> [...]
> > First, I'm a great yum fan. And you are the man. No irony or sarcasm.
> >
> > But... I use a lot of 3rd party fonts that aren't open, like most
> > designers. It's weird/strange/peculiar there's no system-config-fonts
> > that would allow us to install them.
>
> This calls for some font2spec script that'd create a spec file for your
> font and let you build a package from it easily, much like R2spec or
> cpan2rpm.
R2spec or cpan2rpm work by converting existing metadata. Raw font files
do not have the kind of metadata which could be used to generate
complete spec files. You have significant packager involvment to fill
the info that wouldn't be there otherwise.
But anyway you're invited like everyone else on the list to review,
comment on and complete the current font packaging guideline change
proposal on
http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation
--
Nicolas Mailhot
15 years
FWN article on web font surveys
by Nicolas Mailhot
Hi,
Now that:
1. Fedora 10 has a significative font complement
2. Fedora 10 has a working openjdk java plugin
3. Linux has enough market share web designers care a little about us
I'd like someone at FWN to write a simple article asking our users to
participate in the online font surveys out there on Fedora 10 release
http://fedoraproject.org/wiki/Linux_fonts_on_the_web_—
_CSS_and_font_surveys
This way we may limit the number of web sites that only work with Arial
or Times New Roman, and make more web designers aware of the fonts
actually available on free systems.
Sadly I doubt my English is simple and compelling enough for the task.
Best regards,
--
Nicolas Mailhot
15 years
conf.avail, rpmlint and the FHS
by Nicolas Mailhot
Hi all,
When conf.avail was introduced in fontconfig we at Fedora mostly ignored
it and let font packages install their fontconfig rules directly in
conf.d
http://fedoraproject.org/wiki/Packaging/FontsSpecTemplate
(the exception being the fontconfig package itself who perforce followed
the new conventions).
Recent events made me revisit this point and try to heal the rift
between fontconfig and font packages by following common conventions.
http://fedoraproject.org/wiki/PackagingDrafts/Fonts_spec_template_correct...
In the course of the examination of this guideline change proposal,
however, it was identified that conf.avail as currently designed causes
our rpmlint package sanity check tool to emit errors. Those errors were
ok for Behdad to ignore, but really not ok for general packaging
guidelines we want to put into newbie packager hands.
The core reason are that since we deploy policy through those fontconfig
files, we absolutely do not want users to change them (they're free to
un-reference the files in conf.d, or write their own fontconfig rules in
different files, but we instruct rpm to stomp on old versions of our
files on updates). Since we mark those files as non-modifiable (%config
and not %config(noreplace) in rpm speak) rpmlint considers them as data,
not configuration, and complains of their location under /etc.
After thinking a bit about it I feel rpmlint is right — since we don't
let users modify our fontconfig files they're not dynamic configuration,
just static data users can choose to activate or not.
We could of course add an exception in rpmlint just for conf.avail, but
I'd rather have fontconfig be fixed to follow more closely the FHS.
Exceptions ultimately pile on till you have a lot of cruft to clean up
which is not my definition of fun.
Can conf.avail and its contents be moved in /usr/share/something in the
next version of fontconfig?
See also:
http://fedoraproject.org/wiki/Packaging/Minutes/20081021
Regards,
--
Nicolas Mailhot
15 years