fonts October 2009

fonts@lists.fedoraproject.org

14 participants
19 discussions

New audit messages
by Nicolas Mailhot 31 Oct '09

31 Oct '09

Hi all, I did what I could based on current feedback to improve the audit messages and make them clearer and less threatening. If you didn't feel comfortable with the previous version, please check the new text and tell me what you think about it (what you don't like, suggestions to make it better, patches, etc http://git.fedorahosted.org/git/fontpackages.git?p=fontpackages.git;a=blob;… -- Nicolas Mailhot

1 0

"Problems detected in the oldstandard-sfd-fonts rawhide package!"
by Ankur Sinha 31 Oct '09

31 Oct '09

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

3 5

Re: "Problems detected in the oldstandard-sfd-fonts rawhide package!"
by Nicolas Mailhot 31 Oct '09

31 Oct '09

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

1 0

Re: What would be considered a fault in font encodings?
by Nicolas Mailhot 30 Oct '09

30 Oct '09

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=histo… 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

1 0

What would be considered a fault in font encodings?
by Paul Flo Williams 30 Oct '09

30 Oct '09

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.

1 0

New fontpackages releases
by Nicolas Mailhot 27 Oct '09

27 Oct '09

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

1 0

Web Open Font Format for Firefox 3.6
by Rahul Sundaram 26 Oct '09

26 Oct '09

Hi, Just FYI, http://hacks.mozilla.org/2009/10/woff/ Rahul

1 0

Hello and Tiza Fonts packaged for review
by TK009 25 Oct '09

25 Oct '09

Hello everyone, Nevermind the name in the email =), my name is Edward (irc tk009). I have packaged the NS Tiza font: https://fedoraproject.org/wiki/NS_Tiza_fonts and created a Review Request: https://bugzilla.redhat.com/show_bug.cgi?id=530880 Please go easy on the new guy =) Edward

1 0

SIL Scheherazade font is now in Fedora
by Hedayat Vatankhah 19 Oct '09

19 Oct '09

Hi all, The packaging process of SIL Scheherazade font (http://fedoraproject.org/wiki/SIL_Scheherazade_fonts) is now completed and it is going to the living phase! :) Also, SIL Lateef font will finish the birth phase soon and go to the living phase. Good luck, Hedayat

1 0

Font package review request for AnonymousPro
by Robin Sonefors 15 Oct '09

15 Oct '09

Hi After reading Mairin's Unpackaged Font of the Week post yesterday, I decided to try packaging it. The result is a review request at https://bugzilla.redhat.com/show_bug.cgi?id=529196 I've never done RPM packages before, so realistically there should be some mistakes. I'd be thankful for having those pointed out to me. Thanks, Robin Sonefors

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts October 2009