When it comes to naming, keep in mind that plenty of us are just sending the fonts to someone else who deals with that mess so that we don’t have to.

That said, I think that many type designers don’t know the first thing about DTL products because as we come into the field we learn Fontlab, Fontlab, and Fontlab. Any time I’ve talked to people about DTL software the answer is the same—it’s specialized stuff used by big foundries and too expensive for individual designers. Fontlab hasn’t just taken over the industry by luck; Adam and Ted are out there pushing the software and training users at conferences and online in a way that DTL is not. Maybe if DTL evangelized its software better more people would start using it. Send someone to Typecon to teach a class.

Price is another issue. Fontlab is far less expensive than DTL software. I think that many type designers aren’t selling enough fonts to break even if they spring for the DTL software. The designers who are probably have the knowledge/skill to work around software issues, or they use an ADFKO/VOLT workflow and don’t need to bring more software into the picture. I would much rather spend some time find answers online or by trial-and-error than by dropping €2,000 on Fontmaster or even just €255 on OTM.

Edit: I’m not claiming that the DTL software is not worth buying, simply pointing out that one must be selling a lot of fonts to afford it.

I can't speak to the reasons, perhaps masochistic, why others might want to be repeatedly editing font data that could, and probably should be managed via a single data source. I do know why I value having a tool like OTM that gives me direct access to the internals of sfnt format tables. Because one of our principle clients has delivery requirements that include VTT and VOLT sources, this means that the formal source of any font at some stage becomes a TTF with VTT and VOLT private tables. Although outlines and initial table data originate in FontLab, as soon as we move close to a beta version of the font, the TTF becomes the source. This is what is shipped to the client, who look after final compilation from VTT and VOLT and shipping. In addition to our own fonts, we also sometimes are updating existing fonts for the same client and, again, the sources are TTF files. This means that we have to edit some data directly in the TTF tables, because there is no external data source.

I've taken various approaches to this over the years, including creating and managing external data sources via TTX. And when we had to process 500 fonts in multiple formats in the late '90s an external data source was essential scripted (FontLab-to-spreadsheet-to-FontLab). But since most of the time I am working with only a small number of fonts at a time, I find it often easiest to go in and edit the tables directly, with a tool like OTM or FontChef, rather than editing an external data source and then run through an automated update procedures.

James:
'[...] plenty of us are just sending the fonts to someone else who deals with that mess [...]'

Sometimes I get the feeling that people in the font business have to act for a living like the two male musicians in the brilliant Pixar animation One Man Band. I reckon that also much profit vaporizes in case hired 'command line wizzards' have to deal with font naming and other technical issues that should not be to difficult to handle in the first place.

'[...] Fontlab hasn’t just taken over the industry by luck [...]'

Mostly that is true, I reckon, although we were at some stage somewhat unluckily hampered by a compiler, which was not updated to support OS X. Nevertheless Adam and Ted and the others did a good job, that's for sure.
The DTL FontMaster tools are more specialized niche products anyway and ask for a different approach from the user and I don't think that we are actually capable of giving extensive basic support like FontLab Ltd offers.

'[...] Price is another issue. [...]

Although a couple of hundred or even thousand bucks may perhaps look like a lot of money for the end user, a software company that fully relies on the sales has to sell a lot for even providing sufficient support, let alone continuing the development. The market for font editors is not that big and even if a company controls this market, I would not be surprised if it is difficult to have a constant stream of revenues.
Furthermore prices are relative. If for instance Euro 255 is too much for a program that makes editing tables as easy as possible and makes generating 'GPOS' and 'GSUB' tables a piece of cake, I wonder what hiring experts for these jobs costs.
The standard batch support in FM can save a lot of time, i.e. money, of course. For some people the price for the full set perhaps looks expensive, but for this one gets a solid product and basically unlimited support and supply when it comes to command files, features files, kern files, et cetera.

By the way, the DTL Bezier- and IkarusMaster modules are fully functional on their own, have built-in single glyph/single font improvers, batch functionality (metrics, composites, et cetera), can be used to generate 'automatically featured' OpenType fonts (although not in batch) and cost only Euro 382,50.

Anyway, even for those who don't use FM, it is good that there is at least the option of an alternative font editor, i.e. competition.

'[...] Edit: I’m not claiming that the DTL software is not worth buying, simply pointing out that one must be selling a lot of fonts to afford it. [...]'

Even without this edit, I appreciate your comments –as I enjoy any discussion.
Thanks.

John:

'[...] I value having a tool like OTM that gives me direct access to the internals of sfnt format tables. [...]'

Thanks for the nice compliment.

'[...] as soon as we move close to a beta version of the font, the TTF becomes the source. [...]'

That pretty much make sense, I reckon, especially when one can even add and/or edit glyphs in a tool like OTM. This editing functionality will be enhanced in upcoming versions and we even consider turning OTM into a full font editor.

... it is difficult to believe that one can produce fonts professionally without a thorough knowledge of the Windows platform.

That would totally mess up my head.
You must be familiar with Apple's positioning, "think different".
No doubt I sacrifice something in productivity for bearing that burden of otherness, but I don't believe that the quality of the fonts I make suffers as a result.
It was hard enough switching from Fontographer to FontLab.
I've tried AFDKO and Superpolator, but they didn't fit into my workflow.
Right now, I'm extremely comfortable doing everything in FontLab, and that must count for something in terms of productivity.

Nick: '[...] You must be familiar with Apple’s positioning, “think different” [...]'

Thinking differently in this community would result for instance in working with Linux and FontForge. Utterly otherness would imply working with Windows and FM, I reckon.

Frank, it seems to me that you are the masochist by developing a product that is not attuned to its target market, and then slagging potential purchasers for their stupidity in not buying it.

Note that DTL products to date have been available for Mac as well as Windows, and the decision to limit further development to Windows seems to be a recent one, presumably based on experience.

