unifont.org >> Font Dialog
By Ed Trager, 2005-09-25
Even though recent versions of important Open Source and commercial programs designed for graphic design and text layout have many advanced features indicative of the increasing maturity of these products, the font selection dialogs and widgets in these programs are for the most part still immature and lacking in important features that, if implemented, would make font selection a more streamlined and intuitive process.
The purpose of this document is to illustrate the problem using examples from both commercial and Open Source programs, and then suggest a solution for the Open Source community. Of course, the solution would be valuable if implemented in commercial software too, but my intention is to address an audience of Open Source software implementors. I specifically wish to address software engineers responsible for the Gnome and KDE desktops, the Gimp, Inkscape, and the OpenOffice.org suite.
The Gimp sports a sophisticated, well-designed color selection dialog. This document argues that attention should now be placed on bringing the font selection dialog in this and other programs up to the same level of excellence.
It is interesting to note that many of these same programs have sophisticated color selection dialogs and widgets that allow users to choose colors in several different ways and to remember a palette of recently used colors. For example, the Gimp allows users to choose colors in four different ways and maintains a palette of the most recently used colors. Programs like the Gimp will become even better when the same degree of thought and attention to detail has been engineered into the corresponding font selection widgets. In this document I will argue that current font selection dialogs and widgets are either not right, or only half-right, and I will outline what I believe to be the right solution.
In the research phase which preceded this written treatise, I decided to evaluate how a number of currently-available programs handle font selection. Below, I present the results of this investigation.
Without further ado, let's first take a look at what is clearly not the right solution. Adobe Illustrator version 10 is a program for graphic design professionals. As shown below in the screenshot of the Windows version of the program, font selection requires choosing a font from a series of pop-out lists. If a user has hundreds or thousands of fonts on his machine, getting to the right font can be an annoyingly slow process. The fonts are shown in alphabetical order, except that for some reason the highlighted "Aharoni" font appears after the Chinese and other non-Latin Unicode fonts! Also note that the non-Latin Unicode font names appear as gibberish after the two Chinese fonts (AR PL ShanHeiSun Uni and AR PL ZenKai Uni). In this day and age, this is an unacceptably bad design. Perhaps Adobe's newer InDesign product redresses these shortcomings, but I have not had an opportunity to find out.
The font selection mechanism in Adobe Illustrator 10 on the Windows platform is completely unacceptable for a professional graphics design package.
Note also that in Illustrator 10 there is no font preview. This is like choosing colors by name or hex-value without getting to see a preview of the color. Of course other programs do get the font preview part right. For example, both Microsoft Word on OS X and OpenOffice.org Writer (on all platforms) give the user a preview by displaying font names in the font itself, as shown below.
The font selection widget in MS Word on OS X displays font names using the font itself, but does not handle Unicode names properly (square rectangles in the middle of the list).
The font selection widget in OpenOffice.org also displays font names using the font itself, but the preview is uninformative for non-Latin fonts such as the Arabeyes.org "ae_" fonts for Arabic at the top of the list, and the two Arphic Chinese fonts (AR PL ...) at the bottom of the list.
But what is wrong with these font previews? First, in the case of MS Word on OS X, non-Latin Unicode font names are not handled correctly: we see a series of empty rectangles for two fonts in the middle of the list. This is one problem that can occur.
Another problem that occurs even more frequently is that the font preview is uninformative, as illustrated in the OpenOffice.org screenshot. The "ae_" fonts at the top of the list are Open Source Arabic fonts released by Arabeyes.org. The style of the Arabic glyphs is different in each one of these fonts, but as is often the case with non-Latin fonts, the Latin glyphs contained in these fonts are just "fillers". In the case of the Arabeyes.org fonts, the Latin glyphs do not change at all among most of the "ae_" fonts shown, and in any case give one no clue about the shape of the Arabic glyphs.
At the bottom of the OpenOffice.org font selection list, two Arphic Chinese fonts are shown -- one for traditional Chinese (Big 5), and another one for Simplified Chinese (GB). Although the glyphs in both font files are in the same "KaiTi" style, the Latin glyph preview is completely uninformative. Also, one has to have arcane knowledge about computer encodings to realize that the first font listed is for the "Big5" encoding used in Taiwan for traditional Chinese, and the second is in the "Guo Biao" (i.e., GB-2312 or GB-18030) encoding used for simplified Chinese in mainland China. Would it not be a lot easier and more intuitive to simply show the Chinese font names in Chinese where it would be obvious to the reader which contained simplified and which contained traditional glyphs?
Let's investigate two of the world's favorite Open Source graphics programs, the Gimp and Inkscape. We can argue that it is especially important for graphics design programs to "get it right." Do they?
The Gimp version 2.2 has chosen to display just the first letter of the alphabet in upper- and lower-case forms. At first glance, this seems like a very reasonable compromise which insures that the name of the font remains very legible since it is displayed in the standard user interface font while still providing the user an idea of what the glyphs look like. But wait a minute -- the fonts shown here are for Indic languages and Thai, so a preview using the letters "Aa" is once again completely uninformative. The intuitive answer would be to show DEVANAGARI LETTER A U+0905 "अ" for the Hindi font, THAI CHARACTER KO KAI U+0E01 "ก" for the Thai Loma font, etc. Even though the Gimp is now completely capable of handling Unicode fonts for non-Latin scripts, the font selection dialog has not yet evolved to the next logical step.
Font selection in the Gimp appears initially to be a good compromise between maintaining consistency in font name readability while still providing a preview. The only problem is that the letter "A" preview tells the user nothing about the Indic and Thai fonts shown!
In Inkscape, the font names are similarly displayed using the standard user interface font, but there is a separate window showing the text rendered in the selected font. This requires the user to click on a font in the list in order to see a preview of the text displayed in that font. One ends up clicking a lot in order to find the font that is "just right" in a given situation.
Inkscape displays the font list using the standard user interface font but has a separate box where a preview of the text appears.
The verdict? I had been using both the Gimp and Inkscape quite a lot recently when I began thinking about this font selection dialog issue, and I felt neither one provided the kind of font selection I was really hoping for. There was one more place to look: Mac OS X. I figured that if anybody were to "get it right", it would most likely be Apple.
Below is a screen shot from a program called TexEdit Plus which has an option to use Apple OS X's font dialog. One immediate improvement here is the concept of font collections, the idea that fonts should be grouped together. It makes a lot of sense that "fixed width" or "sans serif" fonts should be automatically grouped together by the operating system without the user having to create such a collection, and OS X does that.
At the same time, font collections also need to be user-definable. For example, if you were working on a new graphics project, say a new computer game called "Goth", you would want to choose a collection of "goth" fonts and group them into a collection for your game project. Of course OS X also allows you to do this.
Apple OS X's font selection dialog gets one very important thing right that we haven't seen prior to this: fonts need to be categorized and presented in collections or related groupings. Apple's font selection dialog is being used here in a program called TexEdit Plus.
While Apple got it right by grouping fonts into collections, I still felt that it would be better if I could see glyph samples without having to click on each font name in a list. In other words, I felt that OpenOffice's drop down showing font names rendered in each font was intuitive and effective.
At this point I felt I had done enough research to put forward a solution which combines both of these ideas, as described in the The Solution.
Note bene: Additions to the original proposal based on feedback I have received are printed in brown.
Note bene: New additions related to the the Gnome Live! 2006 Text Layout Summit are in this green color.
Solution for a font selection widget combines displaying font names using the fonts themselves, hierarchal font categorization including nesting, and proper handling of non-Latin Unicode font names, including font name aliases and RTL scripts like Arabic.
The solution that I envision uses a drop-down selection widget with the font names displayed using the fonts themselves similar to the drop-down font selection widget used in OpenOffice.
However, this drop-down selection widget goes beyond OpenOffice's solution by presenting a hierchical menu of font groupings or "collections," to borrow Apple's terminology. Nested groupings would be permitted.
In addition, this widget will handle non-Latin font names correctly, will allow the user to assign aliases for existing fonts, and will handle right-to-left scripts like Arabic and Hebrew properly.
The hierarchical drop down menu should at the very minimum have the following default top-level font groups defined a priori by the operating system:
All Fonts would simply be a list of all of the fonts, no different than what OpenOffice.org's current font selection drop down provides. Other would list remaining fonts that were not classified into the Sans, Serif, or Monospace categories.
Recently Used would maintain a list of the last n (defaulting to 5, the number n would be user-settable) fonts used on either a local (program specific) or global (user specific, but across all aware programs) basis.
Remember, the above merely represents the minimal classification of the fonts. It represents a reasonable classification for users in what we traditionally would call a "Latin 1" environment. (Do not confuse the idea of a Latin-1 environment with the locale. In the brave new Unicode world, everyone (on Linux) should be using a Unicode UTF-8 locale ... ).
Most modern Linux distributions will ship with and by default install fonts that cover many different blocks of Unicode, not just Latin and extended Latin. If distributors utilize information from sites like my Unicode Font Guide For Free/Libre Open Source Operating Systems , they will be able to supply users with a selection of legally-unencumbered, high-quality fonts covering an ever-widening swath of the Unicode code space.
In such an environment, the above scheme needs to be expanded. Ideally, fonts should be automagically classified into appropriate Unicode script categories without requiring manual user intervention.
For example, if a user has Chinese, Arabic, and Thai fonts, the automatically-generated top-level menu categories might now look like this:
Note that in addition to Arabic, Chinese, and Thai, I have added a "Pan Unicode" category to hold fonts like Bitstream Cyberbit, James Kass' Code 2000, MS Arial Unicode, and Michael Everson's Everson Mono Unicode.
The following paragraph and classification of Chinese fonts into Unicode/Simplified/Traditional is now clearly obsolete. A more natural default ordering for CJK fonts is by style. Individual fonts can then be marked with additional icons if the user has chosen to highlight specific orthographies, such as simplified (简体), traditional (繁體), or Hong Kong (香港).
Top-level Unicode-block-based categorizations for fonts covering scripts like Arabic, Japanese, Korean, and Thai should be sufficient in most cases. However Chinese fonts should be automatically sub-categorized as follows:
The same menu in Chinese is:
Unicode (统一码) refers to modern Chinese fonts like Debian Taiwan's Arphic-derived "AR PL ZenKai Uni" and "AR PL ShanHeiSun Uni" fonts which contain both simplified and traditional characters together. Simplified (简体) refers to fonts that contain simplified characters for use in mainland China. These fonts usually use the "GB" (国标 --i.e., GB-2312 or GB-18030) encoding standard of mainland China. Traditional (繁體) refers to fonts that contain traditional characters for use in Taiwan, Hong Kong, Singapore, and overseas Chinese communities. These fonts are usually (but not always) encoded using the "Big 5" standard. As many existing Chinese fonts in widespread use cover only one of the two categories, simplified or traditional, these sub-categories are necessary for Chinese.
Also, it is important to note that in mainland China there are a large number of fonts encoded using the "GB" standard for simplified characters but actually containing glyphs for traditional characters! On first principles, you might say this is "wrong," but that's the reality. This is another reason why the categories should be simply shown as Simplified (简体) and Traditional (繁體) and never as "GB" and "Big 5". Also, requiring computer users to know about arcane encoding systems like "GB" and "Big 5" is an extremely bad practice.
CORRECTION: After thinking about this some more and reflecting on some other comments I received from Yu-ching Chen 陳育青 and others, it might be better to *not* split Chinese fonts into Simplified (简体) versus Traditional (繁體) categories, but rather to just use little icons after the font names to indicate which character sets are supported: 简，繁，or 香港. （香港 would of course refer to fonts that have the additional glyphs of the Hong Kong Supplemental Character Set (HKSCS)). Using informational icons would be consistent with the idea expressed below in the section entitled Icons for Displaying Special Types of Font Information, and would make it possible to group Chinese fonts based on style first instead of on Unicode coverage first, as the following section suggests.
Now a days, amateurs may have hundreds of fonts on their computers, while graphics professionals may have thousands. Western graphics professionals will very likely want to be able to arrange fonts into stylistic categories like script, black letter, modern, ornamental, and so on (as the mockup suggests).
East Asian graphics professionals will likewise wish to categorize their CJK font collections into appropriate stylistic subcategories. Yu-ching Chen 陳育青 has suggested the following classification scheme as a possibility for users with extensive Chinese font collections:
Based on the excellent information at sci.lang.japan FAQ on Shotai (書体), we can classify Japanese fonts as follows:
The following classification is still incomplete, as only calligraphic font styles are treated at present, and even the calligraphic classifications may be incomplete. Nevertheless, something along these lines will apply. This initial classification is based on information from http://www.islamicart.com/main/calligraphy/styles/index.html
An XML schema should be used for storing the user's font selection hierarchical menu. A centralized XML file could be easily used and shared by implementations of the font selection widget on different platforms and programs, i.e., Gnome, KDE, OpenOffice, Gimp, Inkscape, Scribus, etc. This would help provide an additional degree of standardization to the Linux desktop which, as it currently stands, remains an incredible mish-mash with little cohesiveness.
The XML schema might look something like the following:
<fontmenu> <category> Chinese <category> Unicode <font> AR PL ZenKai Uni </font> <font> AR PL ShanHei Uni </font> </category> </category> </fontmenu>
... which would specify the following:
As you can see, sub categories are simply specified using
As previously mentioned, displaying a font preview of a Chinese or Arabic font using the English name of that Chinese or Arabic font is highly uninformative.
Some TrueType and OpenType fonts are distributed with TTF names in languages other than English. 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. In these cases, an intelligent font selection widget could automatically make use of a non-English name when displaying the font name preview.
Most non-Latin fonts however only have romanized names in the Latin script and lack names in the native script. For example, the Open Source Arabic fonts distributed by Arabeyes.org currently only have romanized names in the font files.
A good solution to this problem is to allow for fonts to assume aliases:
<fontmenu> <category> Arabic <font> ae_AlArabiya <!-- THIS ENTRY LACKS AN ALIAS --> </font> <font> ae_arab <alias> عرب </alias> </font> <font> ae_khalid <alias> خلد </alias> </font> <font> ae_tholoth <alias> ثلث </alias> </font> </category> </fontmenu>
This snippet of XML would produce the Arabic font sub-menu exactly as shown at the bottom of the mockup widget illustrated at the top of this page.
As shown in the mockup at the top of this page, font names or font aliases in right-to-left (RTL) scripts such as Arabic and Hebrew should automagically cause the menu bullets and category arrow-heads to appear on the right side instead of on the left side. The category arrow-heads and bullets would also be indented to the proper nesting level now starting from the right instead of from the left, just as shown above for the Arabic example.
Of course the Arabic example above shows a "mixed" case where some entries like "ae_AlArabiya" are in Latin script, and thus the bullet is on the left, while the remaining are in Arabic script with bullets on the right.
Some will object and say this looks bad and that the decision to have a consistently left-handed or right-handed menu should come from the system LOCALE setting. I say that is not necessary and that it actually looks better to have the Latin-script names in a left-handed menu and the Arabic names in a right-handed menu. And if you don't like having the word "Arabic" and the font name "ae_AlArabiya" in a left-handed menu, then just type in the Arabic aliases for all entries in the Arabic submenu, including the category title itself --and voila! You will get a completely right-handed menu just for the Arabic subsection. And it will look fantastic.
The only aspect of the font selection widget that should change depending on locale is the handed-ness of the drop-down button, "", which should appear on the left side in Arabic and Hebrew locales.
Some might ask what should the menu behaviour be in the case of a font name or font alias written in a mix of Arabic and Latin or Hebrew and Latin? This can be considered an extremely rare edge case in which case the default LTR behaviour would be sufficient. Most people will be consistent and create font aliases using only one script or another, not a mix of two. I don't think it will be an issue.
Type icons indicate font file type.
As shown in the mockup, icons can be used to display whether a given font is a TrueType, OpenType, Postscript, or bitmap font:
Displaying type weight and style iconically. One could optionally display font weight and style (normal, bold, italic, bold italic) as shown in the top row. Other weights such as extra light (XL) and extra bold (XB) may be of interest to professional graphic artists (bottom row).
An option might be made available to show iconically whether a given font is available in other weights (such as bold or extra light), condensed form, or italic/oblique form.
Fonts for Western scripts like Latin and Cyrillic are often produced in the four common variants of normal, bold, italic (or oblique) and bold italic (or bold oblique) and it would not be difficult to display the available font weights and styles iconically (top row in figure on the left).
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.
The mockup below provides an idea of how the font selection drop-down might appear with this additional information displayed. Also note how much better looking and more effective the Arabic sub-menu is now that Arabic font name aliases have been used to replace all of the original romanized font names.
Font selection Drop-down showing optional information about available font weights and styles. The Arabic sub-menu has now also been completely converted to Arabic by using aliases to replace the original romanized font names.
Special Type Icons could be used to display vertical layout capabilities in CJK fonts (left) or extended orthographic capabilities in Arabic fonts for Farsi and other languages (right).
Besides being able to iconically display whether a font has bold or italic variants, other more specialized information could be shown for certain audiences of users:
CJK fonts: Some CJK fonts have vertical advance information required for vertical layout, and some do not. CJK fonts with vertical layout capabilities could perhaps be shown with an iconic "垂".
Arabic fonts: Some Arabic fonts have glyphs for additional letters like pe U+067E پ and gaf U+06AF گ needed to write Farsi, Dari, Tajiki and other languages. An iconic gaf گ could perhaps be used to display Arabic fonts with these extended orthographic capabilities.
The previous description of how special icons should be used is almost but not quite right. It is true that the user should have the option of highlighting special font capabilities using additional icons. Highlighting CJK fonts with vertical layout capabilities by using an iconic form of "垂" is a good example of this capability.
But the example for Arabic fonts needs to be revised and extended to a more general case. In general, the user should be given the opportunity, in a management panel, to specify an ordered set of orthographies which he or she would like to highlight. Fonts capable of rendering these orthographies would then be marked in selection widgets. Little icons would be required for highlighting. In regional markets where politics was not an issue, little national flags could be used (i.e., just as the KDE desktop by default uses little national flags to display the active keyboard when multiple keyboard layouts have been enabled). In some markets politically-neutral icons would be required.
For example, using the Arabic script again, an Urdu user could choose to highlight the subset of fonts that are capable of displaying Urdu. Moreover, the display of Arabic fonts would then be automagically ordered within the selection widget to display Urdu-capable fonts first --unless, of course, our Urdu user had placed some other Arabic orthography first in his ordered set of highlighted orthographies.
Let's add just a little to this to make it perfectly clear how I imagine this would work. The previous section entitled Arabic Font Styles suggests that Arabic fonts would, to the extent possible, be placed into categories like Diwani, Kufi, Naskh, etc. (Such categorization would be done automatically if possible, and manually as otherwise required). Indeed, this would apply in the case of our Urdu user's desktop too. So, when our Urdu user drilled down into, say, the Naskh category, he would find that the Urdu-capable Naskh fonts would be at the top of his list. Which is most likely exactly what he would like.
INSERT IMAGE OF MOCKUP MANAGEMENT PANEL FOR SELECTING AN ORDERED SUBSET OF PREFERRED ORTHOGRAPHIES
We can imagine however that the above description of our Urdu user's font selection widget represents only the default arrangement. Other arrangements would be possible too. In fact, the whole list of fonts should be sortable by any arbitrary set of available keys.
What is meant by available keys? The available keys would be any of the bits of metadata
collected on each font as represented in the implementation of the
FontInformation class object.
For example, the
FontInformation class should have a member for
_license as well
as, say, a boolean member called
_hasAlternateForms. So, if the user wanted to see his OFL
fonts which contained optional alternate glyph forms, he could have these sorted at the top of the selection
It helps here to think of the collection of fonts as belonging to a structured database where all the meta-information
is stored in
FontInformation objects. The default arrangement of fonts is more-or-less what one
would get, in an SQL system, by executing
select * from fontDatabase order by script, style, orthography.
That query would give our Urdu user his Urdu-orthography fonts listed first within each style category (Diwani,
Kufi, etc.) nested within the script category for Arabic. That represents the default.
In order to see OFL fonts with alternate glyph forms, the query would be along the lines of
from fontDatabase order by license, hasAlternateForms instead.
Modern graphic designers will have thousands of fonts on their machines. While the default arrangement of fonts in the font selection widget should be designed to meet most needs in a very natural and intuitive way, finding just the right font as quickly as possible would be easier to do if the user always had the option of sorting by any set of arbitrary keys. How to make that possible within the confines of a drop-down selection list, even one as capable as suggested here, will require some additional creativity in GUI design.
Although a font preview using the name or alias of a font as shown in the drop-down list provides a nice initial view of a font, one often also desires to see a preview of an actual snippet of text from the document formatted in the selected font. Alternatively, one might want to use a pangram like "The quick brown fox jumped over the lazy dog" to get a better idea of all of the glyphs in a font.
In programs like Inkscape, a snippet of the document text is styled in a preview window in the Text and Font dialog when one clicks to select a font.
Here I would like to advocate an approach that will work more successfully with the proposed drop-down widget: a "tooltip"-style popup preview. Hovering the mouse over any font in the list long enough would automatically pop-up the preview.
The text used in the "tooltip"-style popup could be from one of two sources:
1. By default, the beginning snippet of the document text selected for formatting would be used. For example, as illustrated below, the beginning of the document quote from Thomas Jefferson, "The light which has been shed on mankind by the art of printing ..." is shown.
2. An alternative could be provided to show a pangram like "The quick brown fox jumped over the lazy dog". This could also be used in cases where no text in the document had been selected. (Note that the software needs to be smart about internationalization when using a pangram. If the user hovers over a Chinese font, a Chinese "pangram" should be used. I stand corrected: it is kind of difficult to make a Chinese pangram. A representative Chinese phrase or sentance should be used. Pangrams for different scripts could be defined in the XML config file, and by default a number of stock pangrams for common scripts should be supplied.)
"Tooltip"-style popup font preview provides the opportunity to view a longer, more complete sample of text formatted in a selected font when one simply hovers the mouse over a font long enough.
Akkana Peck has pointed out that tooltips over menu entries can be annoying when they pop-up and inadvertantly obscure other items in the menu. There are several possible solutions to this problem:
1. Control the x coordinate of the popup to insure that it always occurs sufficiently to the right of the drop-down menu (or to the left in Arabic, Hebrew, and other RTL script locales) so as to never obscure the other menu entries.
2. Make sure the timer on the pop-up is long enough to not be annoying, regardless of where the popup is placed.
Or, my new favorite solution:
3. Simply allow the user to RIGHT-CLICK to request an extended preview. This functionality could exist in addition to a timer-based popup with a fairly long delay (say a 5 second delay). Users would have the option of turning off the timer-based behaviour, in which case RIGHT-CLICK would be the only way to get an extended preview. Both timer delay and the option to turn off timer-based pop-ups would be set in the XML file. The default would be to have timer-based extended preview pop-ups set to ON.
As noted earlier, pangrams do not exist for Chinese, but one can use a representative phrase or sentance instead. However, another problem is that Chinese can be written using either simplified characters (简体字 used in mainland China and in Singapore) or traditional characters (繁體字 used in Taiwan, Hong Kong, and overseas Chinese communities everywhere). With the huge increase in global communication in recent years, mainland and overseas Chinese alike have an increasing need to access and use both styles of characters.
Yu-Ching Chen 陳育青 has come up with a good solution which addresses the font preview aspect of both of these issues:
The character "永" (U+6C38 "forever") is a "pan-stroke" character often used in teaching Chinese calligraphy. It contains the eight basic Chinese stroke forms (point 點, horizontal line 橫, vertical line 豎, hook 鈎, kick 挑, long slash 撇, short slash 短撇, and long backslash 捺) and thus provides a good idea of the visual forms that may appear in the glyphs in a Chinese font.
For the pop-up font preview, an enlarged character "永" can be combined with a sample sentance or phrase printed in both simplified and traditional forms, as shown below.
"Tooltip"-style popup font preview for Chinese displays the model calligraphic character "永" in enlarged form along with an example displayed in both simplified (简) and traditional (繁) forms. The example shown here is a short poem from the fifth chapter of Dream of the Red Chamber （紅樓夢第五回）.
The hierarchical drop down font list may be quite long, possibly even when completely "collapsed" and showing only top-level categories in the event that there are many top-level categories defined. The traditional solution, used by both OpenOffice and the Gimp, for example, is to display a subset of somewhere between 8 to 15 entries in the drop-down pane with a vertical scrollbar.
Perhaps the number of entries to display at one time, n, could be another user-settable parameter in the XML configuration file. A default value of 12 seems reasonable to me.
Some users are very fond of being able to type just the first few letters of a font name in order to have the selector jump to the first matching font. This should be supported. Developers would need to insure that matching occurred on Unicode strings using either the font names or font name aliases, either of which could be in non-Latin scripts like Arabic, Chinese, or Thai.
Modern fonts with Unicode CMAPs ("Unicode fonts") cover various blocks of Unicode, and one or more blocks of Unicode provide coverage for a "script".
A couple of problems may occur. First, earlier I suggested that the software automatically categorize Thai fonts as Thai, Chinese fonts as Chinese, Arabic fonts as Arabic, and so on. But what happens when a "Chinese" font also provides complete coverage for Latin, extended Latin, Greek, Cyrillic, Hiragana, and Katakana? This is one problem.
A related problem might occur when we want to have the proposed widget display an extended font preview using a pangram, example sentance, or other appropriate example string that would highlight glyphs from the font. If a font covers multiple scripts, how does the software decide which script pangram or other appropriate example string to use for displaying the font preview?
Let's examine how we might get some meaningful answers to this problem that will at least help guide us in the right direction, even if final answers remain as yet shrouded in mist.
First, we can group Unicode fonts based on script coverage as follows:
Grouping Unicode fonts by script coverage.
Starting from the right side of the above chart, let's examine the
easy cases first. There are of course fonts that
cover a single script. In the chart, I have shown a few
Indic and Indic-derived Unicode fonts. These fonts do not have Latin
glyphs. They basically cover a single block of Unicode, maybe with
some Western punctuation or other diacritical marks thrown in, and are
easy to classify. For example, fontconfig's
utility would (presumably) show that the MalithiWeb font is
good for Sinhala and nothing else. Thus, MalithiWeb could be automatically
placed into a "Sinhala" font category, UniBurma into a "Burmese"
category, and Kalimati into a "Devanagari" category.
What about Latin fonts? Latin fonts run the gamut from the typical ASCII-only art font to more sophisticated modern fonts with coverage of ASCII, extended Latin blocks, and maybe even the IPA. How should these fonts be handled? I suggest that, in all cases where the user's locale uses the Latin script, a pangram appropriate to the user's locale be used to display the extended font preview. (This is just the standard software localization practice, nothing new here ...).
For example, suppose a you live in a french locale. A nice french pangram is "Voix ambiguë d'un cœur qui au zéphyr préfère les jattes de kiwis." If a font preview of this pangram showed a few rectangular boxes or missing glyphs like "Voix ambigu d'un cur" --well, this obviously tells you right away that the font will be of limited use for high-quality french typography. This is probably exactly what you wanted to find out.
A huge number of fonts have been designed to cover a non-Latin script but also provide Latin and in some cases extended Latin glyphs too. Some relevant Open Source examples are the Arabeyes.org fonts for Arabic, the Tibetan and Himalayan Digital Library (THDL) Tibetan Machine Unicode font, and NECTEC's Loma font for Thai. What is most important about these fonts is not that they cover Latin at all, but rather that they cover Arabic, Tibetan, Thai, or some other script.
These fonts should be appropriately categorized based on the non-Latin script that they cover. Intelligently-designed software should be able to handle this case without difficulty.
Pan-Unicode fonts like Bitstream Cyberbit cover a large number of scripts encoded in Unicode. At first glance, these fonts should not be difficult to classify. However, a problem may occur with CJK fonts being mis-classified as "Pan Unicode" fonts. Many CJK fonts provide fairly good coverage of not only the unified CJK characters, but also of Latin, Greek, Cyrillic, Hiragana, and Katakana. Other blocks like BoPoMoFo may also be covered. As humans, we can see that the glyphs in the Latin, Greek, and Cyrillic blocks of these fonts are often of poor quality compared to the CJK glyphs. But software cannot make this kind of distinction. Such fonts may easily be misclassified, or perhaps we should say "less than ideally classified" as Pan-Unicode fonts.
A possible solution to this problem may be to examine the TTF Names in the font. If a potential "Pan Unicode" font contains TTF names in Chinese, it is very likely a Chinese font. This would be useful for another reason too: If a Chinese TTF name string contains the character "繁", then it must be a font containing traditional Chinese glyphs even if the encoding is GB-xxxx for simplified Chinese.
When a user has fonts for different scripts installed on their machine, the font management and selection system proposed here categorizes those fonts into their respective script categories at the top level. Japanese fonts go into the Japanese category, Arabic fonts into the Arabic category, and Thai fonts into the Thai category. In fact, in order to be completely consistent, let's not forget that Latin fonts themselves need to appear in a top-level "Latin" category.
However an annoying problem occurs with Pan Unicode fonts. Fonts like MS Arial Unicode, Bitstream Cyberbit, and Code 2000 appear repeatedly in almost every script category. The solution I propose is to forcibly relegate all Pan-Unicode fonts into a single special "Pan Unicode" script category by default.
A GUI font management panel would allow a user to selectively control whether such fonts to appear in all script categories for which the fonts satisfy orthographies or not. The font management panel is really a necessity here. For example, by default certainly MS Arial Unicode and Code 2000 would only appear in the "Pan Unicode" category, having been forcibly removed by an appropriate algorithm from the other script categories. But then some other font such as Gentium might also end up in the "Pan Unicode" category -- it all depends on one's definition of pan unicode, doesn't it? Suppose that the algorithm works by saying "any font covering five or more script categories is a pan unicode font." That can easily relegate a lot of the larger fonts into the "Pan Unicode" category. So the user should have an option to check or uncheck individual "Pan Unicode" fonts, thus allowing or disallowing their display in individual script categories.
Implementation of the font selection widget described in this document would greatly improve GTK+, KDE, and similar GUI toolkits and programs derived from these toolkits. Use of a standardized XML configuration file that would span across different toolkit implementations would help to increase uniformity in the look, feel, and font selection behaviour of important Open Source programs such as Open Office, the Gimp, Inkscape, Konqueror, and Firefox on Linux and related Open Source platforms.
This document currently fails to describe how users would customize their font groupings or define font name aliases. In the absence of some additional GUI font management screen, users might be forced to resort to editing the XML configuration file by hand. Perhaps existing font management tools like KDE's KFontInst could be modified to provide the additional support that a more sophisticated font selection widget would require.
I welcome comments and criticisms on this proposal. I would especially welcome hearing from developers who might be interested in implementing this widget, especially in the GTK+ and KDE toolkits.
-- Ed Trager, 2005.09.25
After announcing this proposal, a number of comments began to appear on the mailing lists. For the benefit of those who may not have had an opportunity to see the original posting and responses, I am collecting them here. Corrections and additions based on this feedback are being incorporated back into the original proposal.
The following is a copy of the original announcement sent on 2005.09.27:
=== ORIGINAL ANNOUNCEMENT POSTING === Date: 2005.09.27 From: Edward H. Trager <ehtrager --at-- umich.edu> 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/ === ORIGINAL ANNOUNCEMENT POSTING ===
The following are responses that I have collected so far:
From: PLinnell <mrdocs --at-- scribus.info> Date: Tue, 27 Sep 2005 22:02:41 +0200 On Tuesday 27 September 2005 21:01, gimp-developer-request --at-- lists.xcf.berkeley.edu wrote: > http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/ <snipped> 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 --at-- 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
From: Sven Neumann <sven --at-- gimp.org> Date: Tue, 27 Sep 2005 23:04:58 +0200 Hi, "Edward H. Trager" <ehtrager --at-- umich.edu> 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
Date: Tue, 27 Sep 2005 17:22:16 -0400 From: michael chang <thenewme91 --at-- gmail.com> On 9/27/05, Edward H. Trager <ehtrager --at-- umich.edu> 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.
From: "Robin Rowe" <rower --at-- MovieEditor.com> Date: Tue, 27 Sep 2005 14:24:12 -0700 FYI. Interesting proposal below. Seems like a good idea. What's the status of font selection in FLTK 1 and 2? Robin
From: Craig Bradney <cbradney --at-- zip.com.au> Date: Wed, 28 Sep 2005 00:50:04 +0200 On Tuesday 27 September 2005 22:02, PLinnell wrote: > On Tuesday 27 September 2005 21:01, > > gimp-developer-request --at-- lists.xcf.berkeley.edu wrote: > > http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/ > > <snipped> > > 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 --at-- 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 Please remember to consider the case where a user might legitimately have 2000 fonts on their system. In any case, this is a hard thing to handle, but its not an unreasonable thing to expect. Very interesting pages! Craig
From: Akkana Peck <akkana --at-- shallowsky.com> 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
Date: Wed, 28 Sep 2005 01:42:32 +0100 From: "Alastair M. Robinson" <blackfive --at-- fakenhamweb.co.uk> 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
Date: Wed, 28 Sep 2005 11:01:50 +0900 From: mpsuzuki --at-- hiroshima-u.ac.jp 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.
From: Keith Packard <keithp --at-- keithp.com> Date: Wed, 28 Sep 2005 05:28:54 +0300 On Wed, 2005-09-28 at 11:01 +0900, mpsuzuki --at-- hiroshima-u.ac.jp wrote: > Hi >=20 > 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. >=20 > There are a few problem: >=20 > 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
Date: Wed, 28 Sep 2005 13:09:06 +0100 From: "MacArthur, Ian (SELEX) (UK)" <ian.macarthur --at-- selex-sas.com> Mr Trager (Ed?) Excuse the interruption... Was reading you note on "Designing a Better Font Selection Widget." Seems= like a sound idea. Unfortunatley I don't have the skills to help. And I *know* I don't have the skills, because I tried to do this in the= past... One thing that occurs to me, though: I tried using the fonts to render= their own names, so you could see what they looked like. This was= generally a Good Thing. But... in the case that the font is one of these "dingbats" type fonts, the= result can be, erm, variable, as these seem to have non-letter glyphs in= the "usual" latin code places... So, you can render the name, but not actually read it... Minor point, probably doesn't matter. And I'm probably missing the point totally anyway! Cheers, --=0D Ian MacArthur
Edward G.J. Lee 發表於星期日 十月 23, 2005 2:55 pm Re: 選擇字型的新建議 >車藹 寫到: >你們大家好， >2005年09月27日我發表了一件“Designing a Better Font Selection Widget"的英文建議而送到下面的 mailing lists: 的確，能顯示中文字的「形」是最佳的方式，有中文的例句更好(tooltip)。 但這除了應用軟體支援外，字型本身在設計時也是要有提供才行。 引言回覆: >我最想要知道： > －中國人想怎麼分中文的字型最好？ 這個可能不太容易有統一的分類法。因為中文字型的發展是歷史演進而來的， 並不是字型設計之初就有這種分類，所以，不容易使用 serif/san serif 的 分類方法。不過，在： http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/#theSolution 中關於： Chinese 中文 * Typographic fonts o 明體／宋體 o 仿宋體 o 楷書 (standard style only) o 黑體 o 圓體 * Calligraphic fonts o 篆書 o 隸書 o 楷書 (include all styles) o 行書 o 草書 * Stylized o Other fonts ... 似乎是不錯的分法。 引言回覆: > －中文沒有“pangram”，就應該用什麼為 tooltip 上的列句？ 中文非由字母組成，是由部首、筆畫組成，如果把部首、筆畫比擬成字母的話， 光部首就有 214 個，所以，實際上的 “pangram” 恐怕也會非常龐大。 或許，可以由中文字的組合及造形種類上來達成類似的 “pangram”？例如： 『春朝暫衝國，自小今申年』 分別代表： 1. 上下組合成的字。 2. 左右兩邊組合。 3. 左右和上下組合。 4. 左右或上下三分組合。 5. 造形為正方形的字。 6. 長方形的字。 7. 三角形的字。 8. 菱形的字。 9. 六角形的字。 10. 五角形的字。 _________________ L.G.J.