RSS/Atom feed Twitter
Site is read-only, email is disabled

Designing a Better Font Selection Widget for use in Open Source Software

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

14 of 15 messages available
Toggle history

Please log in to manage your subscriptions.

Designing a Better Font Selection Widget for use in Open Source Software Edward H. Trager 27 Sep 19:36
  Designing a Better Font Selection Widget for use in Open Source Software Sven Neumann 27 Sep 23:04
  Designing a Better Font Selection Widget for use in Open Source Software michael chang 27 Sep 23:22
  Designing a Better Font Selection Widget for use in Open Source Software Akkana Peck 28 Sep 02:02
   Designing a Better Font Selection Widget for use in Open Source Software Sven Neumann 29 Sep 21:03
  Designing a Better Font Selection Widget for use in Open Source Software Alastair M. Robinson 28 Sep 02:42
   Designing a Better Font Selection Widget for use in Open Source Software GSR - FR 30 Sep 17:18
  Designing a Better Font Selection Widget for use in Open Source Software mpsuzuki@hiroshima-u.ac.jp 28 Sep 04:01
   Designing a Better Font Selection Widget for use in Open Source Software Keith Packard 28 Sep 04:28
  Designing a Better Font Selection Widget for use in Open Source Software James Richard Tyrer 30 Sep 03:21
  Designing a Better Font Selection Widget for use in Open Source Software Roman Joost 30 Sep 10:26
   Designing a Better Font Selection Widget for use in Open Source Software Sven Neumann 01 Oct 02:30
  Designing a Better Font Selection Widget for use in Open Source Software GSR - FR 30 Sep 17:43
20050927190101.C636C146A4@l... 07 Oct 20:24
  Designing a Better Font Selection Widget for use in Open Source Software PLinnell 27 Sep 22:02
Edward H. Trager
2005-09-27 19:36:45 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

Hi, everyone,

This message is an open letter to:

- Gnome Desktop developers - KDE Desktop developers
- OpenOffice.org developers
- Gimp developers
- Inkscape developers

... regarding a proposal for an improved font selection drop-down widget that would be ideal for use in professional-quality Open Source word processing, desktop publishing, and graphic design programs such as OpenOffice.org, Gimp, Inkscape, and similar programs.

The proposal suggests a design that is particularly applicable where users require a streamlined and intuitive interface for selecting multiple fonts from large font collections present on the user's machine. The proposal also attempts to fully address aspects of internationalization related to font selection that I believe have been largely overlooked until now. Finally, the proposal suggests using a common XML configuration file which for storing font collection information.

To see the full proposal, please see:

http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/

The rest of this email provides a synopsis of the proposal.

Synopsis ========

Although important Open Source desktop software has advanced rapidly in the last few years and now easily rivals and in many cases surpasses commercial equivalents in terms of functionality and ease of use, the font selection drop-down widgets and font selection dialog boxes in many programs still lack a number of important features. (This is also true among commercial software too, but that is not our concern here).

First, many programs do not provide adequate font previews at the stage where the user is choosing from a (now-a-days usually very long) drop-down list of available fonts. Even when font previews are provided, they are often limited to a preview of Latin glyphs and thus provide no information about the appearance of non-Latin glyphs for, say, Chinese, Thai, or Arabic users trying to pick fonts for their language.

Secondly, a very long list of alphabetically-sorted font names is not ideal. Fonts need to be organized and presented to the user in logical groups, as is done in Apple OS X (where they are called "collections").
These groups can and should be both system-defined and user-defined. System-defined groups would include font categories like "Sans", "Serif", "Monospace", "Recently Used", and "Chinese". User-defined groups might include categories like "Script", "Black Letter", "Funky", or "Fonts for the new company brochure".

The proposal at http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/ addresses how these goals can be met. Implementation of the proposed font selection widget at the GUI toolkit level (i.e., in GTK+ and in KDE) along with an XML-based configuration scheme standardized across toolkits and desktops would do much to help create a more intuitive and more uniform user experience on Linux and related Open Source platforms.

I welcome the community's suggestions and criticisms --

-- Ed Trager maintainer of "Unicode Font Guide For Free/Libre Open Source Operating Systems" http://eyegene.ophthy.med.umich.edu/unicode/fontguide/

PLinnell
2005-09-27 22:02:41 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