Nick, I think DTL products are well attuned to their target market, which I take to be a particular segment of professional font developers. I'm part of that market, although I currently only use two DTL products (KernMaster occasionally and OTMaster frequently), and I have to concur with Frank that Windows is the primary development platform of this market, both in terms of the platform within which fonts are developed and the target environment in which the fonts are used. Quite simply, I could not make the fonts that I make or provide a service to the clients I have working on a Mac development platform (by which I mean running Mac OS software; running Windows software on Mac hardware is still running Windows software). The Windows font development tools are more advanced and sophisticated than those available on the Mac, as are the layout capabilities of Windows software, notably for complex scripts. I can quite understand, however, how for you, making the kind of fonts that you make and for the kind of customers whom you make them, FontLab on a Mac is a sufficient tool.

As Frank acknowledges, FontLab has been very successfully marketed, and it is also aim at a wider market to begin with. So the relevant question would seem to be why DTL products do not have a larger share within their target market, i.e. the people who would most benefit from the library batch processing and automated build features of DTL tools? I think the answer involves workflow disruption and learning curve issues: using FontMaster requires a fairly substantial rethink of ones approach to font development, and if one has established workflows built around other tools moving to an FM development stream may be a significant undertaking. I think if one had a fairly large library of fonts and made most of one's income from licensing of existing fonts, then this move would be manageable, since the downtime involved would not impact the main source of revenue. But for someone who makes money from producing new fonts on a pretty continual basis, as I do, this would be a challenge.

The Windows font development tools are more advanced and sophisticated than those available on the Mac

John, what exactly do you have in mind? (I trust you aren't referring to FontCreator...)

as are the layout capabilities of Windows software

I am so surprised by these statements that I too would like to know more?

Thanks John.
I was a little off in my comment -- Frank had noted that DTL was addressing a niche market, so I should have more accurately said if that's his market position, there's no point in berating those who aren't in it for not buying his product.

I think if one had a fairly large library of fonts and made most of one’s income from licensing of existing fonts, then this move would be manageable, since the downtime involved would not impact the main source of revenue.

Sounds like me, but I still have reservations that this software is too technical. The Mac-centricity goes pretty deep.

Nick: '[...] if that’s his market position, there’s no point in berating those who aren’t in it for not buying his product [...]'

Although I actually would not mind if this discussion eventually leads to more sales for us, it was not my direct intention starting this topic. I agree with John's statement that 'for someone who makes money from producing new fonts on a pretty continual basis, as I do, this [switching to a FM workflow, FB] would be a challenge'. If such a font tools switch does not result in more (financial) benefits, it simply does not make sense, of course.

What bothers me though, is what sometimes seems to me as a somewhat restricted view on font production and related tools. It would be a good thing for everybody if matters were placed in a broader perspective. The outcome does not necessarily have to be a change of tools and subsequently workflow, but could for instance lead to a more efficient use of the preferred tools. It could even put pressure on the developers of these tools to come up with additional functionality. It is for instance quite possible that some of the things said here, will make me rethink some issues concerning FM, like functionality and policy.

One has to be careful not to base conclusions on a sort of common wisdom. For instance, I love the Mac since my first Plus in 1986 and I treasure Apple as being the last of the original hardware developers, but I always have the feeling that Microsoft does not get the acknowledgement it deserves in the font community because of a very much black and white view on the (historical) development of the Mac and MS OS's.
Having read a couple of books on the development of the personal computer (Fire in the Valley: The Making of The Personal Computer is for instance an informative one), I think that there is at least room for some more nuance. Furthermore, with the direct financial support for type related events by MS and the development of free tools like VTT and VOLT, we should perhaps cuddle (figuratively speaking, of course) Sergey, Simon and others at MS somewhat more.

One general misunderstanding is that FM is very technical. Let me underline that I am a designer with a certain interest for font technology and above all for workflow organization, but I am far from a programmer (and I don't want to become one, like the FM programmers don't want to become designers). I reckon that most people on this list are capable of for instance making AppleScripts like I do.
Handling command files in FM is basically easy and the syntax is very simple. As John pointed out, using FontMaster requires a fairly substantial rethink of ones approach to font development. That is probably the main difficulty.

These are among the Windows font tools we use regularly that are more sophisticated and advanced than anything available on the Mac platform: VTT, VOLT, FontChef, Font Validator, even humble fpEdit and the MS console tools like cacheTT and FastFont. Some of these tools are just nice to have, but others like VOLT and VTT are pretty much essential for the kind and quality of fonts our clients want.

Regarding layout capabilities, the options for working with complex scripts on the Mac remain very slim, and it is notable, I think, that those programs that do enable users to work with complex script text on a Mac (using cross-platform compatible OT fonts, not Mac-only AAT) do not originate from Apple: they are all third party and only some of them are available in compatible Windows versions. Apple have done some good work in recent years providing access to OT typographic layout, but their basic support for many languages and scripts is still tied up in AAT, which I think is a dead-end. In terms of professional graphics and publishing software, there is roughly parity between Windows and Mac, but that is due to Adobe and Quark bypassing the operating system for text layout.

John, I don’t think anyone would argue that for the sort of clientele you have, working with Windows is essential. But most designers don’t have your clientele. And that just leads the conversation a few posts back into what kind of commercial font software market really exists.

Whoa, what a relief. For a moment I thought that you mean the Ventura Publisher ;-)

Handling command files in FM is basically easy and the syntax is very simple.

Easy for you to say, but how are you going to convince someone like me, who has an aversion to code (which I presume is what you mean by "syntax") to grin and bear it?

Nick: '[...] how are you going to convince someone like me, who has an aversion to code [...]'

The rules for the command files language-structure and other supporting files in FM are fairly simple. The following command file generates OpenType Pro fonts with an Adobe Standard Encoding ('PostScript-Number') from all BE files (and related files like UFM and AFM) that are residing in a certain directory.

