Home› Type Business

Reducing font family bloat

Nick ShinnNick Shinn Posts: 2,059
in Type Business
The number of fonts in a typeface family is mushrooming.

Without even getting to web fonts, I'm about to publish a multi-script RIBBI typeface that has 64 fonts, 80 if family packages are included. Each style will be available in four script options (Latin, Greek, Cyrillic and Pan-European), Plain and Pro, and .otf and .ttf.

I’ve been publishing only .otf format since 2005, but the Bold Italic of this face looks so much better on an Apple monitor in .ttf that I have seriously considered only publishing the .ttf format … however, there is a lingering stigma, I suspect, amongst Mac users, against .ttf fonts.

Of course, another option would be to not even bother with individual fonts for the Greek and Cyrillic markets; I mean, it’s unlikely I will ever sell any Greek Bold Italics. However, making those individual fonts available sends the message that this is a serious multi-script face, has symmetry, and shows cultural respect.

What should I do?
«1

Comments

  • Mark SimonsonMark Simonson Posts: 1,601
    Why do you need to even offer Greek, Cyrillic, etc. as separate fonts? Why not just have one version and simply include all the characters and their associated encodings? Is there some advantage to having them be separate?
  • RalfRalf Posts: 170
    however, there is a lingering stigma, I suspect, amongst Mac users, against .ttf fonts.
    According to the spec, you could just make TTFs and give them an OTF suffix. :-)
  • Stephen ColesStephen Coles Posts: 989
    edited December 2012
    Why not just have one version and simply include all the characters and their associated encodings? Is there some advantage to having them be separate?
    If you want to offer fonts with Extended/Non-Latin support as a different product so it can have a different price tag?
  • Robin MientjesRobin Mientjes Posts: 132
    Yes, I’d suggest making a TrueType-outlined OTF. No problems there, I suppose? And I side with Georg, do you have screenshots of this? I’m interested.
  • Christoph KoeberlinChristoph Koeberlin Posts: 51
    Just rename the TrueTypes to .otf!
  • James PuckettJames Puckett Posts: 1,947
    Yes, I’d suggest making a TrueType-outlined OTF.
    That might annoy users who convert the letters to outlines to edit (for logos and such) and realize that they’re getting Illustrator’s messy TT to PS conversion.
  • Nick ShinnNick Shinn Posts: 2,059
    Mark: I did that with the Modern Suite, but it meant that the very large fonts were very expensive.

    Now (as per Stewf’s observation) I intend to price the PE Pro fonts high, but offer basic Latin fonts with no features at low price. That should generate more profit overall, and not piss off those who buy the big fonts for big bucks and end up paying for a lot of stuff (eg Greek small caps) they never use.

    James: the TT to PS conversion is quite accurate; the only problem is that it adds a lot of extra points that aren’t in the original FontLab PostScript drawing. More fussy than messy. Is that an issue?

    I will post comparative files soon.
  • Mark SimonsonMark Simonson Posts: 1,601
    Converting from PS to TT does lead to more point data, but, as David Berlow showed in the thread about The Future of OT/CFF, if you work natively in TT, it's possible to get paths that are just as point-efficient as PS. The extra points aren't a necessity of the format, just an artifact of the usual conversion algorithm.
  • Nick ShinnNick Shinn Posts: 2,059
    edited December 2012
    image
    This is an InDesign document, PostScript above, TrueType below. FWIW, the Bold styles have Forcebold applied. The viewing scale is 141%, just a random size the document opened at.
  • Matthew ButterickMatthew Butterick Posts: 143
    the Bold Italic of this face looks so much better on an Apple monitor in .ttf
    Does InDesign rely on OS X for rendering type, or the CoolType rendering system used in Acrobat?
  • Nick ShinnNick Shinn Posts: 2,059
    edited December 2012
    Mark, those point-efficient TT paths are nonetheless embellished when converted to PS by layout apps.

    Matthew, Adobe applications work independently of Apple rendering—you can tell because Apple rendering pays no attention to a font’s hinting, whereas one is able to fine-tune type’s appearance in InDesign et al by adjusting alignment zones &c.
  • PabloImpallariPabloImpallari Posts: 773
    edited December 2012
    Nick,
    The "Additional Vertical Metrics", often overlooked, are maybe on of the most important factors to improve rendering on screen.

    Can you post a screenshot of your "Key Dimensions" and "True Type specific metrics" info? Maybe I can help to improve your OTF rendering
  • James PuckettJames Puckett Posts: 1,947
    edited December 2012
    I think this is a CoolType issues. Truetype and Postscript rendering look almost identical in a browser. Below are Chrome and Safari rendering the same document and fonts (click to view full-size).



    image
  • Nick ShinnNick Shinn Posts: 2,059
    Thanks for your kind offer Pablo, but I don’t think there’s much hope for PostScript in Adobe’s rendering of this typeface. The most notable factor is the hinting of the diagonal strokes in TrueType, especially in the Bold Italic.

    I will change the suffix of the TT fonts to .otf and publish only those.
    Thanks for that advice Ralf.
  • Deleted AccountDeleted Account Posts: 739
    Mark: "Converting from PS to TT does lead to more point data..."

    Except, as I pointed out, with Robofont, where 1 to 1 point conversion is one click away. With this, one has all the freedom long required for professinal work independent of the tt-ps, and hinting nonsenses.

    Happy new long count.
  • Mark SimonsonMark Simonson Posts: 1,601
    David, where is this "1 to 1 point conversion" one click away? I know that there is a setting in Preferences for drawing with either "Cubic Beziers (PostScript)" or "Quadratic Beziers (TrueType)", but that just affects the way the pen tool works. And it will convert TT curves to Quadratic curves with two off-curve points on importing a TT font, but it doesn't seem to do any sort of conversion on importing PS fonts. I can't find anything in the program or the documentation about any "one click" conversion, one way or the other.
  • Deleted AccountDeleted Account Posts: 739
    edited December 2012
    Robofont, font window, font info/Robofont/... The one can choose "preserve points" or "...curves".
  • PabloImpallariPabloImpallari Posts: 773
    This is great. However, you will need to review your glyphs after conversion.
    Some glyphs converts flawlessly, some others get screwed.
  • Mark SimonsonMark Simonson Posts: 1,601
    Ah, right, I think you explained this somewhere before, but I forgot. So it only happens on generating a font?
  • PabloImpallariPabloImpallari Posts: 773
    edited December 2012
    BTW, Eduardo Tunni (http://tipo.net.ar/ and teacher at http://www.cdt-uba.org/) has a very cool method for distributing the BCP controllers in a way that they are always at optimal position, whiteout changing the curvature of the segments. Andrés Torresi is making a macro out of his method, called 'The Tunnifier', and hopefully they will release it soon.

    I guess that Cubic Beziers curves processed throw Tunni's method, will produce much better results when converted to Quadratic Beziers via Robofont "preserve points" option.

    Will run a few test and report back
  • Mark SimonsonMark Simonson Posts: 1,601
    I think you mean "without" instead of "whiteout" and "through" instead of "throw". I had to read several times to understand what you meant. Get that auto-correct under control! :-)
  • PabloImpallariPabloImpallari Posts: 773
    Yep.
    Thanks for the corrections. Sorry about my limited English.
  • Mark SimonsonMark Simonson Posts: 1,601
    No problem. Looking forward to the results of your testing.
  • PabloImpallariPabloImpallari Posts: 773
    edited December 2012
    David, Mark et all:

    Fist test: http://cl.ly/0J3z3g3r0l03

    A: Original Glyph, harmonized using RMX Supersmoth All
    B: /A processed through the Tunnifier. Note that the BCP are in optimal position.

    C: Robofont "preserve points" conversion of /A. Note the wonky curves at the top
    D: Robofont "preserve points" conversion of /B. Flawless conversion!

  • [Deleted User][Deleted User] Posts: 0
    The user and all related content has been deleted.
  • Deleted AccountDeleted Account Posts: 739
    edited December 2012
    PI:"Some glyphs converts flawlessly, some others get screwed."

    As per your example, it looks like good glyphs convert flawlessly, bad glyphs become obvious. ;)

    JM: "What did Tunnifier do?"

    I think it tries to undo what we don't usually do.

    There is also a Robofont panel called "Curve Adjust" that does Tunnific work, but it's always good to have more.
  • PabloImpallariPabloImpallari Posts: 773
    edited December 2012
    What did Tunnifier do?
    Basically, his method finds the optimal position of the BCP's (almost) without modifying the curvature of the segment. But this is only my very simplistic definition.
    I've invited Eduardo to join us, so he can provide a detailed explanation of his method.
    Isn't that the way one draws outlines with BCPs anyway
    Exactly, but even someone with a high level of skill like you, can't always find the perfect/optimal placement of all the BCP's on all the Segments on all the Glyphs. Or maybe you can, but it will require a lot of time. Using Tunni's method/macro, you can get there much faster.

    James, I know that you are not very affectionate towards automated solutions, but this one will not draw the glyphs or the curves for you. It will only optimize the BCP's placements without modifying your drawings.

    If you want to see a few more sample, feel free to post a file containing a few of your glyphs and I will run the macro and post the file back, so you can compare the before and after results. I guess that your glyphs may be very very close to the optimal values, but still there is room for little improvement.

  • Ben BlomBen Blom Posts: 250
    a very cool method for distributing the BCP controllers in a way that they are always at optimal position, without changing the curvature of the segments
    Pablo, when I compare the "A" and "B" glyphs of your test, I notice a change in curvature. "B" does not look like "A", and I am afraid I like the shape of "A" more than the shape of "B". So, the price one has to pay for using the Tunnifier, is that the original design of a glyph might be replaced by an inferior version of it. I would not want to pay a price like this.

    I like the idea of the Tunnifier, but the test does not support its description.
  • James PuckettJames Puckett Posts: 1,947
    So, the price one has to pay for using the Tunnifier, is that the original design of a glyph might be replaced by an inferior version of it.
    That argument can be made for every tool that automates some part of type design. But accepting the automated result is not mandatory.
Sign In or Register to comment.