fonts December 2013

fonts@lists.fedoraproject.org

10 participants
6 discussions

current state and future of liberation-fonts
by Fabian Greffrath 27 Jan '14

27 Jan '14

[Sorry for the re-post, I did not know had to subscribe to the Fedora list.] Hello Pravin Satpute et al., I am one of the maintainers of the liberation-fonts package in Debian (it is called fonts-liberation there [1]) and I am a bit concerned about the current state of development and the future of these fonts. I have read that the new release 2.00.1 based on Google Crosscore fonts has been defered from Fedora 18 because of rendering regressions [2]. However, since then development has apparently stopped in the GIT repository [3]. Have these rendering regressions been identified? Are they going to get addressed in the fonts or in other parts of the font rendering stack? Will there be another release of the liberation-fonts in the short term or have these fonts been defered altogether in favor of another font family? Thanks for your replies, - Fabian [1] http://packages.qa.debian.org/f/fonts-liberation.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=885596 [3] https://git.fedorahosted.org/git/liberation-fonts.git

3 11

Muli fonts packaging
by bebo_sudo 27 Dec '13

27 Dec '13

Hi all, I'm going to package the "muli" fonts (http://www.fontsquirrel.com/fonts/muli) by Vernon Adams. What I'd ask is: Is it correct to name the package vernon-adams-muli-fonts ?? And another question: the designer, Vernon Adams, hosts the source file on fontsquirrel, as you can see from the above link, but he didn't set a version number. Should I set it to 1.0 or what else? Thanks in advance, bebo_sudo

2 5

Lohit2: Lohit Malayalam development plans
by Pravin Satpute 12 Dec '13

12 Dec '13

Hi All, I think everyone should be happy with Lohit Devanagari and Lohit Gujarati releases. While looking back i see we have achieved objectives planned [1] during the start of project. Its time to move towards other scripts. Though Bengali, Gurumukhi, Tamil looks low hanging fruits we want to fix bit more challenging scripts as well. We started thinking on what we can do in Lohit Malayalam in last month. After couple of weeks of analyisis we found there is good scope for improvement in Lohit Malayalam. Basic improvements as we done in Devanagari and Gujarati 1. Following AGL. [2] 2. Supporting points provided in Unicode chapter 9 for Malayalam script. 3. Feature file separate for flexibility and reusability. 4. Complete cleanup of existing Open type tables 5. Supporting both "mlym" and "mlm2" open type specifications. 6. Thorough testing with Harfbuzz and Uniscribe (WinXp, W7 and W8) Other fonts specific improvement. 7. Presently Malayalam font has 281 shapes out of that we figure out 71 (+5/6) shapes are irrelevant. We can achieve these shapes with glyph positioning and intelligent glyph substitution rules without affecting fonts aesthetics and quality. 8. We have some pending bugs on bugzilla [3] as well As we planned earlier making Lohit fonts most efficient and effective is our primary objective. [1] Bit ambitious to say right now but i want make Lohit as a lightest Malayalam modern script fonts. Sneha has already started working on lohit2 [4] git repo for Malayalam font development. If you are looking any other suggestions or improvement in Lohit, feel free to propose here. Cheers, Pravin Satpute 1. http://pravin-s.blogspot.in/2013/08/project-creating-standard-and-reusable.… 2. https://sourceforge.net/adobe/aglfn/wiki/AGL%20Specification/ 3. https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&… 4. https://github.com/pravins/lohit2

1 0

[Announce] Lohit Devanagari 2.93.0 release (lohit2 project)
by Pravin Satpute 11 Dec '13

11 Dec '13