--------------------------------------------------------------------------------------
# DTL DataMaster 2.5.2 Command File
# DTL Prokyon CFF TPRO
# Last update: 4 December 2006

# Select Character Layout File and Code Page.
CharacterLayoutFile FontProduction:FontMaster:Support_Files:Character Layout files:OpenType:Pro:pro_otf.cha
CharacterLayoutCodePage PostScript-Number

# Set Basic Em-Square.
BasicEmSquare 1000

# Select Basic Format.
BasicFormat BE Format

# Select Basic Font Directory.
BasicFontDirectory FontProduction:FontMaster:Aanmaak:Prokyon:Mac OS:OpenType:Pro

# Select Basic Font(s).
SelectBasicFont all

# Set up Target Directories for all Export Formats.
ExportFontFormat OpenType (CFF)
ExportTargetDirectory FontProduction:FontMaster:Aanmaak:Prokyon:Mac OS:Result:OTF

# Select Export Format.
# NOTE : This will also select the related target directory.
ExportFontFormat OpenType (CFF)

# Avoid Export Font Dialog.
ExportSkipDialog true

# Avoid existing file overwrite confirmation dialog.
OverwriteExistingFiles true

# Start Font Export.
StartFontExport
--------------------------------------------------------------------------------------

This command file generates all Western European PostScript Type1 fonts for DTL Prokyon Condensed:

--------------------------------------------------------------------------------------
# DTL DataMaster 2.6.1 Command File
# DTL ProkyonCon PS Type1 West all
# 19 July 2007

# Activates following command files:
CommandOpen FontProduction:FontMaster:Support_Files:Batch files:Production files:ProkyonCon:PS1 Mac OS:West:ProkyonCon_PS1_All.cmd

CommandOpen FontProduction:FontMaster:Support_Files:Batch files:Production files:ProkyonCon:PS1 Windows:West:ProkyonCon_PS1_All.cmd

# End listing
--------------------------------------------------------------------------------------

by calling other batch command files, such as:

--------------------------------------------------------------------------------------
# DTL DataMaster 2.6.1 Command File
# DTL ProkyonCon PS Type1 West all Mac OS
# Last update: 19 July 2007

# Activates following command files:
CommandOpen FontProduction:FontMaster:Support_Files:Batch files:Production files:ProkyonCon:PS1 Mac OS:West:ProkyonCon_PS1_Standard.cmd

CommandOpen FontProduction:FontMaster:Support_Files:Batch files:Production files:ProkyonCon:PS1 Mac OS:West:ProkyonCon_PS1_Special.cmd

CommandOpen FontProduction:FontMaster:Support_Files:Batch files:Production files:ProkyonCon:PS1 Mac OS:West:ProkyonCon_PS1_SmallCaps.cmd

# End listing
--------------------------------------------------------------------------------------

et cetera.

--------------------------------------------------------------------------------------

Over time I built a hierarchic (and fixed) system to control the DTL library. In FM: Automation at your fingertips I tried to explain the structure somewhat more.

I'm sorry I missed your talk Frank (I was touring the Hermitage at the time).
I think that's suitable outreach to the masochists.
Will you be giving it again at TypeCon?

Nick: '[...] I think that’s suitable outreach to the masochists [...]'

Thanks. At an early stage of the development of FM we discussed the necessity of the support for (Python) scripting. I had my doubts and basically the statement of the programmers was, that most of the batch functions we could think of could be implemented directly and controlled by simple (command) files. So, we decided not to implement scripting-support.

Command files as shown above will be generated automatically by DataMaster when the selections have been made and fonts are generated. The results can be listed and saved. If one uses a fixed system, copying and renaming the command files is enough for further use, of course.

Another example how simple things can be controlled in FM, is generating (unlimited numbers of) composites. The following file shows respectively target position in the glyph database, base character and accent.

-------------------------------------------------
// For generating composite characters
// Version 1.0
// Last change: 29 April 2004 by FEB
// URWNum;URWComp;URWComp
201;101;701
202;101;704
203;101;705
204;101;706
205;101;707
206;101;708
207;101;709
208;101;703
209;101;713
210;103;et cetera
-------------------------------------------------

The dialog can be used for further positioning. One can use different files for different positioning, of course.
 

 
Touring the Hermitage was a good alternative, I reckon. Personally I liked especially the small paintings by Jan Brueghel the Elder ('Velvet Brueghel') there.
 
So far I had no plans for TypeCon, to be honest.

Tracking this thread at the peril of masochistic consumption.
Mostly, trying to just figure out what your product actually does so I can determine if it is worthwhile. I use a pre Intel Mac so I may be just lost anyway.

ChrisL

[Mr Lozos] Tracking this thread at the peril of masochistic consumption.

:D   If you refer to OTM, it says MacOS 10.4 but works on my MacOS 10.3.9.

Being a bit late to the party, I'd like to get back to two early posts:

[Nick] by developing a product that is not attuned to the market

[James] I think that many type designers don’t know the first thing about DTL products because as we come into the field we learn Fontlab, Fontlab, and Fontlab. ... Maybe if DTL evangelized its software better more people would start using it. Send someone to Typecon to teach a class.

Every ATypI conference comes with a FontLab and a FontMaster track, so it is not that FM has no presence at all. For whatever reasons not many people are willing to even have a look. This is something that I don't understand.
A designer should be able to handle, or at least know, more than one tool because it frees one from mistaking tools' peculiarities (or constraints?) for the essence of the product they help create. Just one example: Quite a few Typophile threads about spacing and kerning with FLS classes indicate that people mistake a specific implementation (spacing, kerning, classes, key-glyphs) for a general idea of how letter-to-letter distances are to be defined. Make a step out of FLS and into AFDKO-syntax class kerning and you will notice that there are no key-glyphs -- these are FLS's solution to establish a link between plain kerning and classes. (The key-glyphs' kerning values are "representative" of their classes' kerning values.) Make another step, this time into OT layout table architecture, and you will notice that there is nothing like "kerning" at all but only adjustment of glyphs' placement and/or advance (width). And making some more steps ... the idea of defining letter-to-letter distances by way of sidebearings plus kerning is rooted in an older technology, metal type, and there is no necessity for imitating this either in digital font formats nor the tools used for creating digital fonts. So having a closer look at different tools may reveal the implicit understanding of what we consider as the essence of what we create, and enables us to re-think what we do and re-think tools. What I see today is way too much scratching on the surface.

