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
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
_______________________________________________ Fedora-fonts-list mailing list Fedora-fonts-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-fonts-list
