[Fwd: Font issues (mkfontdir & friends not getting run) with F-8]
by Nicolas Mailhot
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
16 years, 5 months
Identifying text rendering problems
by Ben Laenen
[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.
16 years, 5 months
[Fwd: Identifying text rendering problems]
by Nicolas Mailhot
[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
16 years, 5 months
Identifying text rendering problems
by Ben Laenen
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.
16 years, 5 months
Re: [Fontconfig] Announcing Fontconfig 2.4.92 (2.5 RC2)
by Nicolas Mailhot
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
16 years, 5 months
Looking for help
by Orion Poplawski
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
16 years, 5 months
Comments from a distribution packager
by Nicolas Mailhot
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
16 years, 5 months
Fonts SIG status and todo list
by Nicolas Mailhot
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
16 years, 5 months
Re: [Fedora-packaging] Re: [Fedora-fonts-list] Fonts spec template validation
by Nicolas Mailhot
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
16 years, 5 months