That James mentions TypeCon but not ATypI is telling, though I am not sure if it means that one gained momentum while the other lost some, or that TypeCon is for Americans while ATypI is for Europeans. Perhaps DTL should consider TypeCon as being equally important?

Karsten, you are right, the TypeCon vs. ATypI issue is important here. As an American on a sometimes tight budget attending ATypI would be an extravagance. Typecon is much, much less expensive.

...something that I don’t understand.

A designer should...

You won't understand it if you think in imperatives based on what is the logical best practice.
As I have attempted to explain by offering myself as an example, there are a lot of Mac-centric type designers from an arts background who are uncomfortable having their work increasingly directed to the left side of the brain, all numbers and code.
Logic may not be the best practice if it hampers intuition and good taste.

the idea of defining letter-to-letter distances by way of sidebearings plus kerning...there is no necessity for imitating this...

It is a tangible metaphor rooted in historical practice, and it explains much about the structure of type glyphs in the traditional genres. That is its necessity, especially so given the predominant conservatism of typographers.

But just because this kind of metaphor (like layers in layout applications) continues to be a necessity, doesn't mean that we shouldn't also experiment and dig deeper with new tools.

My "should" is logical, not imperative, it lays out what I consider a designer. I don't expect everybody nor even anybody to fit into this scheme, yet it is the basis for my judgement.

Chris: 'Mostly, trying to just figure out what your product actually does [...]'

The FM modules, including DTL OTMaster, mostly simplify all kinds of (repetitive) type design and font production tasks. The command files I showed earlier are powerful by themselves, but bundled with the automated features generation, batching the OT production becomes very easy.
As you know, the modified Hatch OpenType tool ('HOT') will remove the features that are not covered by the character set during font generation (see also this PDF on font naming).

To proof yourself how versatile the software is, please download the Light version of OTM (which also contains the modified 'HOT' tool) and open an as large as possible OpenType font. Subsequently go to this Adobe forum page and download the Minion features file that was posted there by Thomas Phinney a couple of years ago.
In OTM Light go to File->Import... and select at the bottom of the dialog Files of type: Adobe DFK features file and select the Minion features file. You will be asked what to import and when done, you can have a view at the outcome in Tools->'GPOS'/'GSUB' Table Viewer.

Please note that the more the character naming in the font used matches the one in the features set, the more features will be generated.

As you can imagine, the same way you can update (and standardize) your OpenType fonts (irrespective of the program used to generate these) with your own standardized features file that covers all possible features.

Thank you, Frank! I will try that.

ChrisL

Frank: As you know, the modified Hatch OpenType tool (’HOT’) will remove the features that are not covered by the character set during font generation

Which is a very nice idea. I was dreaming about VOLT doing this. Ideally, I'd like a switch that tells the OT compiler whether to ignore lookups for which glyphs are not present or, as is the current VOLT behaviour, stop the compile and flag the lookup that references missing glyphs.

Nick: '[...] there are a lot of Mac-centric type designers from an arts background who are uncomfortable having their work increasingly directed to the left side of the brain, all numbers and code.'

Although there always will be room for discussing how much is actually art or plain craftsmanship, at the end type design and font production are industrial design by definition. Perhaps some sorts or lettering can be seen as pure forms of art, but the clear purpose of type, i.e. casting written information in the best possible mould, defines clear requirements and subsequently makes restrictions inevitable.
So, a type designer and/or font producer can't completely circumvent the numbers and code part, but, as I have tried to explain in this topic, many complex tasks can be simplified (basically hidden) by the font production software.

Karsten: '[...] So having a closer look at different tools may reveal the implicit understanding of what we consider as the essence of what we create [...]'
'[...] I don’t expect everybody nor even anybody to fit into this scheme, yet it is the basis for my judgement. [...]'

I highly value Karsten's opinion and I like his theoretical and sometimes even philosophical approaches, especially knowing that he is also a very practical guy. The latter is explicitly proven by Karsten in his OTM Manual, especially in the part where he compactly describes the OpenType Font Tables.
Also I learned to know him as being completely impartial and an independent thinker. And although the first priority is to get one's job done, for future developments it is necessary to constantly re-think matters.

James: '[...] But most designers don’t have your clientele. [...]'

That does not by definition imply that taking at least a closer look at the applications and the layout capabilities John described, could not also be useful for producing fonts for other sorts of clientele than John's. It might perhaps even help to enhance one's business, I guess.

John: '[...] I’d like a switch [...]'

Yes, a switch for either ignoring or reporting lookups for (deliberately) omitted characters makes sense for controlling the consistency of fonts –and has been added to the wish list accordingly.

'[...] a switch for either ignoring or reporting lookups for (deliberately) omitted characters makes sense [...]'

That being said, there is of course the log file: File -> Messages, which will show the 'HOT' info.

Frank,

to address your initial question: there is a number of type design applications: FontLab Studio/TypeTool, FontLab Fontographer, DTL FontMaster, FontForge, FontCreator -- just to name a few. Some cover only a partial task such as AFDKO, VOLT, VTT or ftxenhancer. And there are new coming, such as FontShop's FontStruct, Kalliculator etc. And there is a number of tools we don't even know about (for example custom tools for CJK font development).

But they all meet at one low level: the final font file. If we put Type 1 aside and concentrate just on OpenType/TrueType. Each of those tools has some quirks, also both those tools and the applications in which people use fonts evolve.

