current state and future of liberation-fonts
by Fabian Greffrath
[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
9 years, 10 months
Muli fonts packaging
by bebo_sudo
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
9 years, 11 months
Lohit2: Lohit Malayalam development plans
by Pravin Satpute
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-reusabl...
2. https://sourceforge.net/adobe/aglfn/wiki/AGL%20Specification/
3.
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNE...
4. https://github.com/pravins/lohit2
9 years, 12 months
Local patching of fonts
by Paul Flo Williams
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
10 years
Fonts included in packaged themes
by Pete Travis
-----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-----
10 years
