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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
