Re: Linux and application installing
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