fonts November 2007

fonts@lists.fedoraproject.org

11 participants
61 discussions

[Fwd: Font issues (mkfontdir & friends not getting run) with F-8]
by Nicolas Mailhot 16 Nov '07

16 Nov '07

Forwarding to the right list (not that the two example package follow the provisional guidelines on the fontconfig front, and I don't care much about the core font side myself) -------- Message transféré -------- De: Hans de Goede <j.w.r.degoede(a)hhs.nl> Hi On both my F-8 x86_64 live-dvd installation and my (clean) F-8 i386 install dvd installation, not all scriptlets for font-packages have properly run. Taking /etc/X11/fontpath.d/fonts-default (urw-fonts) as example: -On the x86_64 live dvd install, only fonts.scale is present, iow mkfontdir and fc-cache have not been run, even though they are in the scripts: [hans@localhost ~]$ rpm -q --scripts urw-fonts urw-fonts-2.4-1.fc8.noarch postinstall scriptlet (using /bin/sh): { umask 133 mkfontscale /usr/share/fonts/default/Type1 || : `which mkfontdir` /usr/share/fonts/default/Type1 || : fc-cache /usr/share/fonts } &> /dev/null || : -On the i386 dvd install, nothing was run, so not only mkfontdir and fc-cache were not run, but also mkfontscale has not been run The strange thing is fontconfig is actually required, so atleast the fc-cache file should have been created. As for the other two not being created, well that is to be expected if the necessary packages are not added to any Requires. Why are these files generated on install anyways, I understand this used to be usefull back in the days when multiple packages would install files under one dir, but isn't it so that most font dirs now only contain fonts from one package? Note that this is not isolated to urw-fonts, ghostscript-fonts for example has the same problem. Regards, Hans -- Nicolas Mailhot

2 1

Identifying text rendering problems
by Ben Laenen 12 Nov '07

12 Nov '07

[sorry if you all get this mail two times, Nicolas asked me to resend it because he thought some problems may have occurred with the delivery of my first attempt] Hi all, I've written up a bit of text to help with point 8 on the http://fedoraproject.org/wiki/SIGs/Fonts/Todo page given our experience with DejaVu. Finding out what is causing text rendering issues may be quite hard to describe, especially since we never follow some certain pattern to get to what the problem is with the bugs we get reported with DejaVu. It's usually just experience with what problems are related to certain issues that immediately tells us what's wrong. Furthermore, the variety of possible text rendering problems is very big. Nevertheless, I've tried to compose some summary here describing what could go wrong. Just keep in mind that I've certainly not covered all issues here. I'll only address issues here which one could encounter with normal opentype truetype fonts (ttf). For opentype fonts with CFF outlines (otf) this will probably be somewhat the same, except that all BCI or autohinting issues should be discarded here, and replaced by postscript hinting issues. Bitmap fonts probably have their own issues, I'm not looking at those here. Also, I'm aware Fedora doesn't enable the BCI in FreeType by default, but many users do enable it, so I'm not discarding the issues of BCI hinting here. Most of the bugs reported to us btw relate to bad autohinting, so it's usually the first thing we will test. Final note: I don't take subpixel hinting into account here. It's possible that some issues occur only when subpixel hinting is enabled, but I don't think we ever got reports for those (and I still use an old CRT screen, so I don't use subpixel hinting myself) I would say there are three kind of bug reports we get: 1 a certain glyph looks bad 2 glyphs are placed incorrectly 3 user preference issues so let's see how we handle these. 1. a certain glyph looks bad Caveat: is the user sure he sees the font he reports an error for. Font substitution could be at work and he may look at a completely different font which has a bad glyph. Suppose the shape of a glyph looks bad. Again, there are two categories here: 1.a the shape is just wrong This means the font should be fix the shape. 1.b the glyph looks bad at specific font sizes This is where we try to determine whether the user who reports the error is using the autohinter, or the bytecode interpreter (BCI). We made life a bit easier in DejaVu by adding the glyphs U+F000 and U+F001 in Sans, which show 88 when the BCI isn't used (i.e. he is using the autohinter) and the font pixel size when BCI is enabled. If the user uses the autohinter, it is most likely a autohinter problem and the problem should be reported to FreeType. If the user uses BCI, the font has bad hinting instructions for the glyph and the font needs to fix it. It's also possible that the BCI of the renderer is buggy. In reporting the bug to the font, it's important to tell them the pixel size (not point size, because that's variable on dpi settings). As said before, for DejaVu the U+F000 and U+F001 give the pixel sizes. 1.c a glyph looks too fuzzy compared with other glyph The user probably has BCI enabled and is using a glyph from a font which doesn't have that glyph hinted. Solution: persuade the font authors to hint the specific glyph. 2. glyphs are placed incorrectly Again, many different possible issues here: 2.a bad spacing between glyphs Test out if the spacing is still bad at very big font sizes. If it is: the font probably has bad bearings (space between the glyph outlines and the glyph boundaries) for a specific glyph. The font could also have bad kerning. If the spacing is nice at big font sizes or when it only happens at specific sizes, it's again likely a autohinter or hinting bug. See 1.b 2.b accents are badly placed (for precomposed glyphs) Again, test out for big font sizes have the issue as well. If it looks bad as well then, the font has the accent badly placed in the precomposed glyph. If it looks bad at only specific sizes, the font maybe need to adjust the accent with hinting, or autohinting is placing it incorrectly. Also see 1.b 2.c combining diacritics are badly placed on base glyphs First question to answer: does the user have a renderer which can properly handle anchors (Pango, Qt4) or not. If he doesn't (Qt3 for Latin for example), then there's not much to do, except to convince the people in charge of the renderer to support it (in case of Latin in Qt3 it probably won't happen since new versions of Qt4 handle them). If the renderer can handle anchor placement, some things can be wrong: - The font may have bad anchor placement - The font has no anchors at all (or it has no anchors for that specific base glyph - mark combination (but in that case the renderer should have some fall-back option for default placement. Qt4 has it, Pango IIRC not, but it may have changed by now with Harfbuzz) Other issues which could relate to a renderer problem or a font problem: - Diacritics on wrong part of ligature (could be an anchor issue in the font, or a renderer problem) - "Extreme diacritic testing" (read: not many users do that), i.e. one or more base glyph with a big amount of diacritical marks, or with special marks like CGJ (combining grapheme joiner) (again, could be a anchor issue, but if the font handles normal cases nicely it's likely that the renderer will get confused or isn't build to handle the specific string with CGJ) 3. User preference issues These usually aren't bugs, but do get reported from time to time, so I put this section here anyway. - Font looks fuzzy overall (sometimes reported as: too thick; or sometimes also: fonts are too sharp, usually reported as: too thin): The user should play with hinting settings and preferably enable BCI when he finds the fonts too fuzzy (patent issues aside). The autohinter sometimes doesn't make the glyphs sharp enough. Also, is the font hinted? If not, then he should try to get autohinting enabled only for that font (todo: look up some fonts.conf for that...). When the font isn't fuzzy enough (i.e. too sharp) BCI is probably not something the user wants, and he may want to try out several settings of the autohinter, or no hinting at all. Depending on the platform he uses (KDE, Gnome...), give the user fonts.conf configurations, or direct him to the proper dialogs to get the fonts to the way he likes them best. - Fonts are bitmapped/aliased, which looks bad; or: fonts are bitmapped, and I want them to, but they look very bad. If the user doesn't want bitmapped fonts, it's easy: just enable antialiasing. If he wants bitmapped fonts but they look bad: the amount of fonts made to look nice bitmapped are very few (the old MS corefonts for example, but making fonts like this has the oddity that it will sometimes have bad hinting when antialiasing is enabled), so usually the bad look is to expect. If the user uses one of the corefonts for example and they look bad, he probably makes use of the autohinter, since these fonts will also look nicely as bitmaps only when BCI is enabled.

2 1

[Fwd: Identifying text rendering problems]
by Nicolas Mailhot 11 Nov '07

11 Nov '07

[Third attempt since it seems not to reach the list at all] -------- Message transféré -------- De: Ben Laenen Sujet: Identifying text rendering problems [sorry if you all get this mail two times, Nicolas asked me to resend it because he thought some problems may have occurred with the delivery of my first attempt] Hi all, I've written up a bit of text to help with point 8 on the http://fedoraproject.org/wiki/SIGs/Fonts/Todo page given our experience with DejaVu. Finding out what is causing text rendering issues may be quite hard to describe, especially since we never follow some certain pattern to get to what the problem is with the bugs we get reported with DejaVu. It's usually just experience with what problems are related to certain issues that immediately tells us what's wrong. Furthermore, the variety of possible text rendering problems is very big. Nevertheless, I've tried to compose some summary here describing what could go wrong. Just keep in mind that I've certainly not covered all issues here. I'll only address issues here which one could encounter with normal opentype truetype fonts (ttf). For opentype fonts with CFF outlines (otf) this will probably be somewhat the same, except that all BCI or autohinting issues should be discarded here, and replaced by postscript hinting issues. Bitmap fonts probably have their own issues, I'm not looking at those here. Also, I'm aware Fedora doesn't enable the BCI in FreeType by default, but many users do enable it, so I'm not discarding the issues of BCI hinting here. Most of the bugs reported to us btw relate to bad autohinting, so it's usually the first thing we will test. Final note: I don't take subpixel hinting into account here. It's possible that some issues occur only when subpixel hinting is enabled, but I don't think we ever got reports for those (and I still use an old CRT screen, so I don't use subpixel hinting myself) I would say there are three kind of bug reports we get: 1 a certain glyph looks bad 2 glyphs are placed incorrectly 3 user preference issues so let's see how we handle these. 1. a certain glyph looks bad Caveat: is the user sure he sees the font he reports an error for. Font substitution could be at work and he may look at a completely different font which has a bad glyph. Suppose the shape of a glyph looks bad. Again, there are two categories here: 1.a the shape is just wrong This means the font should be fix the shape. 1.b the glyph looks bad at specific font sizes This is where we try to determine whether the user who reports the error is using the autohinter, or the bytecode interpreter (BCI). We made life a bit easier in DejaVu by adding the glyphs U+F000 and U+F001 in Sans, which show 88 when the BCI isn't used (i.e. he is using the autohinter) and the font pixel size when BCI is enabled. If the user uses the autohinter, it is most likely a autohinter problem and the problem should be reported to FreeType. If the user uses BCI, the font has bad hinting instructions for the glyph and the font needs to fix it. It's also possible that the BCI of the renderer is buggy. In reporting the bug to the font, it's important to tell them the pixel size (not point size, because that's variable on dpi settings). As said before, for DejaVu the U+F000 and U+F001 give the pixel sizes. 1.c a glyph looks too fuzzy compared with other glyph The user probably has BCI enabled and is using a glyph from a font which doesn't have that glyph hinted. Solution: persuade the font authors to hint the specific glyph. 2. glyphs are placed incorrectly Again, many different possible issues here: 2.a bad spacing between glyphs Test out if the spacing is still bad at very big font sizes. If it is: the font probably has bad bearings (space between the glyph outlines and the glyph boundaries) for a specific glyph. The font could also have bad kerning. If the spacing is nice at big font sizes or when it only happens at specific sizes, it's again likely a autohinter or hinting bug. See 1.b 2.b accents are badly placed (for precomposed glyphs) Again, test out for big font sizes have the issue as well. If it looks bad as well then, the font has the accent badly placed in the precomposed glyph. If it looks bad at only specific sizes, the font maybe need to adjust the accent with hinting, or autohinting is placing it incorrectly. Also see 1.b 2.c combining diacritics are badly placed on base glyphs First question to answer: does the user have a renderer which can properly handle anchors (Pango, Qt4) or not. If he doesn't (Qt3 for Latin for example), then there's not much to do, except to convince the people in charge of the renderer to support it (in case of Latin in Qt3 it probably won't happen since new versions of Qt4 handle them). If the renderer can handle anchor placement, some things can be wrong: - The font may have bad anchor placement - The font has no anchors at all (or it has no anchors for that specific base glyph - mark combination (but in that case the renderer should have some fall-back option for default placement. Qt4 has it, Pango IIRC not, but it may have changed by now with Harfbuzz) Other issues which could relate to a renderer problem or a font problem: - Diacritics on wrong part of ligature (could be an anchor issue in the font, or a renderer problem) - "Extreme diacritic testing" (read: not many users do that), i.e. one or more base glyph with a big amount of diacritical marks, or with special marks like CGJ (combining grapheme joiner) (again, could be a anchor issue, but if the font handles normal cases nicely it's likely that the renderer will get confused or isn't build to handle the specific string with CGJ) 3. User preference issues These usually aren't bugs, but do get reported from time to time, so I put this section here anyway. - Font looks fuzzy overall (sometimes reported as: too thick; or sometimes also: fonts are too sharp, usually reported as: too thin): The user should play with hinting settings and preferably enable BCI when he finds the fonts too fuzzy (patent issues aside). The autohinter sometimes doesn't make the glyphs sharp enough. Also, is the font hinted? If not, then he should try to get autohinting enabled only for that font (todo: look up some fonts.conf for that...). When the font isn't fuzzy enough (i.e. too sharp) BCI is probably not something the user wants, and he may want to try out several settings of the autohinter, or no hinting at all. Depending on the platform he uses (KDE, Gnome...), give the user fonts.conf configurations, or direct him to the proper dialogs to get the fonts to the way he likes them best. - Fonts are bitmapped/aliased, which looks bad; or: fonts are bitmapped, and I want them to, but they look very bad. If the user doesn't want bitmapped fonts, it's easy: just enable antialiasing. If he wants bitmapped fonts but they look bad: the amount of fonts made to look nice bitmapped are very few (the old MS corefonts for example, but making fonts like this has the oddity that it will sometimes have bad hinting when antialiasing is enabled), so usually the bad look is to expect. If the user uses one of the corefonts for example and they look bad, he probably makes use of the autohinter, since these fonts will also look nicely as bitmaps only when BCI is enabled. -- Nicolas Mailhot

1 0

Identifying text rendering problems
by Ben Laenen 11 Nov '07

11 Nov '07

Hi all, I've written up a bit of text to help with point 8 on the http://fedoraproject.org/wiki/SIGs/Fonts/Todo page given our experience with DejaVu. Finding out what is causing text rendering issues may be quite hard to describe, especially since we never follow some certain pattern to get to what the problem is with the bugs we get reported with DejaVu. It's usually just experience with what problems are related to certain issues that immediately tells us what's wrong. Furthermore, the variety of possible text rendering problems is very big. Nevertheless, I've tried to compose some summary here describing what could go wrong. Just keep in mind that I've certainly not covered all issues here. I'll only address issues here which one could encounter with normal opentype truetype fonts (ttf). For opentype fonts with CFF outlines (otf) this will probably be somewhat the same, except that all BCI or autohinting issues should be discarded here, and replaced by postscript hinting issues. Bitmap fonts probably have their own issues, I'm not looking at those here. Also, I'm aware Fedora doesn't enable the BCI in FreeType by default, but many users do enable it, so I'm not discarding the issues of BCI hinting here. Most of the bugs reported to us btw relate to bad autohinting, so it's usually the first thing we will test. Final note: I don't take subpixel hinting into account here. It's possible that some issues occur only when subpixel hinting is enabled, but I don't think we ever got reports for those (and I still use an old CRT screen, so I don't use subpixel hinting myself) I would say there are three kind of bug reports we get: 1 a certain glyph looks bad 2 glyphs are placed incorrectly 3 user preference issues so let's see how we handle these. 1. a certain glyph looks bad Caveat: is the user sure he sees the font he reports an error for. Font substitution could be at work and he may look at a completely different font which has a bad glyph. Suppose the shape of a glyph looks bad. Again, there are two categories here: 1.a the shape is just wrong This means the font should be fix the shape. 1.b the glyph looks bad at specific font sizes This is where we try to determine whether the user who reports the error is using the autohinter, or the bytecode interpreter (BCI). We made life a bit easier in DejaVu by adding the glyphs U+F000 and U+F001 in Sans, which show 88 when the BCI isn't used (i.e. he is using the autohinter) and the font pixel size when BCI is enabled. If the user uses the autohinter, it is most likely a autohinter problem and the problem should be reported to FreeType. If the user uses BCI, the font has bad hinting instructions for the glyph and the font needs to fix it. It's also possible that the BCI of the renderer is buggy. In reporting the bug to the font, it's important to tell them the pixel size (not point size, because that's variable on dpi settings). As said before, for DejaVu the U+F000 and U+F001 give the pixel sizes. 1.c a glyph looks too fuzzy compared with other glyph The user probably has BCI enabled and is using a glyph from a font which doesn't have that glyph hinted. Solution: persuade the font authors to hint the specific glyph. 2. glyphs are placed incorrectly Again, many different possible issues here: 2.a bad spacing between glyphs Test out if the spacing is still bad at very big font sizes. If it is: the font probably has bad bearings (space between the glyph outlines and the glyph boundaries) for a specific glyph. The font could also have bad kerning. If the spacing is nice at big font sizes or when it only happens at specific sizes, it's again likely a autohinter or hinting bug. See 1.b 2.b accents are badly placed (for precomposed glyphs) Again, test out for big font sizes have the issue as well. If it looks bad as well then, the font has the accent badly placed in the precomposed glyph. If it looks bad at only specific sizes, the font maybe need to adjust the accent with hinting, or autohinting is placing it incorrectly. Also see 1.b 2.c combining diacritics are badly placed on base glyphs First question to answer: does the user have a renderer which can properly handle anchors (Pango, Qt4) or not. If he doesn't (Qt3 for Latin for example), then there's not much to do, except to convince the people in charge of the renderer to support it (in case of Latin in Qt3 it probably won't happen since new versions of Qt4 handle them). If the renderer can handle anchor placement, some things can be wrong: - The font may have bad anchor placement - The font has no anchors at all (or it has no anchors for that specific base glyph - mark combination (but in that case the renderer should have some fall-back option for default placement. Qt4 has it, Pango IIRC not, but it may have changed by now with Harfbuzz) Other issues which could relate to a renderer problem or a font problem: - Diacritics on wrong part of ligature (could be an anchor issue in the font, or a renderer problem) - "Extreme diacritic testing" (read: not many users do that), i.e. one or more base glyph with a big amount of diacritical marks, or with special marks like CGJ (combining grapheme joiner) (again, could be a anchor issue, but if the font handles normal cases nicely it's likely that the renderer will get confused or isn't build to handle the specific string with CGJ) 3. User preference issues These usually aren't bugs, but do get reported from time to time, so I put this section here anyway. - Font looks fuzzy overall (sometimes reported as: too thick; or sometimes also: fonts are too sharp, usually reported as: too thin): The user should play with hinting settings and preferably enable BCI when he finds the fonts too fuzzy (patent issues aside). The autohinter sometimes doesn't make the glyphs sharp enough. Also, is the font hinted? If not, then he should try to get autohinting enabled only for that font (todo: look up some fonts.conf for that...). When the font isn't fuzzy enough (i.e. too sharp) BCI is probably not something the user wants, and he may want to try out several settings of the autohinter, or no hinting at all. Depending on the platform he uses (KDE, Gnome...), give the user fonts.conf configurations, or direct him to the proper dialogs to get the fonts to the way he likes them best. - Fonts are bitmapped/aliased, which looks bad; or: fonts are bitmapped, and I want them to, but they look very bad. If the user doesn't want bitmapped fonts, it's easy: just enable antialiasing. If he wants bitmapped fonts but they look bad: the amount of fonts made to look nice bitmapped are very few (the old MS corefonts for example, but making fonts like this has the oddity that it will sometimes have bad hinting when antialiasing is enabled), so usually the bad look is to expect. If the user uses one of the corefonts for example and they look bad, he probably makes use of the autohinter, since these fonts will also look nicely as bitmaps only when BCI is enabled.

1 0

Re: [Fontconfig] Announcing Fontconfig 2.4.92 (2.5 RC2)
by Nicolas Mailhot 07 Nov '07

07 Nov '07

Le Mer 7 novembre 2007 11:46, Frederic Crozat a écrit : > for serif and sans-serif, we are favoring DejaVu over Bitstream Vera > (since Vera is not changing anymore, unlike DejaVu which is also > changing for latin glyphs). Should we do the same upstream ? I've pushed upstream (@dejavu) the fontconfig files we use to achieve this effect @fedora. If the fonconfig maintainers stance on Dejavu changed they could be moved to fontconfig. Last time the issue vas discussed there was some opposition to preferring dejavu at the fontconfig level. Also I rather prefer distributed policy in separate files, since that means they're only deployed if the font packages themselves are installed on the system (instead of mucking with .avail symlinks, and trying to manage a centralised policy everyone patches anyway). > Related question : we are favoring free fonts (also because we aren't > enabling patented bytecode interpreter) over MS fonts, by pushing Luxi > and Nimbus over Verdana and Arial (or Andale Mono, Courier New). We're dropping Luxi @fedora since the license forbids modification and you have alternatives with more liberal licenses available nowadays. Regards, -- Nicolas Mailhot

1 0

Looking for help
by Orion Poplawski 07 Nov '07

07 Nov '07

I've acquired a moderately large stable of packages that is starting to consume too much of my time. I'm looking for people interested in either taking over (preferrable) or co-maintaining the freefont -- Free UCS Outline Fonts package. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion(a)cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com

1 0

Comments from a distribution packager
by Nicolas Mailhot 04 Nov '07

04 Nov '07

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

1 0

[Fedora-fonts-list] STIX fonts in, Conakry fonts awaiting a packager
by Nicolas Mailhot 03 Nov '07

03 Nov '07

Hi all, A major free/libre font project, STIX, did its first public release yesterday. It's a huge work – the project timeline starts in 1995. The result are engineering and scientific fonts: latin + greek + cyrillic + a lot of technical glyphs, in serif. The STIX fonts have been packaged and approved, and should be available as Fedora 8 updates and in Fedora devel. http://koji.fedoraproject.org/koji/packageinfo?packageID=5222 Everyone interested please test and report upstream (http://www.stixfonts.org/betafeedback.html) Upstream beta period ends on december, 15 and it will be much harder to request fixes after this date. In other news a new OFL font has been requested by African users and added to packaging wishes in http://fedoraproject.org/wiki/SIGs/Fonts/Triaging/Pipeline#wishes Would-be packagers are demanded. Regards, -- Nicolas Mailhot

1 1

Fonts SIG status and todo list
by Nicolas Mailhot 03 Nov '07

03 Nov '07

Hi all, To help the numerous volunteers who are dying to contribute to the SIG, but wonder what still needs to be done, I've added a todo page to the wiki space: http://fedoraproject.org/wiki/SIGs/Fonts/Todo If you feel you can contribute to one task, just put your name in the driver column. Likewise if you feel I forgot something important the SIG needs to get done, just add an entry to the table. Regards, -- Nicolas Mailhot

1 0

Re: [Fedora-packaging] Re: [Fedora-fonts-list] Fonts spec template validation
by Nicolas Mailhot 03 Nov '07

03 Nov '07

Le samedi 03 novembre 2007 à 12:13 +0100, Patrice Dumas a écrit : > > Please get together and write guidelines for legacy font packaging (with > > scriptlets you actually understand). I've wrote it before and write it > > here again: I have zip interest in legacy fonts. I recognise it's font > > I am not asking you to do anything, nor I am asking anything to anybody. > I am well aware that everything in Fedora is volunteer. Well, *I* am asking because having legacy font packagers ask me the same questions all the time is getting old fast. You people chose to package legacy fonts. You get together to write your own policy (or heed the "don't do it" advice of people like Behdad and me). > However, when > there is something unclear or even that seems incorrect in the wiki, > I have to raise the issue. > > > stuff some Fedora users need, so the Fonts SIG wiki will host any > > properly-written legacy fonts policy. But I won't write it for you. I've > > I didn't asked that. I said that because it seems confusing to me to > write things like > mkfontdir, xfs, "cannot find default font 'fixed'", > when it is not of any relevance in the latest fedora version. I've tried to add even more keywords so people recognise the thing. It's difficult to point to it when most people do not know the official name, and nicknames vary from one person to the other. -- Nicolas Mailhot

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts November 2007