This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature

Fonty Python and the Holy Grail of a font manager

By Bruce Byfield on April 20, 2007 (8:00:00 AM)

Share    Print    Comments   

For designers, a font manager that can activate and deactivate fonts on-the-fly is the Holy Grail of the GNU/Linux desktop. Without such a tool, designers either need to devote an inordinate amount of system memory to their font collections, or else install and uninstall fonts individually, manually keeping track of the fonts needed for each project. The trouble is, no still-viable font manager has reached a 1.0 release, or even an advanced beta. So far, the closest candidate is Fonty Python, currently at version 0.2.

Fonty Python groups fonts into collections that it calls pogs, which can be installed or uninstalled for the current user account. As soon as the fonts are loaded, they are available for use by other programs.

Unfortunately, despite this basic functionality, Fonty Python has two drawbacks. To start with, it works only with TrueType fonts; PostScript and OpenType formats are not supported. At the bottom of the Help page, Donn Ingle, the developer of Fonty Python, admits, "I know nothing at all about Type-1 fonts and all the other weird fonts out there. I can include support for other formats only if I get some help/code/information about them."

For another, the unconventional layout of the Fonty Python window is awkward to use. Users must start by creating a pog -- an unnecessary piece of jargon if there ever was one -- in the right pane of the window, then go to the left pane to choose a file directory on the hard drive. If the directory has any TrueType files, they display in the middle pane, where users select each font to install by clicking on the panel in which it is displayed. If the directory has more fonts than the middle pane can show at one time, users change the display not by scrolling, but by using Forward and Back buttons. Then users have to select the pog in which to install the fonts from the top right pane, then click a button at the bottom of the middle pane to install the fonts to the selected pog. However, before they can use the font, they have to return yet again to the right pane to install the pog.

Poor alternatives
A Web search reveals the beginnings of several font managers. An early version of Choosefont, a font viewer, was released with a readme file that suggested that "in the future Choosefont might also have capabilities to install and remove fonts," but the last activity listed on the project's SourceForge.net page was more than three years ago. Similarly, although Hamster Font Manager reached a 1.0.2 release, it has apparently not been updated for eight years, and requires a copy of tixwish that is incompatible with any available from the Debian archives.
In short, Fonty Python's requires users to jump around the window, use non-standard controls, and go through too many steps. Its interface is in drastic need of an overhaul, and only tolerable in the absence of anything better to use.

Still, to be fair, Fonty Python is a one-person project. Ingle has prepared guidelines for contributions to the project, but, so far, no one has stepped forward to help. As a result, progress on the project is slow.

The KDE4 Font Installer

Another project that shows promise is the revised KDE font installer scheduled to be included in KDE4. Craig Drummond, the developer behind the software, created a KDE3 version of the changes to "harvest opinions," he says, but it is no longer available, and Drummond's attention is focused on KDE4. Currently, the only way to test the changes is to compile KDE4, which is inadvisable for designers needing to do serious work.

According to Drummond, KDE's new font installer will have two modes. The basic mode will simply allow users to install and remove both system and personal fonts, while Font Management mode will allow users to create groups of fonts and enable and disable fonts. It will also have a number of utilities, such as tools to find duplicate or corrupt fonts, and to download new fonts from a special site. In both modes, the installer will have a view that will be filterable by file name and location, and a font view that will show the Unicode character table.

Future prospects

As a complement to projects like Scribus and Inkscape, a fully developed font manager would be a small but vital piece of functionality that would assist in attracting designers to the desktop. The lack of a GNU/Linux font manager is especially frustrating, given that it is a project with limited scope that could be developed in a few months of concentrated effort by one or two programmers.

At least now, the end of the wait is in sight. The changes to the font installer in the KDE Control Center that are scheduled for KDE4 may be what designers are waiting for. Given that a proof of concept version has already been made, and that Drummond reports that much of this functionality already exists, KDE4 will almost certainly include the first complete font manager for the desktop when it is released in October 2007. Meanwhile, unless Fonty Python manages another release with support for other font formats, designers will just have to wait.

Bruce Byfield is a computer journalist who writes regularly for NewsForge, Linux.com, and IT Manager's Journal.

Bruce Byfield is a computer journalist who writes regularly for Linux.com.

Share    Print    Comments   

Comments

on Fonty Python and the Holy Grail of a font manager

Note: Comments are owned by the poster. We are not responsible for their content.

One step is too many

Posted by: Anonymous Coward on April 21, 2007 04:00 AM

Fonty Python's requires users to jump around the window, use non-standard controls, and go through too many steps.


One step is too many. Microsoft Windows doesn't require users to know what a "font" is. Desktop Linux shouldn't either. Text should just look perfect without any action by end-users.

#

Re:One step is too many

