Linux and application installing

Nicolas Mailhot nicolas.mailhot at laposte.net
Wed Sep 8 19:35:50 UTC 2010


Le mardi 07 septembre 2010 à 22:23 +0100, Richard Hughes a écrit :
> On 7 September 2010 17:32, Matthias Clasen <mclasen at 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



More information about the devel mailing list