abattis-cantarell-fonts looking for review
by Luya Tshimbalanga
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello team,
Design team have recently chosen Cantarell for body text.
I have packaged Cantarell fonts for Fedora and am looking for review [1].
I noticed Dave Crossland is part of SIG Fonts so, if interested, he can
be co-maintainer
of abattis-cantarell-fonts once it passed the review.
Ref:
- -----
[1] https://bugzilla.redhat.com/show_bug.cgi?id=623868
- --
Luya Tshimbalanga
Graphic & Web Designer
E: luya(a)fedoraproject.org
W: http://www.thefinalzone.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iQEcBAEBAgAGBQJMZKNPAAoJEGZ+gIukWeEeY2YH+gOYRLrNlB9O4GcRStXDUQCF
YGM5wyfJivrmysWUJ+Krxc7cXo5lRWGnQ6M1nOxKr1rfhjMyyHxCThUKIAOVkTWu
mxGyu1r39RvgGk+9kUYZe3zDH0FbeXTpkrnUGEhuRpe4ut9xgM97I7qvAZJ/u4sA
+sPK5smgTAtKNgh8fp5EaKEvd9ilDZR5QWOOTNG0wE5lKmKV3xnYhrgiYoASwk/8
bRoMHO74t1RNnOIPopF0fZ/jqvLDQ8ciZ2oE/Iw5r9ImLYwDwfORCutBIq4JPPgT
gg6+fOwsNUJrykbytovOgCr9TezF1goqgtAU9b1223AmcDmAN6LpUGda5Hgy8LE=
=EOFF
-----END PGP SIGNATURE-----
13 years, 1 month
Re: Linux and application installing
by Nicolas Mailhot
Le mardi 07 septembre 2010 à 22:23 +0100, Richard Hughes a écrit :
> On 7 September 2010 17:32, Matthias Clasen <mclasen(a)redhat.com> wrote:
> >> And BTW a request at the time was to extend it with font previews to get
> >> a "font store" (because for fonts, gfx preview is really relevant and
> >> not eye candy) and it never happened :(
> >
> > If you send a patch it might !
>
> A patch would be lovely, but some sample code that renders a ttf file
> to a png file "The smart brown fox or whatever" using cairo is
> probably good enough for me to get going.
As far as I know, here is the current state of the art:
1. gnome-font-viewer has the code to select a specific font file and a
pangram database (short snippets of text appropriate for different
locales)
2. pango-view has the code to generate a svg using cairo containing a
specific text in a specific font (but it does not let you select a
specific font file as far as I can see)
For example:
pango-view --font="Yanone Kaffeesatz 50" -t "tralala" --no-display -o
preview.svg
so by combining code from both it should be possible to create a small
utility that takes as argument a font file and a locale and generates a
svg (or svgz) containing the pangram text for this locale with the
shapes of the selected font file.
(possibly with the option to specifically pass the unicode string to
render as svg instead of a local, for example for symbol fonts where
it's totally uninteresting to display human text)
And then we could add in our font packaging guidelines that packagers
have to run this utility to install the preview svg in the rpm at a
standard location for packagekit to harvest and display as preview for
this package (maybe multiple preview svgs per package, if a font package
includes multiple font faces or multiple "interesting" locales to
highlight)
Why?
1. As a font file is already an optimized vector library format it is
not advisable to generate a preview for all the glyphs included in a
font file. The result could easily be bigger than the packaged font
file, or too long to be used as preview (cjk *shudder*)
2. It is not really possible to fix in stone or even autodetect the font
subset which is interesting to use in preview. Different fonts have
different unicode coverage, and many fonts have one core part plus
uninteresting bits copied from other fonts to fill in.
For example Debian has tried to run an automated preview generator on
its font archive, displaying some ASCII text, and they got scores of
non-latin font that all previewed the same (because their authors
created the glyphs for their locale, and then copied the same
ghostscript or free sans font for latin so their users could write mixed
english/something else text without changing font).
Therefore, the selection of the font subset to use as preview is an
editorial decision the font packager is best placed to make. (otherwise
I'd be more than happy to have packagekit do it all by itself without
packager intervention, I don't like more work as packager too)
3. It's not really a good idea to render to a bitmap format when you
don't know the pixel density of the user display. As the hardware gets
more diverse, there is a high chance you'll have to scale the preview
sooner or later and for that a vector format like svg is more respectful
of font shapes (grid-fitting & hinting matter at small sizes but font
previews are usually done with big text)
---
I hope this seems sane from Richard's point of view
Regards,
--
Nicolas Mailhot
13 years, 3 months
Re: Linux and application installing
by Nicolas Mailhot
Le mercredi 08 septembre 2010 à 19:07 +0100, Alex Hudson a écrit :
> The i18n situation is also pretty sad from my point of view too. If you
> use pretty much any design app, OO Writer and Inkscape being the ones
> which cause me pain, the standard set of fonts that comes with Fedora is
> entirely confusing and bizarre, and gets completely in the way of
> actually trying to design text.
It's well known that the current font selectors are not good enough.
They were designed for a dozen unchanging fonts with four faces at most,
and the font state has grown a lot more complex since (unicode, smart
font features, fonts with lots of faces, etc). Nowadays a normal desktop
system can have a font library as complex as specialized design stations
had a decade ago, but the standard selectors have not been raised to the
level of dtp font selectors of last decade.
http://qa.openoffice.org/issues/show_bug.cgi?id=79878
https://bugzilla.gnome.org/show_bug.cgi?id=597751
(you can probably find others on
http://fedoraproject.org/wiki/Known_fonts_and_text_bugs)
There are many designs for better selectors floating around (some of
them years old).
I'm pretty use that as soon as GNOME, KDE or OO.o fixes its
implementation, the others will suddenly find the time to fix theirs.
Right now they seem to consider it's ok to suck as long as the others
suck equally.
I'd love to see progress there too, but it is a different problem than
the "font store" one.
--
Nicolas Mailhot
13 years, 3 months
Re: Linux and application installing
by Nicolas Mailhot
Le mercredi 08 septembre 2010 à 09:18 -0800, Jeff Spaleta a écrit :
>
> Just to be clear. When "users" want a to get a new font what is the
> ideal software interaction path you expect them to take to find fonts?
> It's not clear that app-install is what you expect them to interact
> with. I do sort of expect normal end-users to want additional fonts as
> part of day to day document preparation and I wouldn't cast the search
> for fonts as a power user or admin activity.
There are several possible interactions points:
1. just add a "font store" pane next to the "app store" one.
If you go to (free of paid) web font libraries (fontsquirrel, dafont,
myfont...), you'll see that the info presented to users to help them
select the font they want to download is basically:
A. The font name
B. A preview image
C. Some unicode coverage info
D. Some info about the available font faces (bold, italic,
condensed...)
E. A text description
F. Legal conditions (price, eula, licence)
A. C. E. F. are already present in our font package metadata. (however
pk does not display C for fonts even though it is a major criterium to
select a particular font for users, because the current PK package list
only presents generic package info)
If we add the image preview, we have B.
D is rather trivial to add (it's not there yet because nothing uses it)
So with the image preview, we have information parity with web font
libraries, except for our own material, and with unmatched ease of
installation through packagekit
2. modify the standard gtk/qt/gnome/kde font selector to have a "more"
button that just launches the "font store" (Microsoft Office does it
well in Visio for example, the trigger to access the online shape
library is inside the local shape selector)
3. use a "font store" subset to help users select the font they prefer
when the auto-font-installer is triggered (for example, there is no
cyrillic font on system, an app needs to render russian, show the font
store window displaying only russian fonts and let the user select the
one that looks nicest to him)
If 1. 2. 3. are successful I'm sure font-intensive apps (DTP, art,
office) will add by themselves "font store" trigger points wherever's
appropriate (probably adding filters to restrict the search to whatever
they feel is more useful for their users in a particular document
state). We don't need to do it now.
Also, a mid-term objective is to add aliasing info to font packages so
(for example) the liberation package can be autoselected when a user
needs Arial. But it's not really necessary at this point. Having a
decent user-friendly "font store" is a lower hanging fruit with a lot
more ROI (we've already built most of the infra, the gfx previewing is
the main part that stops users from making good use of it)
Regards,
--
Nicolas Mailhot
13 years, 3 months
TeX-Gyre Fonts
by TK009
I am ready to put these up for review but have a question about what the
proper name should be for these fonts.
gust-tex-gyre-<font name>
or
tex-gyre-<font name>
13 years, 3 months
