Le mardi 07 septembre 2010 à 22:23 +0100, Richard Hughes a écrit : > On 7 September 2010 17:32, Matthias Clasen <mclasen@xxxxxxxxxx> 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 _______________________________________________ fonts mailing list fonts@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/fonts http://fonts.fedoraproject.org/
