2007 Poll on Type Design Tools

Stephen ColesStephen Coles Posts: 683
edited May 2013 in Type Design Software
Back in 2007 I posted an informal poll on Typophile asking forum readers what OS and apps they used for designing type. Here were the results (screenshot of ugly unfinished charts also attached).

Many suggestions for improving the poll followed. If a simple survey like this were to be conducted again (to include new tools like Robofont and Glyphs) how would you change the methodology?


  • It would be interesting to see how much work type designers do on their own.
    Like, drawing, extending, interpolating, spacing, kerning, hinting...
  • Chris LozosChris Lozos Posts: 864
    Leave out OS9 but add some sub flavors of windows in that they affect rendering, hinting, naming, etc. Add web type flavors; add sub tools category to show use of popular sub tools (RMX, Superpolator, MetricsMachine, etc.)
  • James MontalbanoJames Montalbano Posts: 736
    edited May 2013
    I'm not interested in any of this at all. Whatever tools a person uses is their own business. I am more than happy with my approach.
  • George ThomasGeorge Thomas Posts: 346
    Instead of an informal poll, how about a web page where interested parties can fill out a questionnaire about their tools, workflow (which covers what Ermin suggested), etc.

    If it were my project, I would limit it to registered users of [site name here] only -- real names, please -- with anonymity guaranteed in the final results.
  • I am very interested in questions of market share and what tools are popular.

    I agree that it would be very interesting to know what peripheral or additional tools people use.
  • I'd love to see this redone too :)
  • I love that my comment of May 11 gets 3 'Off Topic" votes and 1 "Agree".

    The magic of Typedrawers.

  • Adam TwardochAdam Twardoch Posts: 185
    edited June 2013
    I'd like to suggest a slightly more granular approach to the various tasks within the font creation process, to give a chance for more specialized tools to be captured (like Metrics Machine, VOLT or VTT). Perhaps something like:
    — glyph outline drawing
    — glyph set management, general font editing
    — font family management, interpolation
    — metrics and/or kerning
    — OpenType Layout feature development
    — hinting
    — final mastering and font generation

    Also, the ability for each user to give mutliple answers would be useful as, from what I can tell, quite a few people use several tools in combination these days.

    I'd be very interested to hear the results of such poll! :)

    Perhaps also a "number of hours per month" for each tool would be a useful category. There may be tools which are used a lot (usually for glyph outline drawing) and then tools which may be used only once in a while (for autohinting or some specialized tasks).
  • BTW, in 2011, we have done a FontLab product questionnaire on Google Docs:
    which tries to go a bit deeper into the atomized tasks of type design. It is focused on FontLab products, and is quite long, but has gathered a fair number of responses (more than 150), and is still getting occasional responses.

    I'd be most happy to work with others (e.g. makers of various UFO tools, of Glyphs, RoboFont, FontForge etc., and with a committee of other interested people) to prepare a more comprehensive questionnaire which could be used to capture the opinions of different users. The questionnaire could be posted on different forums (TypeDrawers, Typophile, FontLab forum, Glyphs forum, RoboFab list, Google Font Developers list etc.) to ensure the widest possible coverage and the least "skewing" of results.

    We could even have two questionnaires: one simple (2-3 minutes to complete) and one extensive (20-30 minutes to complete), so we could reach a wider audience for the simple one and get more insights into details with the extensive one, where probably less people would respond.
  • Perhaps another useful survey would be to ask how many hours people spend making fonts vs. how many hours people spend filling out questionnaires.

    The magic of TypeDrawers.
  • D. Epar tedD. Epar ted Posts: 664
    Back in 2007 there were no custom web fonts, so it was like a different world.

    I believe, that questionnaire was early, and this one is late.

    But, it'd be interesting to know "why" people use what they use :)

  • I attended the Robofont class at Cooper Union a few weekends ago. From people I talked to there, it sounds like most of the U.S. foundries, including Adobe, and many independents, are now based in a .ufo format world, and using Robofont, Metrics Machine, etc. I don't know about Europe.
  • So the people promoting UFO format tells a group of paying customers that most of the U.S. foundries are using their product, and you believe them. Huh.
  • John HudsonJohn Hudson Posts: 913
    I think the idea of UFO -- a transparent, human-readable source and archive format -- is grand. But I'm not happy about a 16.5 megabyte source file for a 1 megabyte font, nor about the amount of time it takes to load and save that file in some tools.

    So my source format of choice remains sfnt. Everything else is a tool format.
  • The people I know at the bigger foundries are using .ufo tools.
  • John HudsonJohn Hudson Posts: 913
    A good discussion of file formats in The Other Place:

    The contributions from Grzegorz Rolek and David Berlow deserve close consideration.
  • James, I have heard about different foundries from multiple sources, including those at the foundries. I didn't give a list, because I'm not equally sure about all of them. I was surprised about Adobe, and wonder if anyone can verify that. Font Font hasn't switched, I was told, and is very unlikely to.
  • @William Berkson. Go with god.
  • D. Epar tedD. Epar ted Posts: 664
    Which format is that?

  • g o d
    Grievously Over Defined...font objects
  • James PuckettJames Puckett Posts: 1,303
    Please stick to the topic at hand—which is not what type design tools you find most disagreeable.
  • D. Epar tedD. Epar ted Posts: 664
    But seriously,

    John> So my source format of choice remains sfnt.

    SFNT is a brilliant technical solution being that it's as compressed and expandable as you want.

    But sfnt only allows quad or a cubic-based outlines. If one has un-convertable contours and needs to store both, that's two sources, which is not a big deal as maybe it's only some glyphs. But if the next wave of color font standards have their way(s), sfnt could expand in way(s) perhaps too hideous to archive as sfnts? Can the format expand to multiple glyph tables, and a glyph table cop? Who knows. Or, maybe color will be the straw that breaks the camel's back and leaves a non-functioning dromedary or yet another push-me-pull-you format like OT?

    Before that happens, or not, I think there are some things about sfnt sourcing (presumably in an OT or WOFF wrapper); the metadata for defining key values about styles in typeface families is uneven. The range of values, for a minimum pixel size of 1-256 or so, is good. The point-size master of a style can be defined as 1-64k? fine. This means, all OT styles on earth with accurate values for min pixel and optimal size can be compared universally.

    But width and weight only have 10 values. When one thinks of the requirements of publishing, going backwards like that instead of forward to indiscreet variations, and 10,000 values for width and weight is still the biggest wtf, to me, in type tech history and indicates to me a desire to remain hidebound to "Fonts" and not "Typography".

    The other flimsy thing about sfnt sourcing via OT is a bit more complicated; Adam's list starts with drawing and ends with font generation. I've been working under the assumption that such a list, and the format that serves this process, needs to start with Management and end with Monetization. In a lot of cases this is already true of the jobs of many type designers, (as their hearts can easily be torn out from leaving any part of the broad process in the hands of another).

    Making a format/tool for the whole process, or interfaces to tools which can do the rest, free of "black boxes", (or royalties), one can end up with big source fonts, not to mention an expensive tool set. But, if one has a lot of source fonts, big or not, one ends up with either huge UFOs, VFBs, or even more, through littler sfnts. With a lot of little sfnts, and espicially if one is subjegated to a range of tools for accessing different tables within them, the gun I think, is already to one's foot just waiting for a client, or a format change, to help you pull the trigger :)

  • John HudsonJohn Hudson Posts: 913
    Very good points, David.

    I think the conclusion must be that we don't yet have a good generic source format for digital type, only a variety of more or less incomplete tool formats that, with some clever workflows, can be leveraged to produce the kinds of fonts that we've, so far, been called upon to make. Given uncertainty about what might be around the bend, I can certainly see the attraction of open, documented formats such as UFO over proprietary, blackbox formats such as VFB. They, and the tools that use them, can be more easily and more quickly updated, and they encourage collaborative efforts.

    Another reason that I favour sfnt as my font source format -- which is not the same thing as a design/glyph source format --, though, is that I'm very wary about tool-triggered regressions. As Adam pointed out today over in the Other Place, the UFO format deliberately excludes some font data that is expected to be generated by tools, but with the result that the same UFO passed through different tools will not produce the same TTF (back to the clever workflows!). There comes a time pretty early in Tiro's typical font development when we need to lock down portions of data and avoid any steps that will affect and change that data, because we've got clients running diff tests and getting in a panic over backwards compatibility; if we do need to change data, we spend a lot of time managing it to make sure that there are no functional impacts. Now, I am quite aware that what we do and the clients for whom we do it do not correspond to the working situation of a great many of our colleagues -- and that some of our clients' concerns might be silly; then again, they know what costs them money --, and this is why I'm not surprised that a format like UFO is a fine source for many people. But I doubt if we will arrive at a common, universal source format any sooner than we will arrive at a common, universal EULA. Our business is too varied.
  • Chris LozosChris Lozos Posts: 864
    "... the gun I think, is already to one's foot just waiting..."
    David, Is that the self-same German Luger you spoke of at TDC?
  • D. Epar tedD. Epar ted Posts: 664
    >David, Is that the self-same German Luger you spoke of at TDC?

    Lol, no... that gun was rural while this gun is plural...

    John, you have a good plan, and I understand, But...

    "...the UFO format deliberately excludes some font data..."

    The UFO so far developed has been very deliberate, and I'm sure that people-build tools are capable of excluding font data, but the format itself does not deliberate, or exclude, so you must mean something different?

    >...uncertainty about what might be around the bend...

    The reactions to the last uncertainty around the bend is what convinced me sfnt and vfb are not the answer. MS was at the time of ATypI Mexico, "convincing" us via instruction deprecation that the sfnt was dying as a source. Now that we are around the bend, and the same sfnt passing through different devices will not produce the same font, what's the big deal? And at FL, with two years warning before the bend started, the vfb didn't even budge a single byte. Lastly, the list of what's wrong with OT is too long now, as is the line of "students" to educate on the road to change;)

    So because of all those mothers' necessities, we have invention. We have clients who want diff-less fonts too, and we need to serve them as well as ever, but we also have clients who expect the performance, functionality and quality of our products to improve, and all our new production can to do either. Locking down portions of data, vs/or locking down portions of the glyphs, or locking down the designer, or the client, I don't think we should have to choose;)

  • Adam TwardochAdam Twardoch Posts: 185
    edited June 2013

    John was referring to my comment on Typophile, where I wrote that UFO "deliberately leaves various decisions to tools" i.e. does not attempt to cover all aspects of what should go into the SFNT. It does not, for example, have standardized provisions as to what the contents of the "cmap" subtables other than the Unicode subtable (3.1) should be, how the "kern" table should be constructed if it effectively has different contents than the GPOS "kern" feature, or what the contents of the multiple font dictionaries in a CID-keyed CFF table would be.

    I'm not saying that it should define all these things. UFO has its weaknesses but I don't consider the exclusion of certain aspects of "what can go into an SFNT" one of them.

    UFO has provisions that allow users to include their own custom descriptions of such data, and to build tools that would then insert that data into the SFNT when it's being built. But that's true for other source formats as well.

    And, of course, I used "UFO" metonymically. UFOs don't deliberate just like VFBs don't budge even if they very much wanted. It's the creators of the formats who might do these things.
  • Stephen ColesStephen Coles Posts: 683
    edited June 2013
    I love this digression, but getting back to the topic at hand…
    We could even have two questionnaires: one simple (2-3 minutes to complete) and one extensive (20-30 minutes to complete)
    I like that idea. Ruxandra Duru is updating her report on the type design community which we’ll publish at Typographica.org. There will be a new section on digital tools, so perhaps that can fill the role of the simple survey. I have passed along some of the ideas from this thread to her.
Sign In or Register to comment.