Font problems (affecting Java and others?)

[Michael Stone]

>    Thanks for the suggestions.  So is all RPM packaging done by the Red
>Hat team?  

OLPC and some of its friends help maintain several packages important to
OLPC in Fedora. RedHat employees assist other Fedora volunteers in the
same task. (Understand that Fedora and RedHat are related but distinct;
think of Fedora as "the community-owned distro from which RedHat pulls
packages it likes".)

> Do we have any control about what shows up in those
>repositories?  

Yes. A moderate number of packages have OLPC-specific forks inside the
Fedora build system and a smaller number have OLPC-specific forks
outside of that build-system.

> That is, if we have a patch specific to the OLPC, are we
> dependent on Red Hat to approve/reject it and get it incorporated?

Ultimately no, though in practice, we negotiate constantly with other
Fedora maintainers because forks are expensive to maintain.

>    1.)  Is the OLPC expected to contain at least one font containing a
>glyph for all Unicode characters?  Right now, I'm not sure we even have
>one complete font, even if we pick and choose between fonts.

Fonts (and other localization data) can be very big and we are very
pressed for space. We would rather improve our customization technology
to encompass fonts so that individual deployments can more easily choose
the fonts which are appropriate for them.

>    It would seem that a world-friendly OS should contain at least one
>font with glyphs for the majority of Unicode codepoints, or at least a
>bunch of fonts that can be searched for a glyph.  This affects language
>learning and makes or breaks applications.

Given network access, can such fonts be pulled on-demand based on need?

>    2.) If internationalized applications like Java or GTK or Browse
>have pointers to font files that are missing, is it considered an OLPC
>bug that we forgot to distribute those files?  Or considered a bug in
>that Java distribution that needs to point at the fonts we already have?

No policy exists. Can you suggest some of the pro's and con's you see in
each approach?

>  What if they're incomplete?  Or is it a space-saving consideration?
>Or a free font availability consideration?  

All of the above plus inconsistent testing.

> If it's one of the latter, do we declare that we won't fully
> internationalize so platforms like Java and internationalized
> applications (like Browse) will be forever broken?

No, we declare that we need help from the outside world in order to
qualify a release X for locale Y, we hit up friends we know who care about
locale Y, we seek out new friends, and, if necessary, we negotiate the
qualification of a release for locale Y individually as a part of
appropriate deployment contracts.

By "qualify release X for locale Y", I mean the stuff described at

   http://wiki.laptop.org/go/User:Mstone/Notes/Localization_1

Please help me extend that list if I've missed anything.

> 3.) Should it be considered a bug if an existing, central
>application like Browse or Firefox can't find a glyph for many Unicode
>codepoints, and thus fails to display many languages?

Certainly, though it may not be a very high priority one for _OLPC_ to
fix. (Our software is free; other people are welcome and encouraged to
fix bugs which matter to them regardless of OLPC's priorities.)

> Or do we just ship the fonts most used in our customer countries?
> (The latter seems a bit cynical... :) )

We have a scarce physical resource -- NAND flash -- to try to economize.
Consequently, we try to ship something like "the things we consider to
necessary to implement our educational vision plus a few other things to
help meet other demonstrated deployment needs". As I suggested before,
better customization technology would be welcome.

>    By the way, I've made a major rewrite to the Java page of the Wiki,
>hoping to bring it up to date, and provide links to Java-blocking bugs,
>Java issues, benefits of Java, and my own research into improving Java
>footprint and usability.  Updates or discussion are highly welcomed.
>See http://wiki.laptop.org/go/Java

Thanks!

Michael