On Tuesday 27 September 2005 21:01, gimp-developer-request@lists.xcf.berkeley.edu wrote:

http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/

We on the Scribus Team have struggled with this too and with the changes in our 1.3.x series to enhance non-Latin support and complex glyphs will make this even more important. We have made some improvements vis a vis 1.2.x, but its not a 100% solution.

I would recommend you bring this to xdg@freedesktop.org as well, as well as the Scribus mailing list. I am sure this will be considered carefully.

Your site is an excellent resource and already on our links page on www.scribus.net

Cheers,

Peter

Sven Neumann
2005-09-27 23:04:58 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

Hi,

"Edward H. Trager" writes:

... regarding a proposal for an improved font selection drop-down widget that would be ideal for use in professional-quality Open Source word processing, desktop publishing, and graphic design programs such as OpenOffice.org, Gimp, Inkscape, and similar programs.

Interesting. The GIMP font selection scheme does certainly leave a lot to desire. There are some good suggestions in Bugzilla, just waiting to be implemented:

http://bugzilla.gnome.org/show_bug.cgi?id=137624 http://bugzilla.gnome.org/show_bug.cgi?id=150500

and somewhat related but more technical:

http://bugzilla.gnome.org/show_bug.cgi?id=168102

The proposal also attempts to fully address aspects of internationalization related to font selection that I believe have been largely overlooked until now.

I don't think they've been overlooked. At least for the GIMP font selection, the reason for the fact that the font selection is still that simple, is lack of developer resources. Providing a common framework might help to overcome this problem.

Finally, the proposal suggests using a common XML configuration file which for storing font collection information.

Could this perhaps become part of fontconfig? We already have XML font configuration there. Loading another XML file would slow down startup further.

Sven

michael chang
2005-09-27 23:22:16 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

On 9/27/05, Edward H. Trager wrote:

... regarding a proposal for an improved font selection drop-down widget that would be ideal for use in professional-quality Open Source word processing, desktop publishing, and graphic design programs

http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/

As a user, this sounds like a very awesome proposal, and if implemented, would revolutionize font GUIs for users. I don't know whether it could cause a problem with Usability (e.g. Text to Speech systems) though...

Just a note (and yes, I'm nit-picking), but there is no such thing as 'a Chinese pangram'. Chinese uses individual characters for every word (AFAIK), so you'll just have to choose some sample text that is representative of the language, or make some up. IIRC, Japanese has an alphabet, though, and Chinese has a sort of 'proununciation' alphabet (but that's seperate).

-- ~Mike
- Just my two cents
- No man is an island, and no man is unable.

Akkana Peck
2005-09-28 02:02:39 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

Nice proposal. A lot of apps could benefit from a good shared font selector -- it's not just an issue of one app, as you point out.

I love the idea of font groupings. I don't mind editing an XML file, but I'm sure it wouldn't take much to whip up an app to help people customize their downloaded fonts, compared with the rest of the work involved in the proposal.

Tooltips over menus can be really annoying, because while they're showing more information about one entry they're preventing you from scanning all the other entries. You can move the mouse outside the menu, but it's a shame to have to mouse in to scroll, then quickly mouse out before the tooltip blocks the list you're trying to read. Please consider making that part optional, or skipping it.

One more UI issue you don't address: the length of the font list can be a problem, especially if you have a lot of fonts installed.

The current GIMP font list (and your proposal looks similar) pops up as a combobox that shows, on my system, 9 fonts at a time. Exploring the whole list through this small window takes a long time and a lot of clicking.

Sometimes I really miss having a font selector dialog which I could resize to show a long list, so that I could scan through more quickly without needing to scroll so many times.

...Akkana

Alastair M. Robinson
2005-09-28 02:42:32 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

Hi,

Edward H. Trager wrote:

I welcome the community's suggestions and criticisms --

One easily overlooked feature which I consider to be most important is keyboard support.

In many Windows apps (and OpenOffice), I can type the first few characters into the font selector combo and that's usually enough to narrow it down to the font I'm going to use. This feature makes an *incredible* difference to working efficiency.

All the best, --
Alastair M. Robinson

mpsuzuki@hiroshima-u.ac.jp
2005-09-28 04:01:50 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

Hi

I think your proposal is a propose of "localized font name" (like Microsoft Windows fontmenu, or classic QuickDraw based fontmenu on MacOS) or "localized sample text" (like recent fontpanel on MacOS X). If I'm misunderstanding, please correct.

There are a few problem:

1) font name in font file is localized? internationalized? ----------------------------------------------------------

For example, many CJK fonts will have TTF names in East Asian languages (i.e., Chinese, Japanese, or Korean) stored in the font file itself.

This is correct for commercial fonts, but incorrect for free font. Most CJK free font developers don't assume as the font handler is capable to handle non-ASCII font name, and often use US-ASCII font name or UTF16-ed ASCII font name. For example, Japanese free TTF, Sazanami Gothic and Sazanami Mincho has their name in ASCII.

[NOTE]
BTW, I'm afraid that Mac OS X changes the script to display fontname by language environment. Traditional QuickDraw system uses localized fontname always, but ATSUI does not. See

http://www.gyve.org/~mpsuzuki/ats_benchmark.html

2) a font object knows its best script? --------------------------------------- This is accurate for commercial fonts designed for Microsoft Windows, MacOS, and traditional X window system, but inaccurate for recent Unicode-oriented desktop environment for Linux, Solaris, AIX etc. In such systems, to avoid from handling various font files for various scripts, there is a tendency to push everything into single font file. Unfortunately, the separation of the script and UCS-2 codepoint separation is badly-designed. Parsing traditional TTF header (OS/2 etc) is not sufficient to detect the best script of a given UCS-2 font. I think, the scripts which requires special OpenType layout features (like South Asian and African scripts) won't be merged in near future, because development is ongoing, but the unification tendency is clear for CJK scripts.

