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
10 years, 3 months
Re: fonts Digest, Vol 68, Issue 5
by Fabian Greffrath
Am Freitag, den 23.08.2013, 12:00 +0000 schrieb
fonts-request(a)lists.fedoraproject.org:
> Just done upstream release of liberation-fonts 1,07.3. Improved
> serbian
> locale support in it and also fix couple of other bugs. See changelog
> for
> more details.
It appears that this release is missing the patch for RH#715309:
"hinting problem of Liberation Sans Bold character 'u' at particular
point size" that was included in previous releases.
- Fabian
10 years, 8 months
introducing ttname, the CLI font metadata editor
by T.C. Hollingsworth
Hi Fedora font folks!
To make complying with the new licensing requirements [1] easier, I've written
a little tool that allows you to quickly edit the "name" table of OpenType fonts
from a shell. This makes inserting the contents of a license to a ttf file that
is missing it in a spec file as easy as something like:
--------------------------------------------------------------------------------
BuildRequires: ttname
%prep
%setup -q
ttname -a --copyright=$(head -n2 LICENSE) --license=$(<LICENSE)
--------------------------------------------------------------------------------
It's already available in Rawhide and F20 and you can install it from updates-
testing in F19 and F18:
sudo yum --enablerepo=updates-testing install ttname
I've also filed buildroot overrides so it's immediately useful during builds as
well.
I was disheartened to find that there was nothing like this already in
existence, so I tried to make it generally useful to the free font community. It
supports all the well known fields in the name table and can fill in the
undefined ones too if you give it the numerical IDs.
Let me know if you find it useful for other stuff, or if there's anything that
helpful I could add. (For instance, it seems like there are a couple fields in
the "head" table that would be nice to support too, but I'm not sure.)
I'm going to be announcing the list of packages that have fonts that are missing
metadata soon.
Thanks!
-T.C.
10 years, 8 months
Re: F20 System Wide Change: Web Assets
by Nicolas Mailhot
Le Mar 6 août 2013 23:48, T.C. Hollingsworth a écrit :
> There's already some example instructions on how to use ttname here,
> which accurately reflects the CLI interface as it is now implemented:
> https://fedoraproject.org/wiki/User:Patches/ttname
also please keep the fonts list in CC when discussing changes to fonts
packaging in Fedora
Thank's for working on this!
--
Nicolas Mailhot
10 years, 8 months
Fonts with default Fedora installation
by pravin.d.s@gmail.com
Hi,
Recently i done packaging of google-noto-fonts [1] for Fedora. With this
font we got number of new script fonts of Unicode which were not available
earlier. [2]
Just done editing of comps file and my question is out of these script
fonts how many we suppose to install by default.
Presently we are following like at least one fonts for each script should
be available with default installation, so if anyone while browsing web etc
can get correct rendering for his script.
But here issue is supporting whole Unicode with default installation will
be too much.
Might be we should only install fonts for BMP of Unicode and lets have
other fonts installed by users when required (we do have feature in Fedora
where if any fonts are not installed by default fontconfig search for
particular script fonts.)
I have done comps editing by keeping above thing in mind. If anyone have
other suggestion please let me know.
Best Regards,
Pravin Satpute
1. https://admin.fedoraproject.org/pkgdb/acls/name/google-noto-fonts
2. http://koji.fedoraproject.org/koji/buildinfo?buildID=456970
10 years, 8 months
Released liberation fonts 1.07.3
by pravin.d.s@gmail.com
Hi All,
Just done upstream release of liberation-fonts 1,07.3. Improved serbian
locale support in it and also fix couple of other bugs. See changelog for
more details.
As usual one can download it from
https://fedorahosted.org/liberation-fonts
So presently in upstream we are maintaining liberation 1.07 and 2.00 two
different version. Version 2.00 also facing some hinting related issues.
So looking forward to improve liberation 2.00 version.
In meanwhile i am thinking to make liberation 2.00 available in Fedora,
so if someone prefers glyph coverage over better hinting bytecode he can
get liberation 2.00.
Thanks & Regards,
Pravin Satpute
10 years, 8 months
Q: fedora-review, fonts and %_font_pkg
by Alec Leamas
There is a bug for fedora review [1] to add some basic support for font
packages. It shouldn't be that hard, but time is limited.
One concern is that font specfiles are hard to parse because of the
%_font_pkg macro. The problem is that it "hides" the %files directive
which is what we use to locate the section (that we have to parse
ourselves instead of using rpm's parser is a long story).
Now, anything is possible. But according to the discussion in [2], fpc
nowadays seems very firm about that macros should not include any
section parts like %files, so %_font_pkg should most likely not have
been approved as-is today (?)
So: should the situation be rectified to comply with fpc's view,
probably with a new macro not including %files + deprecating %_font_pkg?
Not only for fedora-review (which will have to handle %_font_pkg
anyway), but for consistency?
--alec
[1] https://fedorahosted.org/FedoraReview/ticket/215
[2] https://fedorahosted.org/fpc/ticket/194
10 years, 8 months