For example, right now, the OS/2.TypoLineGap value isn't used by any application that I know of. But at some point, it will start being used -- and then font developers may discover that they originally put wrong values there. The values were wrong but they went undiscovered for years. How do I fix such a problem? Rebuilding the entire font that possibly went through a multiple-application workflow is risky: are you sure that DTL FontMaster 4.0 or FontLab Studio 7 will generate exactly the same metrics and kerning that the versions "–2"? But what if you really want to maintain those, and you only want to fix that one particular problem?

Then, of course, a GUI tool such as DTL OTMaster, or a commandline tool such as TTX, that operate on the final fonts, can be of great assistance.

Also, none of the tools on the market for "high level" type design will ever give you the ability to do "everything perfectly". Some tools may let you do everything adequately, and some tools may let you do a few things perfectly, so you need to combine tools somehow. And then — well, the final font format is the only common denominator we've got.

You write "the statement of the programmers was, that most of the batch functions we could think of could be implemented directly" (my emphasis).

Now, Python is useful for automating tasks, of course, but the really nice thing about this powerful yet simple programming language is that it is what it is: a powerful yet simple programming language. So my experience with Python is: thanks to its support in FontLab Studio, people have implemented functions that we never have thought of. And that is the real joy and power.

FontLab Studio, TransType, FontForge, Adobe FDK for OpenType, FontTools/TTX, Metrics Machine, Superpolator, Remix Tools, FeatureProof — they all use Python, and therefore can all "talk to each other". Now I only wish that VOLT, VTT, Microsoft Font Validator and of course DTL FontMaster supported Python as well :)

A.

Adam,

Although I actually expected you breaking in at an earlier stage, I am pleased to see you commenting now. As I acknowledged earlier, FLS is very well promoted and your debating talent is a formidable instrument for this. But although cleverly formulated, you seem to either cover up or miss some of the points I brought forward here.

'[...] But they ['type design applications', FB] all meet at one low level: the final font file [...]'
That being a fact, the functionality the applications offer, the file structures, the consistency, the quality of the output, workflow options, et cetera, very much differ. The output can be the same in name, but the consistency of the generated font data is simply not identical. Also the offered options to control all factors of the font production are not the same in the available apps, as I for instance have proven in the examples given above.

As far as I know (please correct me if I am wrong), there is for instance no application besides FM that automates the features generation (in batch). And shortly we will release FM with support for the new 2.5 version of the AFDKO (currently FM supports version 2.0), like is already built-in in OTM. What are your plans for FontLab Studio, which currently supports version 1.6? Furthermore the quality of the generated font data by FM is unsurpassed.

'[...] The values were wrong but they went undiscovered for years. How do I fix such a problem? [...]'
In batch I assume, with a text editor. Changing a UFM file is fairly simple.

'[...] Rebuilding the entire font that possibly went through a multiple-application workflow is risky [...]'
I fully agree with this statement and actually it underlines my point that workflows can be unnecessary complex and that it makes sense in some cases to switch to a new less 'multiple-application' one based on a different font editor.

'[...] are you sure that DTL FontMaster 4.0 or FontLab Studio 7 will generate exactly the same metrics and kerning that the versions [...]'
I can't speak for FontLab Studio 7, but I am pretty sure that DTL FontMaster 4.0 will generate the same metrics (the underlying system is in use for more than thirty years now and has proven to be very reliable and consistent). Kerning is a different issue, of course, because normally the kerning is fixed data and a revision would imply a changed font.

'[...] Also, none of the tools on the market for “high level” type design will ever give you the ability to do “everything perfectly” [...]'
Perhaps not, but we come quite close with the FM modules.

'[...] thanks to its [Python, FB] support in FontLab Studio, people have implemented functions that we never have thought of [...]'
A couple of comments in this topic made clear that there are quite some type designers that are not willing or capable of handling 'numbers and code'. So, the additional Python scripting is probably mostly used by a relatively small group of techies. FM offers easy to control (but under the hood complex) batch functionality for all users. Also, additional scripting does not always improve the stability and consistency of the production environment.

Furthermore, I have seen quite some functions programmed in Python, of which we actually already thought of and which are implemented for a long time in FM now.

'[...] Now I only wish that VOLT, VTT, Microsoft Font Validator and of course DTL FontMaster supported Python as well [...]'
I am afraid that you completely missed my point; please re-read my other contributions to this topic ;-).

Frank,

I did not realize that it was an attempt to lure me into a FM vs. FLS debate :) I'm not going to have one.

We do have FontLab Studio 6 in the works that will support AFDKO 2.5 and will have automatic generation of OpenType Layout features. Like in any market situation, the innovation comes from various angles.

For example, in 1996, FontLab 3 was the first commercially available application that could convert hinted PostScript outlines into high-quality TrueType delta hinting and at the same time provided a visual interface for manual hinting (other publicly available applications either permitted completely automatic hinting conversion with no possibility of manual intervention, or they provided a GUI for manual hinting but required the user to always start from scratch). 12 years have passed and not much has changed: FontLab Studio 5 is still pretty much the only application that has this ability while delivering very high screen quality with either no or very minimal user intervention.

Conversely, URW Kernus, and later DTL KernMaster, have been a very able autokerning solution that I believe does not have a match among other applications.

Another example: in 2001, FontLab 4 was the first application that could decompile binary OpenType Layout table code in the Adobe FDK syntax. 3-4 years ago, FontForge added this ability, and now we have DTL OTMaster that also has this feature -- which I think is wonderful (of course OTMaster is a different kind of product, unique in its kind).

Conversely, DTL FontMaster has been able to automatically create OpenType Layout features for some time, and soon FontLab Studio will be able to do that as well.

So, some features are pioneered by one vendor and are later implemented by others. Other features remain distinctive for a long time — there is hardly a chance that there ever will be a one-vendor solution "to rule them all".

