Controversial: Digital Masochism?

blokland's picture

After the release of DTL OTMaster, the Robothon 2009 organizers kindly invited me to give a short talk on OTM at their conference. I will do that directly at the end of the Robothon conference on Friday 6 March at 15.00 hours in my classroom at the Royal Academy in The Hague.

At 16.00 hours the Gerrit Noordzij prize 2009 will be presented, so I don't have too much time and it will be an informal presentation. Nevertheless I would also like to discuss a subject that could be considered somewhat controversial: why should anyone spend time on for instance developing functionality that already is available off the shelf, or spend time repairing improper font data if this can be generated more correctly at the first place, or using command line tools if certain functionality can be added to the font data more easily?

These are questions that I ask myself for quite some time now and I find it difficult to come up with answers. So, the audience on the 6th perhaps can enlighten me and I reckon some of the Typophile readers will do here also after reading the following.

OTM has many functions, and one can use the program for instance for checking and improving data. Personally I prefer to limit 'after-editing' as much as possible. Basically everything that shows up in OTM that should be proper in the first place, is corrected at database level over here. Re-generating the fonts with for instance an update of FontMaster should not imply that the same corrections have to be made again; one has to keep up a production administration that is complex enough already.

For instance corrections made in the Naming Table in OTM should be applied to the UFM file that is used for generating the font in question also. So, it will be possible to read in an UFM file before editing a font in OTM in the near future.
If the font-data itself contains improper elements, FM is immediately updated, of course.

FM is only further developed for Windows nowadays. For some font producers this seems to be a problem, because they are completely Mac oriented. For me it is difficult to believe that one can produce fonts professionally without a thorough knowledge of the Windows platform, especially when Boot Camp, Parallels and VMware Fusion (or even CrossOver) make it easy to run Windows apps on a Mac.

Consistency and reproducibility are in my opinion the keywords for the professional font production. Over time I have seen many topics on this forum in which all kinds of issues were discussed concerning the stability of the font editors used, and the struggling with scripting to circumvent limitations. Sometimes I wonder what the goal is: producing fonts or just the juggling with limitations, scripts, bugs, et cetera, or even re-inventing the wheel?

I can understand, that it is difficult to radically change a work flow, but why are people doing all kind of things to achieve something that can be done by other software already or even automatically? Is it Digital Masochism?

Frank E. Blokland

Randy's picture

Nick would you like some tea?

James: Exactly.

Nick Shinn's picture

Thanks Randy, it's just gone 4:20 here.

blokland's picture

Now it looks like everything has been said, it is time for a summary.

My main two points for starting this topic are:
1. Technically skilled font developers don't necessarily have to do additional stuff like scripting because relative complex functionality can be used off the shelf in a simple and economical way.
2. Non-technically skilled font developers don't necessarily have to do additional stuff like scripting because relative complex functionality can be used off the shelf in a simple and economical way.

Overlooking the reactions, I can conclude that I hardly succeeded to convince my audience. There seem to be a couple of arguments for this:
A. Relatively simple stuff like for instance command files in readable English is considered complex still.
B. There seems to be a preference for a mainstream 'one-program-fits-all' approach.
C. The price tag.
D. The offered options don't fit the current work flow.

A. Basically I don't think it is possible to make the control over extensive batch functions much easier than it is in the DTL FontTools. As the trade of the font producer is and has always been anchored in technology, it is inevitable that to a certain level technical control and insight are necessary. Although type designers sometimes may see font technology merely as a vehicle for their designs, the existence and the success of a type design relies for a part on the vehicle itself.

B. One would expect especially from (type) designers the attitude to widen the horizon whenever possible and to look for the best available options to solve certain problems. How does one want to persuade a potential customer to use a new typeface instead of for instance the mainstream typefaces Times New Roman and/or Arial, if one himself is not willing to look further for improvements and innovations?
Of course, one can wait for certain functionality to become available in the preferred 'one-program-fits-all' in time, but if this implies that in the meantime concessions have to be made concerning certain functionality in produced and delivered products, I wonder if this is a sensible approach.

C. Looking at the discussions about pricing and the relative small amounts of money that are subject, I can only conclude that the economic crisis is structural in (parts of) the font business. Furthermore, if developers are reluctant to pay for software, how can they expect people to pay for their products?

D. If changing a work flow does not improve things and is not costs effective, one should not do this, of course.

Concerning the DTL FontTools web site, I will review the texts again, but one can hardly expect from the Dutch Type Library that we make things similar to what others do. To be honest, I am not sure if changing the web site would really be of importance, because Light versions of the DTL FontTools with sufficient documentation are available for testing already.
Concerning Learn FontMasterUtilites Fast, one should ask Leslie Cabarga, I reckon.

Anyway, it is time for me to focus on the font production again. Thank you very much for all your comments.

Frank E. Blokland

Nick Shinn's picture

Frank, you're not helping your cause by inferring that I am A unprofessional*, B unadventurous, and C cheap and hypocritical.

*Productivity is not the same thing as professionalism.

There is a distinction between professional services and professional products.
Certainly, a professional font technician should be expected to know all about batch processing.
However, considering a font as a professional tool, its quality is not dependent on the amount of batch processing involved in its production.

Nonetheless, I will be attending the workshops at TypeCon this year, so there's hope for me yet.

hrant's picture

The less our heart is into something, the more we try to nonetheless get good results while avoiding it. And usually we succeed well enough. There is no singular optimal method.


xo's picture

I'm not a person of many words, so I'll state my opinion rather briefly:

If I think I can do it better, and I'm willing to put in the effort to do so, then I see no reason why I can't.

Jongseong's picture

This thread was a good read. I'll remember to consider a wide set of tools and think about what workflow would be suitable for me if I were to get serious about making fonts. Being interested in CJK font development, I've lately been thinking about the limitations of the all-in-one font development software, so I'll definitely explore the modular options.

Christopher Adams's picture
The DTL FontTools FAQ contains this gem:
Is DTL OTMaster a tool only suitable for techies?
Although extensively equipped for font spelunking, OTM can also be used for tasks more on the surface like changing font names and adding characters (or even logo's) to fonts. So, the answer is no.

[Emphasis added]

Font spelunking is a great term of art.

Christopher Adams's picture

For those unable to find their way, the OTM manual provides a helpful map:

Syndicate content Syndicate content