If a given font insists as "I have all character for UCS-2 codepoint", how proposed fontmenu displays it?

[NOTE] The glyph shape for Hanzi is dependent on Simpl. C, Trad.C, J and K, in reality (you can find OpenType categorizes all Hanzi into single "hani" script class, but divide it into sub-categories by language class: JAN, KOR, ZHS, ZHT). In the other words, OpenType thinks traditional TTF mechanism is insufficient to specify the best script, and introduced new mechanism.

3) menu for fontset? --------------------
Microsoft Windows and Mac OS X have a feature to lap over multiple TTFs. The font menu of Microsoft Windows don't have menu to control that, but fontpanel of Mac OS X provide to edit "font collection". How do you think about the requirement of such features?

4) heaviness ------------
I think proposed fontmenu must access all font contents to render its fontname. I suppose both of Microsoft Windows and MacOS/Mac OS X uses kernel space font cache maximumly, but how about UNIX platforms? Thinking about the situation using xfs at remote server, scanning all font contents can be heavy work and users may be forced to wait. There's any proposal about that?

Regards,
mpsuzuki

P.S.

http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/

BTW, proposal of a few terminology fixes of your hard-worked web page.

and the second is in the "Guo Biao" encoding...

"Guo Biao" means just National Standard. Possibly you don't want to call ISO-10646 as "ISO encoding" :-). The encoding should be noted as GB-2312, GB-18030, etc. In fact, legacy PC encoding of TrueType fonts designed for Chinese script on Microsoft platform was based on GB-2312.

Keith Packard
2005-09-28 04:28:54 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

On Wed, 2005-09-28 at 11:01 +0900, mpsuzuki@hiroshima-u.ac.jp wrote:

Hi

I think your proposal is a propose of "localized font name" (like Microsoft Windows fontmenu, or classic QuickDraw based fontmenu on MacOS) or "localized sample text" (like recent fontpanel on MacOS X). If I'm misunderstanding, please correct.

There are a few problem:

1) font name in font file is localized? internationalized?

An ASCII name is (almost) always present; localized names are more often present in commercial fonts. Fontconfig tags each name with the language and territory so you can search for an appropriate name even if the font provides multiple localized names (which TTF does support).

2) a font object knows its best script?

Fontconfig automatically detects language support by measuring coverage against an approximate orthography for the language. This means that even incorrect OS/2 tables will not accidentally mark a font as supporting additional languages.

Fontconfig does use the OS/2 table to disambiguate among hanzi languages -- a font covering all of GB18030 but which does not include Japanese in the OS/2 code page range bits is not marked as supporting Japanese, even though GB18030 includes all of the codepoints needed for Japanese support.

This does rely on the fonts not setting code page range bits for the wrong language; so far, that's been reasonably successful.