I'm very glad that we have several products on the market and that they are in competition. Although I'm particularly refreshed by your notion "Although a couple of hundred or even thousand bucks may perhaps look like a lot of money for the end user, a software company that fully relies on the sales has to sell a lot for even providing sufficient support, let alone continuing the development."

I believe that the problem "between FL and FM" is not that they're direct competitors — but rather that switching between them indeed involves a change of the entire workflow. As I have stated on numerous occasion, I would be more than happy if FontLab and DTL could collaborate more than we compete. I believe that there are enough type designers and font developers in the world who would be willing to purchase tools from both our companies *if* those tools worked together in a reasonable manner.

At the ATypI conference in St Petersburg, I proposed a first step in this direction: a file format that would allow interchange of font sources between various font development applications (FontLab, DTL, FontForge, Robofab etc.). We hope to continue this discussion.

> I can’t speak for FontLab Studio 7, but I am pretty
> sure that DTL FontMaster 4.0 will generate the same
> metrics (the underlying system is in use for more
> than thirty years now and has proven to be very
> reliable and consistent).

Including the "hdmx" (horizontal device metrics) table in TrueType-flavored OpenType fonts? Which was what I was primarily referring to, of course. I would be actually surprised to hear that your screen-rendering-related settings haven't changed at all despite developments such as ClearType. The stability issue is often in the fiddly bits, and it is, by its nature, in conflict with progress. So sometimes, people (users or software developers) have to make choices.

In fact, I have found that balancing out the two directions: "preserve" vs. "fix/improve", with regard to pretty much everything in fonts, has been the biggest challenge when developing FontLab Studio. How to make things better for some users without breaking stuff for others? This is one of the reasons why FontLab Studio has so many bloody options :) But people will see some good changes in this regard soon.

> Kerning is a different issue, of course, because
> normally the kerning is fixed data and a revision
> would imply a changed font.

"Normally", perhaps, but as you probably know, in OpenType fonts, kerning can exist in two forms ("kern" table and "GPOS" table), and there are fonts which make use of both at the same time, there are others that only use one. Also, there is contextual kerning, GPOS extension format and all those new things that change and evolve. There are some designers who are conservative and others who like to delve into the novelty realm.

> ’[...] Now I only wish that VOLT, VTT, Microsoft Font Validator
> and of course DTL FontMaster supported Python as well [...]’
> I am afraid that you completely missed my point; please
> re-read my other contributions to this topic ;-).

I may very well have. Or perhaps, I simply have a different view on this. I have always considered FontLab Studio in two ways: as a standalone product, good as it is, as well as a catalyzer for new developments. As a company, we have contributed (only a tiny bit) to the development of Robofab, and I have helped developers of packages such as FontTools/TTX (Just van Rossum) or Remix Tools (Tim Ahrens) — but the direction in which those applications developed into, the talent they have gathered around them, the new ideas they generated simply left me speechless. I always realized that one centralized entity cannot generate the energy and ideas comparable to a diverse ecosystem. This is why I had my hopes that such ecosystem would develop — and so it happened. FontLab Studio is part of it, and Python is the "aether". It's not just about automation, it's about taking it to a fully new level, being able to tackle design problems from completely different angles, developing alternative user interfaces.

