fonts September 2010

fonts@lists.fedoraproject.org

5 participants
5 discussions

abattis-cantarell-fonts looking for review
by Luya Tshimbalanga 08 Nov '10

08 Nov '10

-----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-----

6 14

Re: Linux and application installing
by Nicolas Mailhot 08 Sep '10

08 Sep '10

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

1 1

Re: Linux and application installing
by Nicolas Mailhot 08 Sep '10

08 Sep '10

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

1 0

Re: Linux and application installing
by Nicolas Mailhot 08 Sep '10

08 Sep '10

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

1 0

TeX-Gyre Fonts
by TK009 05 Sep '10

05 Sep '10

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>

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts September 2010