>This means that we will probably in the near future produce a Mac OS X version of FM for a group of type producers that are part of less than around three percent of all the computer users just to support the Mac OS.

Frank, just to clarify: did you mean to say that you will probably *not* produce an OSX version? That's the conclusion your argument sounded like it was headed toward.

-- K.

Three percent may be correct in terms of the overall computer market, but is it really a relevant number when talking about the type tools market? The number of font designers and developers using Mac OS is has got to be greater than three percent.

We probably will produce a Mac OS X version, if only because the programmers of the FM Team are anxious to start working on it. What I meant is that the development of a special OS X version of FM is a reasonably large investment for a relatively small group of users, although Mark Simonson is right to conclude that the total number of font designers and developers using Mac OS has to be greater than three percent. At the other hand many FM customers are former Ikarus users working on PC

From a font production point of view, for me still there is no special reason to use Mac OS X instead of OS 9/Classic.

I would agree with that. I presently do most of my font development on a separate machine running OS 9. I use OS X for everything else.

As you say, it's not essential, but it would be better if more font tools ran native in OS X since more and more of us are using it. It's true you can run things in Classic, but then they can't take full advantage of things like memory protection, automatic memory management, etc.

Anyway, Frank, I appreciate your sharing this info about the DTL tools. I'm really not familiar with them and this has prompted me to download the demo and find out more about them.

Thank you Mark for your replies. Please note that the current demo version of FM does not contain demos of Kern- and TraceMaster. Also the current demos of Bezier- and IkarusMaster still lack the anti aliasing in the Font Administration tool. For the Windows version this is not a real problem but on the Mac the resolution is actually to low for the current showing of the codepages; it simply does not look nice. Somewhere this or next week demos of version 1.08 will be available (but first I have to update the manual).

I think 3% or whatsoever figures represent nothing. The actually key of font design editors futur is:

What will do the large base of current users of Fontographer?
-stay on 9 for a while...
-move to the X and switch to FontLab (many people already, from what I see on type forums)
-move to FontMaster and stay on 9, but in this case, why they will move to FontMaster?
-mixture of 9 and X.

In my case, I tried FontMaster demo in last september, it crashed couple of time my 9 for not apparent reasons. So, I can't have an opinion of the interface, saddly.

Then the FontLab beta arrived in early November and I switched to the X, 2 weeks later, then, stopped to use Fontographer. I like it very much and the support is quite responsive, in sense, most of uncovered needs are answered by a new tool couple of weeks later. Fog support was also very good, but never answered with a new tool!

Competition is always good thing, I happy to tried again, one day, FontMaster tools, only if they came to the X indeed.

> There is a good reason to keep these parts of the font production separated

Indeed. Although it does seem to me that separation of tasks is a two-edged sword (in terms of endangering the integrity of the whole), if the communication/iteration between the stages is managed well, the gain in efficiency is worth it.

BTW, thank you for such a full elaboration of your methods and plans.

--

> What will do the large base of current users of Fontographer?

I think a large and sad reality of the current base of Fontographer users is that most of them haven't actually paid for it (partly simply because it's much easier to get an illegal copy of Fontographer than of FontLab), and these people are less likely to pay for anything else...

hhp

It is quite understandable that some Fontographer users are not anxious to switch to another programme, especially when they are used to the functionality of the editor, but the fact that you can't use Fontographer to produce OpenType fonts is quite a restriction. However, it is always possible to combine programmes. Type designers who still prefer to work in Fontographer can actually build -as far as I know- a database of roughly 8000 characters. If the naming of the characters is right it must be possible to convert the exported PostScript font containing the full glyph set in DataMaster to a BE database and use DM to generate all the font formats, including OpenType fonts with GPOS and GSUB features. The demo's of BezierMaster and ContourMaster even can help to respectively check the codepages and to get a listing of possible errors.

I will be the last person to deny that we had some stability problems with FM on the Mac. During the testing we never had problems like the one Jean Fran

On the platform usage question:

It's my take that about 2/3 of worldwide font development is on the Mac, while about 2/3 of worldwide font purchase is for Windows.

T

Is that based on your time at Adobe or in general, Mr Phinney?

I wonder if the guys at FontLab would be willing to give figures out for the split between PC and Mac sales of FontLab since the MacOS X version?

I'd be really interested to see if Mr Phinney's 2/3 split is accurate (it certainly would cheer me up if it is!)

FontLab sales are only remotely related to what Thomas was talking about: program is used on both platforms by both font developers and font users. But I cannot see anything that will tell that Thomas is wrong, actually I agree with him.

I can give a hint: FontLab developers group has more Mac computers than PCs :-)

Best regards,
Yuri

After the release of the light version of DTL FontMaster I received several questions concerning the structure of FM and about the advantages of items like the UFM and PAR files. Because of the direct relation with the start of this topic, I will explain somewhat more about the structure of the font production with FM here.

All the files generated by the FM modules are platform-independent. At DTL the font production files are centralized on a server and can be reached from any Mac or PC in the network. I am sure most of you will work in the same way. Because of the fact that the FM data is platform-independent, no conversion has to be done to work on the files in Mac OS or Windows.
The font data consist of five files: the collection of glyphs stored in the BE or IK format, the UFM file that contains the naming, copyright, ID and some conversion information, the AFM and FEA files, and the PAR file. The PAR file contains path information to the kerning data, which can be stored anywhere. The BE/IK,UFM and PAR files have to be located in the same directory and are automatically 'connected' by name. If a BE or IK database is selected in DataMaster the font naming (and ID info) is taken from the UFM file with the same name.

This system is quite versatile. At DTL we store the databases in an old fashion way with an eight character code. The database of DTL Caspari Regular for instance is named C_94_13T. The underscores are replaced with respectively the character that indicates the code page and what we call the 'Standard' (0) and 'Special' (C) info. The last character indicates text (T), display (D) or Poster (P). C_94 is the code for DTL Caspari and 13 means Regular (33 is Italic, 14 Medium, 34 Medium Italic, etc). As a result C094013T means regular with Western European lay-out and tabular figures, and CE94C13T is the code for Eastern European with old style figures. CP94013T is the code for the OpenType Pro font. All glyphs of one weight/style are stored in one database and together with the databases the different UFM and PAR files for Western- and Eastern European, Cyrillic and Greek are stored as C094013T, CE94013T, CC94013T and CG94013T. The second zero is replaced by a C in case of the versions with the old style figures. By only altering the two underscores of the database a different UFM file will be automatically connected to the database and the only thing that has to be done when a font has to be generated, is the selection of the appropriate Character Layout file (.cha) that contains the code page that has to be exported. The PAR file secures the connection with the right AFM or FEA file. Normally a UFM file is made once and never changed again. As many of the supporting files of FM also the UFM file is a simple text file which can be altered directly using a text editor.
The generation of Mac fonts is only possible with the Mac OS version of DataMaster. In mixed environments it is enough to have the editors for both platforms but only the Mac version of DataMaster and to use this to generate the different font formats.

Recently someone wrote me that he would consider to test the program if we would combine the different modules into one 'MasterMaster'. I fully realize that for small productions the split of the functionality is not very important and that the structure differs of what people are used to. However, for controlling large amounts of data the structure of FM is perfect. At DTL we are expanding at the moment the complete library with Cyrillic and Eastern European character sets, including the families that we will release this autumn, namely DTL Romulus and DTL Fell and I can't think of a better way to control the data. Besides the advantages for the font production also the modular structure makes updating the program easier because we can do this per module without disturbing the other stuff.

[ This thread moved to "Build" ]