The Great OTM 2015 Summer Poll

While you’re lying on the beach with a Cuba Libre in one hand and the fine-printed version of the amazing The Autobiography of Benvenuto Cellini in the other, and waiting for the waiter to serve you the Broiled Lobster Tails Au Gratin, perhaps there are moments your mind wanders off to DTL OTMaster.

OTM is on the market for more than five years now. The tool has become quite successful and is considered by many as indispensable. But surely there is additional functionality that you would like to see included. We are for instance thinking of including the subsetting of character sets (together with the OT Layout features) and the export of woff, eot, and svg in future versions.

However, the question is what you would like to see included in OTM.

I’m longing for a Brass Monkey now.

Comments

  • I don't think it that you should add production functionality. The tool is good at dealing with the bits and pieces of a font. Improve on that. Compare lookups, compare hole fonts (diff). Improve the interface (I offered my help on this one several times).
  • I would like to see:

    Import and export VTP projects (microsoft VOLT)

    Import a font with opentype features made by VOLT and Export a fea file (and import) without any errors.

    I am shure I have more but I can't remember right now.
  • Hi Georg,

    I don’t think it that you should add production functionality.

    Although OTM is primarily meant as post-production tool, this does not have to imply a limitation of its functionality, I reckon. I think it’s up to the user to decide whether and how options will be used.

    The next OTM release will for instance fully support the .ufo format, which will make it possible to import a .ufo file (an OpenType font will be generated on the fly) and to check stuff. Because OTM also has a fully-functional glyph editor, this will inevitably blur a bit the sharp boundaries between production and post-production.

  • Chris Lozos
    Chris Lozos Posts: 1,458
    edited July 2015
    I hope you can improve on the interface in the checker. Insert pop-ups with clear explanation of the error and how to fix it.
  • Hi Chris,

    Can you give an example (with a screen dump)?
  • Hi Chris,

    Thanks for the image. Actually, in this case the error is described at the bottom. The Full font name string deviates from the PostScript font name in the ‘CFF’ top dictionary.

    This will work too, I reckon, and IIRC on the OpenType list it was discussed to make the Windows entry equal to the Mac one, like in OT TTF.

  • This is the CFF naming dep.:



    and the ‘name’ table:



  • Chris Lozos
    Chris Lozos Posts: 1,458
    I read the explanation but it seems what I have there already is within the guidelines of what is explained at the bottom.  The font will indeed load but Mac Font Book shows a "minor error" in name table.
  • Chris Lozos
    Chris Lozos Posts: 1,458
    edited July 2015
    The only difference I can see is that there are spaces between words on one but the other has the spaces removed.  Which one is wrong? Should I take the spaces out of line 17?
    PS: I can't read your attachments, the type is too small for my old eyes ;-)
  • Nicolas Silva
    Nicolas Silva Posts: 9
    edited July 2015
    Hi Frank,

    I wonder about batch processing options for most of the editing tools of OTMaster. e.g., To have the ability to call, in Glyph Copy Tool, a list of "Source Glyph Index" in  Source Font and the same o another list on "Glyph Index Selector"; in that way we can do batch processing on a lot of glyphs. Think about the possibility of migrate an entire set of Kanas from one CID-Keyed font to another, substituting Glyphs instead of addding it at the end, and of course adding it at the end as another option too.

    Aditionally (this could be more a Utopia), it would be helpful to set actions that involve the Glyphs Editor, for example copy and paste, for specified glyphs through a list, all paths in such glyphs from a source font to a target font which have previously cleaned the original paths. I think this is another way to substitute glyphs, but of course there are a lot of things that could fall of the truck during the migrating process, like the GPOS entries related to the glyphs (kerning, anchors).

    Please let me know what you think about it, or if some of this things are possible with the current version.

    Best,

    Nicolás
  • Hi Chris,

    Sorry for the quality of the images. As you can see in the CFF table, the PS font name is ‘DezNowSansGaunt’ (no spaces allowed here, of course [BTW, personally I would prefer ‘DezNowSansGaunt-Regular’]). So, according to the specs the Full font name for Windows should be identical.
  • Hi Nicolás,

    Thanks for the suggestions! We are discussing the addition of batch functionality. As you know, there are requests for scripting, which we investigate. ;-)

    F.
  • Chris Lozos
    Chris Lozos Posts: 1,458
    Thanks Frank.  To my point in my first post, this is what should be clarified in the pop-up text in the checker.
  • :-)
  • Because OTM also has a fully-functional glyph editor, this will inevitably blur a bit the sharp boundaries between production and post-production.



    An example of this is the option to check exported quadratic splines against the original bezier curves in OTM, in case the used font editor itself does not provide this functionality. In OTM’s glyph editor the contours can be checked and –if applicable– improved.



    The previous two images show the exported quadratic splines from RoboFont (top) and GlyphMaster (below [codename: IKED]) in red with the original (dark) beziers in the background.



    One can imagine that for instance the improved glyphs are stored in a .ufo file and that a next time these are directly used for the generation of .ttf fonts, for instance using FontForge (image below). Hinting is in most cases generated with ttfautohint anyway AFAIK, so this would be reproducible too.


  • Thomas Phinney
    Thomas Phinney Posts: 2,895
    That name table thing y'all are kicking around, where the Windows Full Font Name is supposed to be the same as the PostScript Font Name, is an old recommendation which was dropped several years ago. Sairus Patel or Read Roberts would be able to provide details, as I recall.
  • Hi Thomas,

    That name table thing y'all are kicking around […]

    I don’t think that we were kicking around much about the entry itself, but more about the (interpretation of the) depth of information provided by OTM. As I wrote: ‘This will work too, I reckon […].’

    Read Roberts wrote the following about the Windows platform name.ID 4 on the OpenType list on 12 January 2010:

    A reason to change name.ID 4 in new versions of shipping fonts is that the latest version of the OpenType specification, version 1.7, has dropped the rule that Windows platform name.ID 4 should be set differently for OpenType/CFF than for OpenType/TTF fonts. Previous versions of the specification say that for OpenType/CFF fonts, the Windows platform name ID 4 should be set the same as the PostScript name, rather than constructing name.ID 4 from the Family and Style names. This special case for OpenType/CFF fonts had to do legacy software support in the very early days of OpenType, and the rule has not been needed for many years.

    But he added a reason why one has to be careful though:

    Since the Adobe Type Department is updating the Adobe Type Library in order to use OS/2 table version 4 and WPF menu names, we thought we would also change the Windows platform name.ID 4 to match the new wording for name ID 4 in OpenType spec v1.7. We found that this was not a good idea.
            Under all versions of Windows, you can manually install (drag a font file onto the Fonts folder window) one version of a font file when a different version is already installed, if the two font files have different name.ID 4 values, even if both have the same file name. Both fonts end up in the system Fonts directory (C:\Windows\Fonts), and the second file gets renamed to a unique filename. Only one of the fonts of is visible in program font menus. This is a problem for several reasons. 1) The user is allowed to install a one version without being alerted to the fact that there is a different version already installed. It is confusing to the user to have installed a newer font, and still have only one show up in program font menus (sometimes the older one, other times the newer one). 2) It also hard on third-party font installers, which may look for previous versions by a specific file name.

    We never changed the Windows platform name.ID 4 in our own font production (i.e., we keep it the same as the PostScript name still), but in the new version of OTM, which will be released towards the end of this year, we will change the info on this entry in the checker.