Minimizing ttf file size

Assuming everything that could be components is, and hinting is kept as lightweight as possible, are there other options for reducing the file size of a ttf? Is there any metadata that could be stripped out? Simplifying outlines?

I’ve been looking at the GLYF table (the main bulk of the weight) using TTX, and it includes quite a bit of comments (under instructions/assembly). Are these added by TTX, and removed again when converting back to TTF?

Is all the additional metadata strictly necessary?


  • edited January 2015

  • > Are these added by TTX, and removed again when converting back to TTF?

    Of course, TTF is a binary format.
  • Thank you, Adrien. Apologies for my stupid questions.
  • John HudsonJohn Hudson Posts: 1,600
    edited January 2015
    In regard to reducing font size:

    Design to a smaller UPM grid, so that more outline point values are stored as shorter numbers (obviously a decision to be made early in the design process).

    Use format 3 post table, which will strip all glyph names. This format was originally specified to avoid duplicate glyph naming in post and CFF tables in PS OpenType fonts, but can also be used in TTFs to reduce file size. [Note, however, effect on Acrobat ability to construct text strings from glyph names in distilled PDFs.]

    Unless explicitly using to affect vertical metrics at particular ppem sizes, don't include a VDMX table.

    You could similarly dump the LTSH and HDMX tables unless you're specifically using them. The cached device metrics tables were originally included in TTF to improve performance on older systems where memory was a premium.
  • Thanks John. That’s very insightful.
  • Unless they are there for a reason, remove the tables with embedded bitmaps (EBDT, EBLC, and EBSC). I had some files where they were accidentally included.
  • edited February 2015
    A discussion on stripping out certain things from the name table, albeit for a different reason, over at Typophile.

  • Name table platform ID 1 is for MacOS 9 and can be removed. 
  • Generate the font with the glyph index in Unicode order. Should save a few bytes.
  • MalcolmW: How can you do that?
  • In FLS5: Glyph / Sort Glyphs / By Unicode
  • In FontCreator: Tools -> Sort Glyphs -> Unicode Codepoints

    Changing the glyph order affects several tables. Most likely cmap gets smaller, but hmtx will most likely increase a bit. If your font contains OpenType layout features, then the GSUB, and GPOS (and GDEF) tables most likely increase more than you gain with the cmap table.

    For internal use you could consider removing the license information. Why do you want your font file to become smaller?

  • edited February 2015
    John Hudson: DTL OT Master can make a format 3 post table, right? Any other ways of generating one?
  • Erwin: Making the file size as small as possible is important for websites, especially those with a lot of visitors.
  • When you export a font with FontCreator, you can specify whether you want to include glyph names or not. See the manual:

    The biggest gain will be making your font available as a WOFF file, but making the ttf file as small as possible before converting it to WOFF will also help a little?

    Most web browsers nowadays support WOFF; which has good compression. The upcoming WOFF2 will reduce the font file size even more, but that format is not official yet, although several browsers already support it.

  • DTL OT Master can make a format 3 post table, right? Any other ways of generating one?

    IIRC, Python FontTools get rid of the glyph names if you just change the format of the post table to 3.

    Something like this:

    p = f["post"]
    p.format = 3"new.ttf")
    Another way to save space, if you have done the TT hinting in FontLab, is to decompile and compile the prep, fpgm and glyf tables once with FontTools. That changes "word" values in the hinting code to "byte" values whenever possible, which take up less space.
  • Not sure if "a few extra bytes" are worth the effort?

    Looking at the http archive data the average font file size is c. 37 kilobyte for Latin fonts ... that's just like 2 percent of the overall average transfer size of a web page.

    I would simply stick to woff and optimize images, scripts and everything else first. 
  • Hi Jens,

    I’m not well versed in Python scripting. What would be the full context of that statement? If that is typed in terminal, then I assume I need to reference the ttf (or the ttx) file before your code.
  • Create with contents

    from fontTools import ttLib
    font = ttLib.TTFont("fontp_post_version_ne_3.ttf")
    f = font['post']
    f.formatType = 3.0
    outfile = 'font_post_version_3.ttf'

    Save file, execute with "python". Obviously this is just a quick example (but it should work nevertheless).

    (Quick test result: TTF with 852 glyphs and post version 2 217 kb, afterwards with version 3 208 kb).

  • Danke, Lars! That should do it :)
  • Thanks. I figured it out. Does the script have to reside in the same folder as FontTools?
  • Mark SimonsonMark Simonson Posts: 1,080
    edited February 2015
    No. If you installed FontTools correctly, Python will know where to find it.
  • We noticed that choosing format 2 or 3 TTF affects appearance on Mac. As you can see in the image, format 3 tends to get fuzzier than the one with format 2 at every even size. Something is not getting rounded up at even size, which is really odd.

    The file size difference between format 2 and format 3 POST table is about 200 bytes in 100-glyph fonts. We haven't experimented with other number of glyphs though.
  • Toshi OmagariToshi Omagari Posts: 18
    edited February 2015
    Posting a bigger image. Sorry, I don't know how to replace or delete the previous one.
  • John HudsonJohn Hudson Posts: 1,600
    That's a really interesting phenomenon, Toshi. I suppose it's possible that the post* table format change is actually triggering some different behaviour within a single renderer, but I think it is most likely that what we're seeing is two different renderers in use. My guess is that Apple is using the post table format to determine to which renderer to pass the font, probably on the basis that the format 3 table was originally defined for use in CFF fonts (PS OTFs already contain glyph names in the CFF table, so the format 3 post table was introduced to the OT spec to avoid redundancy). I presume that the renderer to which fonts with format 3 post tables are passed handles both CFF and TTF outlines—which explains why the TTF display doesn't break completely—, but that its rounding algorithm is slightly different from the one to which fonts with format 2 post tables are passed.

    That's my guess. Could easily be wrong if the answer is simpler or yet more bizarre. In my experience, though, programmers love making assumptions based on coincidental data, and assuming format 3 post table = CFF font seems exactly the sort of thing they'd do. 

    * All uppercase table names indicate tables originated by Microsoft; lowercase table names indicate Apple; and the 'Zapf' table is just a silly name.
  • John HudsonJohn Hudson Posts: 1,600
    So it turns out I am wrong. Ned Holbrook writes:
    It’s something different. Certain (dumb) parts of the system really, really need glyph names to work correctly.
    Now trying to make up my mind which is dumber: what I suggested, or having rendering somehow dependent on glyph names.

  • I think unnecessary tables should be reduced as long as it doesn't change the visual. In the end, we are talking about the difference of up to a kilobyte or two, right? Ideally Apple should address this issue though.

    I didn't know that table names were case-sensitive. I'm still new to this bit.
  • This topic becomes more and more interesting!

    If the OP is only concerned about small file sizes for the web, then simply include glyph names for .ttf and exclude them for .woff. This is how it is done in FontCreator.

    Maybe you can save some more bytes by removing unused glyphs?
  • > I didn't know that table names were case-sensitive. I'm still new to this bit.

    I think John is referring to a convention, not a file format feature
  • In my testing, I was only able to observe the phenomena on a low (96dpi) resolution external monitor. It didn't replicate on the high resolution Retina display. As such, I'm guessing it won't get fixed. 
Sign In or Register to comment.