Comments from a distribution packager

Sun Nov 4 11:09:14 UTC 2007

Dear sir,

I'm writing to you on behalf of Fedora Linux, where I've just pushed the
STIX beta fonts:
http://koji.fedoraproject.org/koji/packageinfo?packageID=5222

Fedora packages may later be re-used by Red Hat Enterprise Linux, the
OLPC project, or others.

My comments will therefore mostly focus on the font distribution
process, comments on the glyphs themselves will have to wait till the
fonts actually reach our users.

Anyway, here are the changes that would have made my task easier, and
which I hope you'll implement next version (due to the fact every Linux
distribution follows the same general model, I expect you'll hear
similar remarks from other distributors).

1. Please use a standard license such as SIL's OFL. 

Standard licenses have already been cross-checked for ambiguities by
third parties, are on pre-approved legal department lists, etc. 

Due to the very short beta period STIX announced we've tentatively
approved your custom license so fonts have the time to reach testers
before December 15. This approval hinges on our reading of § 4. as "a.
you may add glyphs to our font, b. or delete them, including in the base
range, provided you add the following disclaimer".

We've since learnt Debian reads this part differently. If the Debian
interpretation was confirmed, we'd remove STIX from our repository. We
refuse to distribute fonts that forbid modifications.

It is very unfortunate such legal problems may prevent a lot of people
from being able to check your fonts during your beta period. But
nowadays digital redistribution requires getting legalities right.

Also license mismatch is a huge impediment to cross-pollinating between
free/libre font projects. We strongly advice any project wishing to have
its fonts distributed to our users long-term to use a standard license.

Our font legal policy is published there:
http://fedoraproject.org/wiki/SIGs/Fonts/Legal

2. Please include your license as a .txt file in your release .zip.

We'll redistribute your material so our users do not need to go through
your web site (indeed the major added value of a distribution is users
do not need to comb the internet to assemble a working system). That
means our users won't be exposed to your click-through page.

We could of course make a copy of your web page and distribute it with
the fonts. However that would expose us to unpleasant consequences
should you change this page without us noticing. Our policy is therefore
to only redistribute license texts included by upstream projects (that's
you) in their archive files.

http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#LicenseText

As I suppose you want every STIX user to have easy access to your
licensing terms to avoid infringing them, you should add the license
itself to your .zip file.

3. Please allow direct download of your font archives without requiring
a click-through

We have audit scripts that periodically check the archive files we
create our packages from are the same as the ones upstream projects
released. If a project does not allow direct download of its archive
files, those audit scripts can't perform their job.

4. Please use ascending numeric versions only, not strings like "beta"

Linux packaging systems perform automated updates of installed
components on user systems. To decide if a component needs to be
updated, they compare component versions. This only works if versions
can be compared by an automated process, following a logical order.

I had to rechristen your beta version 0.9. That means the next one will
have to be 1.0 or 0.9.1. Such a rechristening is always dangerous since
if our versioning significantly diverges from upstream, users can not
easily check if Fedora carries the latest upstream version.

The contorsions we have to go through in case of non-numeric versioning
are described there
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#PackageVersion

In the future, please make your distributors' life easier and adopt a
strictly numeric versioning.

5. Please use usual archive naming conventions

Version XX of project foo should be released in a foo-XX.zip (or
tar.bz2) archive with a top-level foo-XX directory inside. (We can
workaround this but again that's more work to us and not nice)

6. Please use spaces in internal font names

Every decent software written in the past years has been tested to work
with "Times New Roman". There is no reason to adopt user-hostile names
like "STIXGeneral"

In a general-purpose distribution context such as ours not impeding the
rest of the system takes precedence over the functionality every
individual component adds. Font lists are precious screen-estate shared
by many applications. If users complain because STIX fills their font
lists with ugly names they don't see the need for, we won't mark STIX as
a default package.

7. Please simplify your font distribution

For that reason I've spun out non-base fonts in optional packages and I
don't expect many users to install them. That's a pity because obviously
a lot of work went out in those fonts but your current font layout is
just too font-list-hungry to be acceptable as-is.

(http://koji.fedoraproject.org/koji/buildinfo?buildID=23155)

Also your readme does not explain clearly what all the size variations
are needed for in a scalable fonts world. They seem to require software
tailored around STIX to be used by normal users.

You may consider playing font name tricks so installing your fonts do
not add so many new font names in application font lists.

8. Please provide fontconfig rules

Modern *nix systems use fontconfig to determine when one font should be
substituted to another. Your complex font layout obviously demands
complex substitution rules dumb packagers like me are not going to get
right alone.

I've written some rules for the Fedora packages
http://cvs.fedoraproject.org/viewcvs/devel/stix-fonts/

but they probably do not match what you intended.

9. OTF is still not perfectly supported by popular software like
OpenOffice.org (including its math component). I strongly advice you to
plead your cause to the project so users can choose STIX confidently in
the near future.
http://qa.openoffice.org/issues/show_bug.cgi?id=16032
http://qa.openoffice.org/issues/show_bug.cgi?id=43029
http://qa.openoffice.org/issues/show_bug.cgi?id=79878

10. On a personal note, I find STIX metrics too small to be used
comfortably on a computer screen. Modern computer fonts (and even
not-so-modern ones like "Times New Roman") use a fatter more rounded
style for this reason. I doubt current stix will ever be a popular
browser font for this reason (at least till computer screens improve
their pixel density considerably).

11. Since STIXGeneral is mostly a serif font, I suggest you work with
free/libre projects like DejaVu (dejavu.sf.net) to complete the
scientific symbol coverage of their sans-serif fonts. 

DejaVu Sans already includes a large scientific glyph coverage and for
this reason is a preferred font of our scientific users. Completing the
DejaVu Sans font will be easier than creating a new sans-serif font from
scratch. Additionally DejaVu Sans is a nice screen font whereas
STIXGeneral is not shinning there so far, and the DejaVu project has
very successfully engaged distributors like us, these people know what
our needs are and how to get widely redistributed.

I'm not sure mixing serif and sans-serif symbol in a single font like
STIX does will prove popular with users mid-term.

I'll stop there, and hope this feedback will help the STIX project to
attain its objective of creating good font support for every scientific
and engineering user. Your efforts are appreciated. Thanks.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-fonts-list/attachments/20071104/58a3e6fa/attachment.sig>