Hi All, This is the 3rd release of Lohit Devanagari from the lohit2 project[1] we planned earlier. In this 2.93.0 release i initially thought there will be not that many enhancements or fixes possible but i was wrong. We have following fixes in this version. 1. Additions of 17 glyphs for U+093F (?) and its variants (reph, anusvara). 2. Contextual chaining substitution to match above added matras on proper glyphs. 3. Fix for locl tables for Marathi and Nepali language. 4. Fix for self-intersecting glyph warning in number of shapes. 5. Testing across platform. For more details see Changelog [2] Updated lohit project page [3] for download details. Source tarball link [4], TTF tarball link [5] and webfonts format for Lohit is at [6]. I will soon build this for Fedora. Feel free to report any issues in github[7] Regards, Pravin Satpute 1. http://pravin-s.blogspot.in/2013/08/project-creating-standard-and-reusable.… 2. https://raw.github.com/pravins/lohit/master/devanagari/ChangeLog <https://raw.github.com/pravins/lohit/master/gujarati/ChangeLog> 3. https://fedorahosted.org/lohit 4. https://fedorahosted.org/releases/l/o/lohit/lohit-devanagari-2.93.0.tar.gz 5. https://fedorahosted.org/releases/l/o/lohit/lohit-devanagari-ttf-2.93.0.tar… 6. https://fedorahosted.org/releases/l/o/lohit/lohit-devanagari-web-2.93.0.tar… 7. https://github.com/pravins/lohit/issues/new

1 0

Local patching of fonts
by Paul Flo Williams 06 Dec '13

06 Dec '13