Posted by: Anonymous Coward on April 21, 2007 08:13 AM
We're talking about designers, not Joe Sixpack. Designers--people who work in programs like Scribus--will very much know what fonts are, and in fact they will have particular ideas about which fonts they want, and when.

For the average end-user, Linux fonts are as simple as on Windows.

#

Re:Dev's response to article.

Posted by: Anonymous Coward on April 22, 2007 12:25 AM
Keep up the good work -- font management on Linux is very important (not just for designers, etc... but for any scholars/students that work with multi-lingual/classical texts)!

Fonts just seem to pile up real easy > keeping them under control in an easy and aesthetic way would be really nice.

Thanks for all your effort in this regard!

#

Re:Dev's response to article.

Posted by: Anonymous Coward on April 23, 2007 09:29 PM
If anyone has *actual constructive* criticism then I'd be glad to hear it.

All criticism is constructive! You've just gotten a lengthy and well written opinion on your work. While I understand that you may not like or agree with the criticism, that does not make it invalid. You can choose to accept it, ignore it or whatever but, saying that the author is wrong in his criticism because you don't know how to make it better demonstrates your shortcomings.

It is your program and you can do whatever you like with it, no one will deny you of that. But, you now have two pieces of constructive criticism with which you can work, if you choose to. You can dismiss them, but, you can't negate them.

#

Re:Dev's response to article.

Posted by: Administrator on April 23, 2007 09:54 PM
All criticism is constructive!

Not if there is no alternative suggested to the problems noted. Just saying "that's bad because it confuses me" doesn't actually inform anyone. Sure, it was interesting to hear the sharp response to the gui, and I have taken a lesson from that, but I can't say what I must do to make the interface better without the *constructive * side of criticism.



While I understand that you may not like or agree with the criticism, that does not make it invalid.

Perish the thought!



saying that the author is wrong in his criticism because you don't know how to make it better demonstrates your shortcomings.

I never actually said he was wrong. I merely defended my pov. Please don't make this bigger than it is.



It is your program and you can do whatever you like with it, no one will deny you of that. But, you now have two pieces of constructive criticism with which you can work, if you choose to. You can dismiss them, but, you can't negate them.

Right. Thanks for the criticism.

#

Project should be renamed

Posted by: Anonymous Coward on April 24, 2007 02:20 AM
Obviously, the name should be Phonty Python (anagrammatically-speaking, that is).

#

Re:Project should be renamed

Posted by: Administrator on April 24, 2007 05:12 PM

Never, you phood trough wiper! I phart in your general direction!<nobr> <wbr></nobr>:)


(BTW - I am Kidding! Only kidding<nobr> <wbr></nobr>:D)

#

Re:Dev's response to article.

Posted by: Anonymous Coward on April 25, 2007 01:48 AM
Nicely handled!

E

#

Dev's response to article.

Posted by: Administrator on April 21, 2007 10:23 AM
While it was nice to see an article on FP, it was a little harsh and seemed to miss the point of what FP is designed to do.

"Users must start by creating a pog -- an unnecessary piece of jargon if there ever was one "

Of course the choice of the word was entirely sane and had nothing to do with the Python spirit... Oh, and 'suitcase' was taken as was 'collection'; I thought 'lump' might do for a while.<nobr> <wbr></nobr>:)

"In short, Fonty Python's requires users to jump around the window, use non-standard controls, and go through too many steps. Its interface is in drastic need of an overhaul, and only tolerable in the absence of anything better to use."

1. The flow is deliberately left --> right. It's by design.

2. It's built for use, not for looks. i.e. it's meant to stay open and let you *manage* fonts.
Sure, you have to make some pogs to use it, but that's kernel to the entire point of the app, so is hardly an issue.

3. I cannot see how to cut down on those "too many steps". You need to *source* fonts from someplace, you need to *view* them and *select* them and you need a place they can go to. That's all FP does, no more and no less. (I decided early-on not to use a context-menu and that reflects in the layout where you can see everything you need.)

4. It has a good command-line interface too, you don't need the gui for a lot of mundane tasks.

So, I'm not sure what kind of app you have in mind, but if you view FP in a practical light then I think you will find it has merits.

There is a fellow developer in France who has helped in many ways, including i18n which is great.

For FP 0.3 I am aiming at Open Type Font support (should be easy) along with improved error handling for oddball fonts with exotic unicode filenames, i18n sorting of lists and a lot of "invisible" stuff like that, the interface IMHO is very functional.

Things I still lack:
1. Any practical way to handle fonts other than TTF and OTF.
2. Some way to "clean up" the mass of fonts that seem to creep-in after a few apt-gets in a modern Linux distro -- I have fonts in my choosers that I never use and I *still* cannot find where they are coming from. Fontconfig stuff hurts my head.

If anyone has *actual constructive* criticism then I'd be glad to hear it.

Donn - FP dev.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya