Questions re. generating ttf in Fontlab

I wonder about a few options/checkboxes in Font Info > TrueType specific settings and Preferences > Generate OpenType & TrueType that I can’t seem to find much info about. And, also a wildcard that I’d like to discuss.

• Automatically reorder glyphs. From what I have read, this only affects CFF-OT fonts in OS9 (not very relevant for me). Karsten Luecke on Typophile: “In CFF-OT fonts, the first glyph must be .notdef. And in TT(-OT) fonts, the first four glyphs must be .notdef, .null, CR and space.” I assume this talks about the glyph ID order. I wonder where/how I can inspect or modify this.

• HDMX settings: What determines the sizes I should apply this for? The sizes I have hinted?

• Copy HDMX data from base to composite glyph: I’m not sure what this part means. Can anyone explain?

• Create VDMX table: I use some vertical delta instructions, so I assume FL is correct when it says I need to check it, but what does it actually do?

• Re. kerning settings: When I am making webfonts, file size is very important. From what I’ve read, browser support for a flat kerning table is as spotty as the support for OT class kerning. Also, people are pushing for OT support because that’s the cool stuff. (And David Berlow only includes a selected few kerning pairs in the RE fonts. I can understand that for stuff that is only geared at text sizes, btw. Even the retina screen is lowres when it comes to kerning at text sizes.) So: I am only exporting OT class kerning. What are you doing? Why?


Comments

  • edited September 2013
    Also:

    • The two options “Write stored native TrueType hinting” and “Export visual TrueType hints”. What are these referring to?
  • HDMX and VDMX: AFAIK these tables can only be compiled if you've told FontLab where your copy of CacheTT is on a Win system.
    HDMX gives the system a quick way to anticipate line-lengths, before it's rendered every glyph in the string. It renders each glyph at the sizes you've tagged and stores each glyphs' advance width as rendered. It's mostly needed at sizes you've hinted, because the only time this stored value is different than the calculated value of advance width in units is different than the rendered result is when you've applied deltas to the advance width of the character. This is why you almost always want to check "copy from base to composite", as most composite characters (glyph+accent above or below) will be the same as the base glyph's advance width. Unless you've delta'd the advance width of an accented cap I, for example.

    VDMX I believe is only used by Microsoft products. It renders each glyph in the font at the sizes specified and stores the value in pixels of the tallest glyph for each size. This value can then be used for line spacing. In this way, nothing is ever "chopped off" for being taller than the rendered value of the specified line height. for example, sometimes, if the A+ring is a composite, and you've hinted by forcing a white pixel or more between the top of the A and the ring, the height of the character will exceed the height of the WinAscent, and the top of the A+ring will disappear. Using the VDMX, this won't happen, as the line height will be based on the height of the A+ring at that size, not the default WinAscent value. Of course it's always better to just hint with this value in mind and not allow anything to go taller than the WinAscent would go, but this is a fail-safe.

    FWIW, the VDMX is small and does no damage, so might as well add it. The HDMX is much larger, so calculating for size that either aren't hinted or contain no deltas adds unnecessary bloat.
  • D. Epar tedD. Epar ted Posts: 669
    edited September 2013
    The ..mx tables record metrics not linear to the outlines changed by hinting. So, unless your hinting is changing a lot of widths or heights...Kerning, I'm waiting... As you say Frode, support is spotty, file size is critical, and I hope the web grows out of it. When it does we will be ready with different solutions for different uses, dependent on the font, environment and users.
  • • Automatically reorder glyphs. . . . I assume this talks about the glyph ID order. I wonder where/how I can inspect or modify this.
    You can inspect glyph order by dumping the font with TTX and reading the table in XML format.
  • Kerning, I'm waiting... As you say Frode, support is spotty, file size is critical, and I'm sure the web will grow out of it. When it does, I suggest one should be ready with different solutions for different uses, dependent on the font, environment and user.

    "Export visual TrueType hints”. What are these referring to?"

    If written ""Export Visual TrueType hints”, it would be clearer that it's writing VTT tables for MS's visual TrueType editor to read allowing editing of hints.

    "Write stored native TrueType hinting” I would guess refers to pre-existing hinting in the font, since the only place to "store" anything is in the font you started with.

    ...and Copy HDMX data you should do if you need HDMX in the first place, but you'd like to count on later subsetting and recaching of the HDMX at the time of web delivery.
  • Yeah, the "visual TrueType" thing is confusing, they should have used another word. In this case I believe they refer to the hints generated by FontLab's hint tool. Unfortunately it can't create MS VTT hinting tables.
    As David noted, stored native TrueType hints is the hinting instructions present in the glyph table, so if you had hinted the font with VTT or ttfautohinter, you'd need to check that box in order to retain the hints you'd generated.

    Although I haven't got 100% results you'd think from that last part, so I was hoping Adam might chime in with some info.
  • edited September 2013
    So, what happens if there is no HDMX table? Can it render wrong advanced widths (and then only in pre-Cleartype environments, I presume)?
  • Stored native TrueType hints: If these are hinting instructions present in the glyph table, this is only relevant if I open an externally hinted font in Fontlab — correct? If this is my .vfb that I hinted in FLS, the only one to check would be “Export hinted TT font”?
  • This is a lot to digest for a brain primarily running on pipe tobacco and coffee, but thanks a lot for the answers so far.
  • edited September 2013
    I take that back. I definitely have to check “Store native TrueType hints”.
  • I thought so. :) and I agree that only aliased rendering needs hdmx. And thanks for the vTT vs VTT correction.
  • John HudsonJohn Hudson Posts: 943
    edited September 2013
    The device metrics tables cache metrics for specific ppem sizes. They were added to the TT spec by Microsoft to enable applications to calculate line layout without first needing to calculate ppem metrics by scaling individual hinted glyphs. Their importance diminishes over time, as processing power and memory increases, since the operations that they were designed to avoid needing to do are now much faster.

    I was discussing this with Greg Hitchcock and others at MS last week, and with some caveats regarding the need to test results, the general opinion seems to be that these tables can be safely removed from fonts. If they are not present, software will need to calculate the ppem metrics rather than relying on the cache tables, but that's doable and in the context of things like webfonts there may be a net performance gain in not serving and decompressing the device metrics tables.
    So, what happens if there is no HDMX table? Can it render wrong advanced widths?
    What's 'wrong'?

    You shouldn't see any difference if the hdmx table entries were cached from the same scaler that is now calculating the advance widths on the fly. This is what an hdmx table is: cached values from a scaler (which is why the best way to set them is to run cachett, so your hdmx table ends up with the widths that the Windows scaler calculates; I've no idea how FontLab comes up with its device metrics values otherwise: Font Validator invariably flags them as incorrect when it runs its rasterisation tests).
  • I agree that only aliased rendering needs hdmx.
    No rendering needs hdmx. It's just a cache table, and the same values can always be calculated on the fly from the hinted widths of the glyphs. The hdmx table is an efficiency measure that speeds up line layout by making the calculated values available as a data set.
  • BTW, if you don't ship an hdmx table, but your font does include glyphs whose widths do not scale linearly, then you still need to turn on bit 4 of the head table flags. Otherwise, software may skip hints when performing line layout.
  • John HudsonJohn Hudson Posts: 943
    edited September 2013
    I stand corrected on the origins of hdmx. Thanks, David. I thought it came in with the VDMX and LTSH tables.
Sign In or Register to comment.