3) menu for fontset?
--------------------
Microsoft Windows and Mac OS X have a feature to lap over multiple TTFs. The font menu of Microsoft Windows don't have menu to control that, but fontpanel of Mac OS X provide to edit "font collection". How do you think about the requirement of such features?

Fontconfig also has this support, and Qt and Pango both avail themselves of it. Unlike Windows or Mac OS X, it is entirely automatic so that fontsets are constructed from available fonts to provide as complete a coverage as the available fonts can provide.

4) heaviness
------------
I think proposed fontmenu must access all font contents to render its fontname. I suppose both of Microsoft Windows and MacOS/Mac OS X uses kernel space font cache maximumly, but how about UNIX platforms? Thinking about the situation using xfs at remote server, scanning all font contents can be heavy work and users may be forced to wait. There's any proposal about that?

Client side fonts are quite efficient in this regard, rendering and caching only glyphs which are actually used. This permits efficient use of the actual font for the font menu. It's not as fast as using a single font for all menu entries, but the benefit to the user is probably worth the cost in most environments.

-keith

Sven Neumann
2005-09-29 21:03:11 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

Hi,

Akkana Peck writes:

Sometimes I really miss having a font selector dialog which I could resize to show a long list, so that I could scan through more quickly without needing to scroll so many times.

Why don't you just open the Fonts dialog then?

Sven

James Richard Tyrer
2005-09-30 03:21:25 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

Edward H. Trager wrote:

Hi, everyone,

This message is an open letter to:

- Gnome Desktop developers - KDE Desktop developers
- OpenOffice.org developers
- Gimp developers
- Inkscape developers

... regarding a proposal for an improved font selection drop-down widget that would be ideal for use in professional-quality Open Source word processing, desktop publishing, and graphic design programs such as OpenOffice.org, Gimp, Inkscape, and similar programs.

The proposal suggests a design that is particularly applicable where users require a streamlined and intuitive interface for selecting multiple fonts from large font collections present on the user's machine. The proposal also attempts to fully address aspects of internationalization related to font selection that I believe have been largely overlooked until now. Finally, the proposal suggests using a common XML configuration file which for storing font collection information.

To see the full proposal, please see:

http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/

The rest of this email provides a synopsis of the proposal.

Synopsis ========

Although important Open Source desktop software has advanced rapidly in the last few years and now easily rivals and in many cases surpasses commercial equivalents in terms of functionality and ease of use, the font selection drop-down widgets and font selection dialog boxes in many programs still lack a number of important features. (This is also true among commercial software too, but that is not our concern here).

First, many programs do not provide adequate font previews at the stage where the user is choosing from a (now-a-days usually very long) drop-down list of available fonts. Even when font previews are provided, they are often limited to a preview of Latin glyphs and thus provide no information about the appearance of non-Latin glyphs for, say, Chinese, Thai, or Arabic users trying to pick fonts for their language.

Secondly, a very long list of alphabetically-sorted font names is not ideal. Fonts need to be organized and presented to the user in logical groups, as is done in Apple OS X (where they are called "collections").
These groups can and should be both system-defined and user-defined. System-defined groups would include font categories like "Sans", "Serif", "Monospace", "Recently Used", and "Chinese". User-defined groups might include categories like "Script", "Black Letter", "Funky", or "Fonts for the new company brochure".

The proposal at http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/ addresses how these goals can be met. Implementation of the proposed font selection widget at the GUI toolkit level (i.e., in GTK+ and in KDE) along with an XML-based configuration scheme standardized across toolkits and desktops would do much to help create a more intuitive and more uniform user experience on Linux and related Open Source platforms.

I welcome the community's suggestions and criticisms --

-- Ed Trager maintainer of "Unicode Font Guide For Free/Libre Open Source Operating Systems" http://eyegene.ophthy.med.umich.edu/unicode/fontguide/

Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

ARGH!!

<<
Professional graphic artists might additionally like to be able to find out which fonts were available in "extra light" or "extra bold" forms. Perhaps this could be an additional display option (second row in figure on the left). I am not sure whether such information is encoded in font files in a consistent manner or not. Other font styles such as "condensed" also exist, but again I am not sure whether such information is encoded in font files in a consistent manner that could be enumerated by software reading the files.
>>

First problem:

Devise a method of dealing with the multi-axis qualities of fonts.