I've recently been looking at the prospect of locally patching font files for Fedora, prompted by two things: 1. Petr Vobornik raised the issue of fonts having an fsType flag that prevented embedding, even though they are licensed under terms which allow distribution and modification.[1] 2. Bug 706559, "Font variants not used correctly"[2], refers to a font family that contains more than just the R,B,I,BI styles and shows that they are not well-treated by applications including LibreOffice. It appears that this may be because the various weights and styles are not well named, but we can't quite get to the bottom of this bug because the family under discussion, Neo Sans Intel, is proprietary (i.e. not packaged). However, we can see bugs like 706559 in fonts that we have already packaged. If you install chisholm-letterslaughing-fonts, you'll find that you have three font files but only one is accessible in LibreOffice. Close examination will show that all three have the Family name set to "Letters Laughing", but the Subfamily (Style) names are "at Their Execution", "by Quantized and Calibrated" and "Dissection and Destruction". You can see why LO might be confused.[#] In other cases, we have had to adopt rather awkward Fontconfig configurations in order to rename fonts. Now, we either fix font problems like these locally, or we push them back upstream. We are supposed to do the latter, but we know how many fonts are pushed out into the world as a one off. When font problems are raised during review and the packager is asked to push the comments back upstream, how often do we see little response and no new release? Being practical, if we wish to fix problems locally, I'm aware of three options: 1. FontTools/TTX, which can convert a font into XML and back again. However, Petr reports that it currently crashes on Open Sans[3], and we have no smart way of verifying that the "To XML, patch, compile to TTF" cycle produces a font that performs at least as well as the original. 2. FontForge can be scripted to perform changes on fonts, but in this case we compile a completely new font, which is subject to any number of quirks introduced by local FontForge preferences, unstated in the script file, and FF's well-known stability issues. 3. Fontconfig scripts, which most of us just hack from the templates provided by Nicolas Mailhot because ... well, I certainly couldn't write the DejaVu ones from scratch. There is the additional problem that not all applications might use Fontconfig. (I might be misremembering but doesn't Firefox do something special?) The problem of embedding flags is now being addressed by the packaging of a simple tool called "ttembed" which just touches OS/2.fsType and checksums, nothing else.[4] I was considering the construction of another, more general, tool that would perform adjustments to other OS/2 or name table fields in-place[*], adjusting checksums as necessary in order to keep the font consistent, but specifically not decompiling the font or attempting to do glyph or GPOS type changes. The proposed method would be to write a very simple recipe for the font changes, like this: recipe.txt: OS/2.fsType=0 OS/2.panose=4,0,0,0,0,0,0,0,0,0 name.1.0.0.1="Letters Laughing at Their Execution" name.1.0.0.2="Regular" name.1.0.0.4="Letters Laughing at Their Execution" name.3.1.1033.1="Letters Laughing at Their Execution" name.3.1.1033.2="Regular" name.3.1.1033.4="Letters Laughing at Their Execution" and apply it with: $ ttpatch recipe.txt LettersLaughing.ttf With simple recipes like these, we could correct the entire Letters Laughing family and any others that don't follow WWS naming. With local testing for correct behaviour, we would even have a complete set of corrections to suggest to upstream (with the expectation that they'd apply them in their font editor, of course, rather than ttpatch.) Note that the patch recipe contains deliberately almost-duplicated lines; I'd suggest that it's better to repeat the name record lines for Mac and Windows compatibility rather than try to build a cleverer ttpatch that would try to keep the names consistent across platforms and fail in the case of localisation differences, for instance. I think that this would be a step forward from just packaging fonts and accepting their quirks towards more careful curation. I'd like to hear of any other problems with fonts in common applications that could be addressed in this fashion, or any other thoughts? [*] OK, "in-place" is stretching it when considering the name table, which might grow or shrink as required, but I'm saying that this tool should definitely not re-order tables or touch anything other than the tables required to do the patch, which will be the touched tables, offset table and the head.checkSumAdjustment field. This makes verifying the changes much simpler. [#] This issue came up during package review[5], and upstream refused to rename the styles. I'm proposing to adjust the fonts so that their quirky names remain unchanged, but redistributed amongst the name table fields so that all variants are accessible. I doubt upstream really wanted 2 out of 3 designs to be unusable in our major office application. [1] https://lists.fedoraproject.org/pipermail/devel/2013-November/192501.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=706559 [3] https://lists.fedoraproject.org/pipermail/devel/2013-November/192540.html [4] https://bugzilla.redhat.com/show_bug.cgi?id=1036754 [5] https://bugzilla.redhat.com/show_bug.cgi?id=491530 -- Paul Flo Williams http://hisdeedsaredust.com

6 5

Fonts included in packaged themes
by Pete Travis 05 Dec '13

05 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I've been working to package Nikola[1], a static site generator written in python. Nikola can use bootstrap[2] themes, and includes a couple examples. One of these themes includes a single font, glyphicons-halflings-regular, which appears to be licensed[3] in a way that allows them to inherit the license of the Bootstrap theme they are included in - or at least, Bootstrap is MIT[4] and Glyphicons says if it comes with Bootstrap it uses Bootstrap's license. If *not* distributed with/via Bootstrap, Glyphicons is CC-BY. It seems logical to include an example theme developed for this software, and the font is an integral part of the theme. I'd really like to take the easy route and just bundle the font, but would rather do it the right way. Can someone offer guidance? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1010741 [2] https://github.com/twbs/bootstrap [3] http://glyphicons.com/license/ [4] https://github.com/twbs/bootstrap/blob/master/LICENSE-MIT - -- - -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize(a)fedoraproject.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSoTryAAoJEL1wZM0+jj2ZCKcIAIUsd4RQOqvB+I0ErYEuFwSg i7GBNv7tFuVk5ej5uQDA0lzRRJHSQUNX2C/mDz4iRW/x62Q42z+F/2j6jVhGFE1b re8tlSUA3dos6ty+gD5QWH14vIS7KYvpPY1VtzN+XIown+9jMNsg0rHgJGs8WbPp GX52tXQRvAA/0m0DiRSdljqXCKX/toxDFT9xMzE4ee7hAcS/yaZAzX7F8uSFRCjC 3EYwL868QqyZS7XSl9MoCpRU/zUf7r1aw+U+6fVFvHDH5k4+Auej4mAfuawxu3f1 wdy71itSoGSrVGfhagukcDqvLg6OyY3pYkGxcDp65h+YT2Th+cHDGvesU0Qp55w= =efiD -----END PGP SIGNATURE-----

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts December 2013