(I wish I could have attended the Robothon conference that is taking place in The Hague, and which is a gathering place of some of the people who are developing bits and pieces of that ecosystem I mentioned. I was struck down by a viral infection, so I had to stay home. But there will be podcasts of the recorded sessions available, so I've heard.)

Best,
Adam

Adam: '[...] I did not realize that it was an attempt to lure me into a FM vs. FLS debate :) I’m not going to have one [...]'
I didn't realize this either, so I am glad that we are not going to have one ;-).

Also I am glad that you underline some of the qualities of FM. It is good to see that some of our inventions become standard, like the automatic creation of OT Layout features, which was part of the first release of FM back in 2002.

'[...] there are enough type designers and font developers in the world who would be willing to purchase tools from both our companies *if* those tools worked together [...]'
Yes, I believe that is true and, as you know, we support your initiative for an interchangeable font format (especially after our nice meeting in the coffee shop in St. Petersburg). As you also know, prior to this development I would like to see the development of a conversion tool for the VFB <=> BE/IK formats as a first step.

'[...] one centralized entity cannot generate the energy and ideas comparable to a diverse ecosystem [...]'
This might be true in some cases, but I also think that a lot that is developed by such diverse ecosystems has been a part of our software for quite some time. One can easily ignore developments in different environments and re-event things in one's own. But recalling earlier discussions we had concerning re-eventing stuff, we seem to have some different opinions on this subject.

It is a pity that you are ill and that we can't meet in The Hague tomorrow.
I wish you a speedy recovery.

... there are enough type designers and font developers in the world who would be willing to purchase tools from both our companies *if* those tools worked together ...

But if you were to ask me what I would prefer, rather than telling me what I might be willing to do, I would say I'd prefer to have one stand-alone piece of software that does everything, without the need of coordinating multiple programs that use command files.

Remember, many of your customers don't just design typefaces, they also market, distribute, sell and advertise them, all of which requires the use of yet more software applications.

Adam: ...in OpenType fonts, kerning can exist in two forms (“kern” table and “GPOS” table), and there are fonts which make use of both at the same time, there are others that only use one.

Although I have made such fonts with both kern table and GPOS kerning, at the request of clients, I think it is a really bad idea. As Frank says, if kerning changes that implies that a different font is in use. Since there are built-in incompatibilities between the kern table and GPOS kerning models -- such that only in a very simple font, with no GPOS kerning for unencoded glyph variants and no contextual kerning, could the two sets of kerning data be completely compatible -- what one in effect does is to disguise two fonts as a single font while surrendering control over which font is used to the mercy of the application. It is a pretty much guaranteed recipe for document reflow.

Although there always will be room for discussing how much is actually art or plain craftsmanship, at the end type design and font production are industrial design by definition. Perhaps some sorts or lettering can be seen as pure forms of art, but the clear purpose of type, i.e. casting written information in the best possible mould, defines clear requirements and subsequently makes restrictions inevitable.

Sorry to go a little OT, but this sounds very unlikely to me, considered the term "industrial design" has been coined in the 20th century, while simple mechanization of various aspects of writing has existed almost since the alphabet has been invented (even the simple idea of models for calligraphic styles or abecedaries is halfway to "mechanization").

So, I just wish to say that, if not for the Macintosh, I would probably not even be using a computer.
What created a feeling of "friendliness" around the computer as a tool has largely been the intuition of Steve Jobs and Apple in using a graphic interface like they did.
That, of course, is for good and for the bad, since as a result we have illiterate people creating weblogs, but the same as happened as the book stopped being costly and became economic…

Digital masochism, it appears to me, is everywhere, and we would not even have silly terms like "masochism" or "sadism" if the industrial production of the book was not already there when Krafft-Ebing lost himself in the "technicalities" of his own medical thought.

Claudio: '[...] this sounds very unlikely to me, considered the term “industrial design” has been coined in the 20th century [...]'

Considering that everything only exists because of our awareness, for instance for those who lived before the moment that Newton became aware of the attraction between mass, which he coined gravitation, this force and subsequently term simply didn't exist. But we know gravitation existed long before the end of the 17th century though.

To summarize, there are two camps of type designers:

Camp 1: Visual Joe's
- - - - - - - - - - - - -
Includes hobbyists, part-timers, and full-time-professional type designers. This group often comes from a design background. They want to build fonts that will be used by the design community using design applications. It is in their financial interest to never spend the time to learn a hoard of acronyms, mysterious information tables, command-line mumbo jumbo etc. Why? Because they can make fonts their audience will buy and use with success, using one application that insulates them as much as possible from "the dark side"... namely Fontlab. And that makes them happy. They enjoy drawing, and fear coding.

Camp 2: Font Ninjas
- - - - - - - - - - - - -
These are all full-time type professionals. It is in their financial interest TO SPECIALIZE IN "THE DARK SIDE." Why? Because their clients demand it, as Ninja Hudson has pointed out. Their clients have unique needs for language or feature support that creates a space in the market for Ninjas to operate. They understand that within these constraints, the actual drawing of glyphs is the tip of the iceberg, and they use a full quiver of tools(including DTL's offerings) to tackle complex production needs. They enjoy drawing, and enjoy challenge of using code to speed production. In addition, sometimes Visual Joe's get in over their heads and need to hire a Ninja to beat up their problem.

I'm not going to set the world on fire with these observations. I'm in Camp 1 with Nick. John is in Camp 2 with Chris Lozos (just checking to see if you're still reading Chris).

Frank: just to clarify, is it your desire to sell your product audience to include Visual Joe's?

Randy, I am still reading and honored to be thought of as in camp 2 with real ninjas like John. Let's say I am an infant ninja in training and still wearing diapers with training wheels :-)

ChrisL

Randy, I have enough of a foot in the Ninja camp to produce extended language support and OpenType features, in Fontlab. I don't mind a bit of coding if I can do it within FontLab, but running command line stuff such as what Frank posted above goes right over my head.

One of the most perplexing things for Visual Joes is font naming, and large family typefaces are targeted primarily at the design community, on both platforms. I have wasted soooooo much time trying to get big families to show up correctly in font menus....

Let’s say I am an infant ninja in training...

Hey, Grasshopper, bring me some tea!

LOL!!!
Here you go, John :-)

ChrisL

Wow, you even put in some green t for good health.

Are the FontNinjaCamouflageTM shirts for sale?

* * *

The camp 1 vs 2 may be ok for describing different kinds of designers. But the association of certain pieces of software with either camp 1 or 2 is rubbish.

During RoboThon I realized something funny. On the one hand, that attendants who are FLS users show an almost religious awe for UFO and UFO applications. On the other hand, that in their essence, UFO and UFO applications are actually more similar to Ikarus/FontMaster's than FLS's philosophy:
— The UFO font format. Rather than one file per font as with FLS, an UFO is a collection of separate files for outlines, naming and other metadata, kerning, classes, features -- not unlike FM fonts. Rather than FLS's .vfb, both UFO and FM's .be (plus assorted files) are open in that they are well documented and can be easily read/written by third parties. For those who haven't recognized: We need to define font names and lots of metadata whenever we produce fonts -- regardless of the application we use. There are font info dialogs in FLS, in FM, even in Area51, and all of these give access to more or less the same amount of info simply because that's what the end product requires. (Noticed the long list of data in UFO's fontinfo.plist?) Even Visual Joe needs to be some sort of a Ninja if he wants to produce fonts that work. Period.
— The UFO applications. AFAIK, the philosophy behind UFO-based applications is to have one tool per each well defined step in the font production workflow. Which is exactly FM's philosophy of offering separate modules.
— The price. I do not regard this as a valid argument since whatever helps saving time is worth its price, but since it pops up frequently: If I license FLS, ScanFont, Metrics Machine, Pre- and Superpolator and various other UFO applications shown at RoboThon, I easily pay as much or more than for the FM suite.

To make one thing clear: I like the UFO format and the applications too because they provide great interfaces for dealing with tendious tasks, like Metrics Machine for manual kerning or Prepolator for making masters compatible with each other. Because their interfaces make it easier to understand rather abstract ideas, like Superpolator visualizes interpolation in a multi-dimensional design space. Because UFOstretch combines interpolation and scaling in a single UI -- which combination, by the way, is what Tim Ahrens' RMX tools did before albeit behind the curtains. What I dislike, however, is adhering to some myths -- this app for Visual Joe, that one for the Font Ninja -- when a quick look at different formats and tools would easily prove them to be wrong. Remember that when FOG was still around it was actually FLS that was considered the camp 2 application?  :D

I also want to add that this RoboThon was, of all conferences I have attended, the best and most stimulating one. I have never before seen more new tools and ideas in only two days. It is not hard to predict that the next few years are going to be terribly exciting.

Randy: 'To summarize, there are two camps of type designers'

Classifications always imply the risk of simplification and placing those who work on fonts into two groups of type designers is perhaps a somewhat rough division. For my presentation in the main program of the ATypI TypeTech Forum in Lisbon in 2006 I made this presentation PDF in which (among other things) I tried to analyze the market for font tools. Although I came to three (partly overlapping) groups, namely type designers, font producers and programmers, inevitably this is at the end a generalization and simplification also.
 

 
Irrespective of one is a non-technical designer or a skilled coder, presumably the goal is always to come to an as perfect as possible product in the most effective, i.e. economical way. Revenues, costs and time have to be balanced. If time isn't the most important issue, a production may be allowed to be less effective to a certain extend. But for most of us time is a very important issue and therefor a production has to be consistent and every part of it has to be reproducible.

In my opinion coding only makes sense if the requested functionality is not available yet. If extensive batching functionality is built-in already like in FM, it does not seem to make much sense to start coding when one's first priority is to get the job done, I reckon.
The command files, as shown above, are very simple and in readable English. I must underline here that there is no command line involved; the command (text) files can be selected from the standard dialogs in the FM modules.

Furthermore, complexity is relative: matching an OT Layout features file to the character set in for instance FLS, seems to me more complex than selecting an all-covering features file and to let the app do the matching, like FM does with the modified 'HOT' tool.
The more technical skilled, who use the AFDKO to add features to OpenType fonts can alternatively use OTMaster, which also contains the modified 'HOT' tool, to do the same job much more easily and the non-techies can use the tool the very same way to come to the same result.
By the way, coming AFDKO downloads will contain (download) info on OTM.

This topic is not only about the non-technical versus the 'Ninjas', but above all about the willingness to discuss one's workflow and to look for improvements. The outcome doesn't necessarily have to be a switch to, or incorporation of, the DTL FontTools, but can result into an improvement of the current workflow also. Blindly focussing on one (set of) tool(s) and/or one operating system doesn't seem to me a solid basis for development or innovation anyway.

Already more than twelve years ago I decided that FM would become a suite of modules, which each had to cover a different and clearly described part of the font production. The very versatile modular (IK/BE) font data storage system that FM uses, dates from the 1970's and shows how visionary Dr. Peter Karow was. As Karsten stated, the BE and IK formats are well documented and public.
In my opinion the 'open' modular/modular system of FM is unbeatable when it comes to consistency and reproducibility. But one can consider me biased, of course.

Considering that everything only exists because of our awareness, for instance for those who lived before the moment that Newton became aware of the attraction between mass, which he coined gravitation, this force and subsequently term simply didn’t exist. But we know gravitation existed long before the end of the 17th century though.

With the due difference gravitation is a intrinsic natural force, while you couldn't have an "industrial" product, like typefaces, as there was no "industry", as the term is conceived now.
I just don't like terms which presume to address "in a better way" an intrinsic reality. It would be like calling "gravitation" "illusion of weight" and then go on this way…

As you see, it becomes a sort of existential question, or better it becomes a question of a "paradigm shift", and if I have to reply Randy, the only reason for which I don't like so much studying (some) more tecnical aspects of digital type creation, it's because of the bad use of time I see made around me by ignorant designers (not ordinary people) which often do not care at all about the effective quality of a digital product. Ironically enough, as long as you specialize excessively in a discipline, you lose sight of the overall picture, and so I think it's always good to learn, but with a critical perspective on how delving in specialized territory could become tricky.

In addition, sometimes Visual Joe’s get in over their heads and need to hire a Ninja to beat up their problem.

Or bug him for help (as participants to this thread know too well… :=( )

Remember that when FOG was still around it was actually FLS that was considered the camp 2 application?

So what is design but a treadmill?
A constant relearning of tools that increase the automation of production.
The designer, always in the thrall of the engineer and inventor.
Becoming more and more the technician, the director, the manager, if not the inventor himself.

"Art: man's joy in his handiwork" -- William Morris.

Haha! I meant no offense to Nick and was teasing Chris (whom I will now offend by demoting to Visual Joe 2nd Class). Note to self: should have called everyone a ninja... and used the belt system.

Frank: This topic is not only about the non-technical versus the ’Ninjas’, but above all about the willingness to discuss one’s workflow and to look for improvements.

Good point! The reason I brought up different types of users is that as a mere Orange Belt Ninja (with two stripes!) my process will be much different than John's because our client demands are different. I see how your module system attempts to meet the needs of both, but after exploring your site for 1/2 hour, I confess it is not evident what products I would need from your offering. I perceive some overlap between them (am I imagining this?) and I also spent some time looking for the main FontMaster program that all these modules plug into (but I think I'm imagining that too).

While it may not be the best idea to frame your products with my ninja foolishness, it may be helpful to clearly state what combination of products would suit a class of user, or what products are required to produce what kind of font. Packages, targeted at segments of the market (or something) to make your offering more straightforward. In a sense, this is what Fontlab has done.. TypeTool, Fontlab, Asia Font Studio and it makes sense to me.

*Hang on* Where is my copy of "Learn FontMasterUtilites Fast!" by Leslie Cabarga?

I agree with Randy’s assessment of the DTL site—it’s kind of confusing, both because the descriptions are not very good and because the web site is more complicated than it needs to be. Something similar to tools.typesupply.com would be a good way to introduce the FM tools to people who don’t attend the European conferences. Videos similar to those Tim did for his Font Remix tools and Erik did for Superpolator would also be effective. A FM tutorials blog based on old conference sessions would be a great way to show off. Clearly you have some great tools; try finding new ways to let font designers know what they can do.

"(whom I will now offend by demoting to Visual Joe 2nd Class)"

At least I can then stop making tea for John, then! :-)

ChrisL