THEN perhaps your ideas are the second step -- the solution to the second problem.

Fonts come in different widths as well as different weights. These are linearly independent as is Regular vs Italic|Oblique|Slanted. That is, I can have "Helvetica Condensed Light Oblique" (not sure if it really exists) -- there are three parameters and they can be changed independently. Worse, it is possible that some fonts will have an additional attribute.

Although you can make a list of common weights and a list of common widths, there is no complete list so it is always possible that a font with either a width or a weight that has never been seen before will be installed on the system.

And it gets worse. TrueType and Type1 do not use the same definition of Family. That is, "Helvetica Narrow" Type1 has a family name of "Helvetica". However, "Arial Narrow" TrueType has a family name: "Arial Narrow".

So, there are real problems. Perhaps FontConfig can deal with some of them, but they are real and they need to be fixed first.

Roman Joost
2005-09-30 10:26:55 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

Hi Edward,

thanks for you proposal.

On Tue, Sep 27, 2005 at 01:36:45PM -0400, Edward H. Trager wrote:

To see the full proposal, please see:

http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/

The rest of this email provides a synopsis of the proposal.

Speaking as a user here, I'm not sure if your proposal of a drop down is really what solves the problem here.

I really like the fact, that the fonts are categorized. That is something which I really miss in the font selection dialogs currently. If a user has installed a motherload of fonts, he mostly has to scroll and scroll and scroll to pick a font. Using a drop down widget has the disadvantage, that I still have to scroll like mad to pick a font, even if they are categorized. I'm able to find the font much faster, but picking a font is cumbersome as it is now.

In fact, the only dialog which I endore is the font dialog from Apples Mac OS X. You still have to scroll to pick a font, if there are lots of fonts in one category, but it minimizes the effort.

Well, just my 2 cents to your proposal :)

Greetings,

GSR - FR
2005-09-30 17:18:51 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

Hi,
blackfive@fakenhamweb.co.uk (2005-09-28 at 0142.32 +0100):

I welcome the community's suggestions and criticisms --

One easily overlooked feature which I consider to be most important is keyboard support.

Indeed.

In many Windows apps (and OpenOffice), I can type the first few characters into the font selector combo and that's usually enough to narrow it down to the font I'm going to use. This feature makes an *incredible* difference to working efficiency.

Yet another overlooked feature is being able to search for something in the middle.

GSR

GSR - FR
2005-09-30 17:43:17 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

Hi,
ehtrager@umich.edu (2005-09-27 at 1336.45 -0400):

This message is an open letter to:

[...]

... regarding a proposal for an improved font selection drop-down widget that would be ideal for use in professional-quality Open Source word processing, desktop publishing, and graphic design programs such as OpenOffice.org, Gimp, Inkscape, and similar programs.

[...]

The proposal at http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/ addresses how these goals can be met. Implementation of the proposed font selection widget at the GUI toolkit level (i.e., in GTK+ and in KDE) along with an XML-based configuration scheme standardized across toolkits and desktops would do much to help create a more intuitive and more uniform user experience on Linux and related Open Source platforms.

I welcome the community's suggestions and criticisms --

I doubt a menu is a good idea, both from coding and user point of view, as a huge menu is nasty for speed. Menu creation takes time or a lot of effort to make it really fast (the coding part) and so does navigating it, penalizes failure or experimentation and disallows keeping it open (the user part). A window more like the MacOSX one would be better, IMO. The preview as name, on the other hand, would be a nice addition to the dialog.

It could even become a helper tool, like calculator ones. With a simple method to pass back the info (a la popen(), no need of overengineering things), as well as copy&paste and drag&drop, it would indeed help.

GSR

Sven Neumann
2005-10-01 02:30:27 UTC (over 18 years ago)

Designing a Better Font Selection Widget for use in Open Source Software

Hi,

Roman Joost writes:

I really like the fact, that the fonts are categorized. That is something which I really miss in the font selection dialogs currently. If a user has installed a motherload of fonts, he mostly has to scroll and scroll and scroll to pick a font. Using a drop down widget has the disadvantage, that I still have to scroll like mad to pick a font, even if they are categorized. I'm able to find the font much faster, but picking a font is cumbersome as it is now.

Just a hint, in case you or someone else didn't notice yet: If you know the name of the font, you can limit the fonts being displayed in the dropdown list using the text entry next to the font button.

Sven