"Problems detected in the oldstandard-sfd-fonts rawhide package!"
by Ankur Sinha
On Thu, 2009-10-29 at 23:13 +0100, Nicolas Mailhot wrote:
> Dear packager,
>
> At 20091029T192211Z, while scanning the rawhide repository located at:
> http://koji.fedoraproject.org/static-repos/dist-rawhide-current/x86_64/
> I have identified the following problems in your oldstandard-sfd-fonts package:
>
> SRPM RPM 17
> oldstandard-sfd-fonts oldstandard-sfd-fonts 3
> Total 3
>
> 17. Fonts with partial script coverage
>
> ☛ Some font files included in the package are missing only a few glyphs to be
> accepted by fontconfig as covering one or several scripts. Therefore they
> could be made useful to more people with only a little effort.
>
> To check a font file script coverage, run fc-query with FC_DEBUG=256 and
> look for lines like: script-id¹(number) { list-of-unicode-codepoints }
>
> For example “mi(2) { 1e34 1e35 }” means fontconfig will accept the tested
> file for Maori if codepoints 1e34 and 1e35 are added.
>
> If you feel fontconfig is requiring a glyph which is not strictly necessary
> for a particular script, report the problem upstream².
>
> ¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
> ² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
>
> Please take the appropriate measures to fix the oldstandard-sfd-fonts package.
>
> I will warn you again if I find problems next time I am ran.
>
> Your friendly QA robot,
>
hi,
I got this email, one each for *every* font package that I maintain. I
don't exactly understand what I'm supposed to do to fix the package. Can
someone please outline the procedure?
I ran fc-query on one of the files:
[Package@Ankur gargi-1.9]$ fc-query gargi.ttf
Pattern has 20 elts (size 32)
family: "gargi"(s)
familylang: "en"(s)
style: "Medium"(s)
stylelang: "en"(s)
fullname: "gargi"(s)
fullnamelang: "en"(s)
slant: 0(i)(s)
weight: 100(i)(s)
width: 100(i)(s)
foundry: "unknown"(s)
file: "gargi.ttf"(s)
index: 0(i)(s)
outline: FcTrue(s)
scalable: FcTrue(s)
charset: 0000: 00000000 ffffffff ffffffff 7fffffff 00000000 00000000
00000000 00000000
0009: fffffffe fbffffff ff3fbfff 007fffff 00000000 00000000 00000000
00000000
0020: 77193000 00010043 00000000 00000000 00000000 00000000 00000000
00000000
0022: 00040000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
00e9: 00000000 00000000 00000000 00000700 00000000 00000000 00000000
00000000
(s)
lang: bh|bho|fj|hi|hne|ho|ia|ie|io|kj|kok|kwm|mai|mr|ms|ne|ng|nr|om|rn|
rw|sa|sn|so|ss|st|sw|ts|uz|xh|za|zu(s)
fontversion: 124518(i)(s)
capability: "otlayout:DFLT otlayout:deva"(s)
fontformat: "TrueType"(s)
decorative: FcFalse(s)
Is this what's supposed to be done? If "yes", what now? If "no", please
correct me :)
--
regards,
Ankur
14 years, 1 month
Re: "Problems detected in the oldstandard-sfd-fonts rawhide package!"
by Nicolas Mailhot
Le Sam 31 octobre 2009 11:15, Nicolas Mailhot a écrit :
>
> Le Sam 31 octobre 2009 10:57, TK009 a écrit :
>>
>> Running FC_DEBUG=256 against ns-tiza gives me a list of about 50 scripts. Is a
>> list that size normal?
>
> Many latin scripts use ASCII + one or two additional glyphs. If tiza's
author drawed basic latin (=ascii) only, I wouldn't be surprised the list
was very long.
>
> It means that Tiza could almost be used, but not quite, by a lot of people.
This is a shame. Please relay it to the font author
Of course please only relay elements of the form
foo(2) { 1e34 1e35 }
foo(0) means the coverage for foo is complete
foo(big number) means the coverage is incomplete, but you should not bother
upstream with something that needs a large effort (big number glyphs) on their
part.
--
Nicolas Mailhot
--
Nicolas Mailhot
14 years, 1 month
Re: What would be considered a fault in font encodings?
by Nicolas Mailhot
Le Ven 30 octobre 2009 16:02, Paul Flo Williams a écrit :
Welcome Paul,
And thank you for this very interesting message
> I guess I've got two fault reports to raise already, but I wanted to check
whether I'd done anything stupid in all the above, and I wondered whether
loading a font into FontForge and raising errors upstream would be part of
the normal workflow of a font packager? Are there any reports from FontForge
that are thought to be too pedantic to bother with?
Fonts are a technical/artistic object. To be honest, the technical quality of
FLOSS fonts vary wildly and some are very poor. This is due to many factors:
A. the requirements are complex and evolving
— the font standards are complex and evolving (opentype, unicode, cid tables,
etc). If one does not allocate resources to maintenance, a font file will
slowly become irrelevant, even if it was perfect to start with. But all to
often, authors release fonts as abandon-ware
— the technical environment changes: today's screens and printers are not the
same as a decade ago, the font libs have been replaced in all OSes and do not
care about the same elements as before
— font usage changes too: languages that were irrelevant before (because no
software could manage them) are now widely used, gimp/inkscape/scribus means
complex documents can now be produced by more than the small minority that can
afford Adobe prices (and can buy font collections)
B. FLOSS font authors are poorly equipped to deal with them
— many font authors have an artistic, not technical background
— many font authors still create fonts in isolation (the lone brilliant artist
myth), and therefore do not benefit from the support and structuring larger
organizations can provide
— the tooling, frankly, sucks (I believe this is also the case proprietary
side, foundries manage thanks to better organization)
C. FLOSS hackers did not help a lot. Hackers have very low font needs: code is
ASCII only, does not need scaling, does not need font effects, so a simple
bitmap monospace ascii font with a single regular face will make them happy.
Many of them do not understand to this day the complexity required to satisfy
the needs of other "normal" users. So they write countless video players or
mail apps, but very few of them even think about the text rendering part.
We do have several examples that show technically excellent complex FLOSS
fonts are possible (DejaVu, SIL fonts, etc) but they are very much the
exception.
I believe distributions could play a key role here by helping font authors to
identify the problems in their fonts, what the low hanging fruits are, what
are the conventions worth following. They should also help relay font author
wishes tooling-side, and help relay font lib writers wishes font author-side.
This is what they already routinely do for code; there is no reason they could
not do it for other technical objects such as fonts (plus they need to do it:
if we continue to rely on the GNOME Foundation, Red Hat, or Google, to buy
expensive closed fonts, and re-license them, there is no way we'll be able to
compete with desktops that include much wider font offerings by default in the
long term).
But, this is a could. Lots of work needs to be done for this to happen. We
need to identify the technical problems that need fixing. We need to write
tests to find them in fonts. We need to communicate the results to font
authors. We need to document the usual way to fix each of them.
As a first step, I've spent the last months writing an auditing script in my
free time. Yesterday I did a fist mailing based on this script.
http://git.fedorahosted.org/git/fontpackages.git?p=fontpackages.git;a=his...
It is by no means complete or perfect. There are many problems I do not test
for. Some tests (such as fontlint) are woefully inadequate: fontlint will
error on problems we do not really care about (because they're so prevalent
font libs learnt to workaround them), but only warn about metadata problems
that can be fixed easily and are inter-operability problems (how do you share
a document that references a particular font, if its name is not the same on
every system?). Fontlint will also generally forget to tell you what the
consequences of X or Y are and how one could fix it.
Still, it is way better than we had before. Before, we had nothing.
Unfortunately, the feedback so far has been negative and hostile. People who
packaged a static font blob thinking it needed no maintenance do not like
discovering it needs some. Sometimes they are aggressive because upstream
vanished and so they feel they can not do anything. Sometimes they have
problems understanding the messages the script output. It is very hard to
overcome inertia and bad habits. The current font situation is bad but doing
nothing and shooting the messenger is always an attractive proposition.
I could really use help to improve the wording of my audit messages, so they
are clearer to the people who get on in their inbox and they do not feel
aggressed by them. This seems very simple, but it is incredibly important to
get things to change.
If you are interested to make floss fonts better, and have some time to
donate, there is a lot of work to do. As you noted one first step could be to
triage fontlint output, and make it more useful. (add explanations, review
error criticity, try to output something scripts can easily be fed, etc). The
number of people working on the subject right now is really to low to make
quick progress. Any new contributor would make a huge difference.
--
Nicolas Mailhot
--
Nicolas Mailhot
14 years, 1 month
What would be considered a fault in font encodings?
by Paul Flo Williams
I'm new here, so a paragraph of introduction first. I've just dug some
fonts I created over a decade ago off some old disks and I thought I'd
find out how to publish them and use them in Fedora, which led me to the
Fonts SIG pages, and this list. So far, I've updated the first font using
FontForge, and I'm now looking at publishing it on openfontlibrary.org
before trying to package it. I've been reading the Fonts SIG pages, taking
notes on common packaging errors by reading the package reviews, and
examining existing fonts, which leads me to my first problem.
I've downloaded a load of Fedora 11 font packages and I've been examining
them in Fontmatrix, being nosy about licence and description metadata, and
I found that BrettFont's name doesn't display properly in Fontmatrix; the
"BrettFont Regular" shows up with the notdef square where the space should
be. I was wondering whether this was a fault in the font or Fontmatrix, so
I pulled brettfont.ttf into FontForge, and it spat these errors:
The glyph named space is mapped to U+00A0.
But its name indicates it should be mapped to U+0020.
The glyph named hyphen is mapped to U+00AD.
But its name indicates it should be mapped to U+002D.
The glyph named semicolon is mapped to U+037E.
But its name indicates it should be mapped to U+003B.
The glyph named Delta is mapped to U+2206.
But its name indicates it should be mapped to U+0394.
I've used ttx from fonttools to dump the font and sure enough, space is
only mapped to 0x20 in the Macintosh Roman (1,0) cmap -- in both the
Unicode (0,3) and Microsoft Unicode (3,1) cmaps, space only maps to 0xa0,
no break space.
Because I'm new to TrueType and fontconfig, I assume that BrettFont
appears to work in Inkscape because of glyph substitution.
As an aside, ttx won't dump BrettFont correctly, even with Agira Tagoh's
patch from BZ 512504, because there's another problem with the "gasp"
table.
I guess I've got two fault reports to raise already, but I wanted to check
whether I'd done anything stupid in all the above, and I wondered whether
loading a font into FontForge and raising errors upstream would be part of
the normal workflow of a font packager? Are there any reports from
FontForge that are thought to be too pedantic to bother with?
Sorry, lots of questions in one post!
Paul.
14 years, 1 month
New fontpackages releases
by Nicolas Mailhot
Dear all,
I've pushed two fontpackages releases lately.
1.28
This version is the product of a major refactoring of repo-font audit to make
it generally useful to the individual font packager. You can use it on a local
yum repo to QA your own packages before publishing them more widely. It is
also able to generate maintainer nagmails. However, no new tests were added in
this version.
1.28 is considered very stable and has been pushed to F-11. As a side-effect,
that means fontpackages-devel in F-11 is now up-to-date regarding all the
fontconfig templates written in the past 8 months (last fontpackages pushed to
F-11 was 1.20).
1.29
This version adds fontconfig script coverage and unicode block coverage tests
to repo-font-audit (any package that contains a font file that needs less than
10 glyphs to cover a new script or block will be flagged). Interestingly many
fonts fail the script coverage test while passing the unicode block one, which
seems to imply most font authors are not aware they're only missing a few
glyphs to cover more scripts, and be useful in more regions. Please relay
those failures upstream.
1.29 also adds fontlint to the test list. Since fontlint is very strict and
would reject pretty much every font in Fedora if left alone, I've used the
highly scientific method of filtering out the most common errors to limit the
test failures (on the grounds that if a large number of fonts do the same
mistakes, apps had to learn how to cope with it). If I should filter something
else, feel free to argue your case on the list. I'm not 100% sure my filtering
is perfect, just that it's good enough for a first try.
Those three new tests will flag many more font files than previously, so
expect new error reports. The coverage tests should be pretty solid. I'm less
sure about fontlint. However, since after filtering fonts fail fontlint for
many different reasons, I'm afraid those are real bugs and reflect poor FLOSS
font QA (SIL fonts pass fontlint with colors, so it is achievable).
1.29 has been pushed to F-12 and devel. It will be used in the next rawhide
test run (probably by the end of the month).
--
Nicolas Mailhot
14 years, 1 month
