Monospace font attributes

Dave Crossland
Dave Crossland Posts: 1,429
in Technique and Theory
Monospace fonts should have a few attributes in accord to ensure they are treated as monospace fonts. Are the
  • all glyphs have the same advanceWidth
  • post table isFixedPitch is 1
  • panose bProportion is 9
Any others?

Comments

  • John Hudson
    John Hudson Posts: 3,186
    That should cover it.
  • Georg Seifert
    Georg Seifert Posts: 674
    And what about the nonspacing marks? I just tried it in Indesign and the spacing of the mark is always added. MacOS does seem to ignore the width of the marks (not sure if that is a bug or a feature in this case).
  • John Hudson
    John Hudson Posts: 3,186
    In monospaced fonts, all glyphs have to share the same advance width, including combining marks and other normally zero-width glyphs, and some software will enforce this by caching the advance width of a representative glyph and then using it for all others. But this happens at an early stage in the layout, before OpenType Layout is applied, so we fit combining mark glyphs in the font on the monospace width, and then use an initial lookup in the GPOS <mark> feature to collapse the width of combining mark glyphs to zero before positioning. You can test this with e.g. the MS Consolas and Courier New fonts, which are built in this way.
  • Dave Crossland
    Dave Crossland Posts: 1,429
    So its,
    • all glyphs have the same advanceWidth, except combining marks which have a 0 width
  • John Hudson
    John Hudson Posts: 3,186
    No. All glyphs including combining marks, have the same advance width, but the advance width of combining marks may be collapsed in GPOS.
  • Georg Seifert
    Georg Seifert Posts: 674
    But why do it easy if there is a complicated solution.
    The averageWidth field ignores the width of zero width glyphs so I thought that would allow them in monospaced fonts.

    I'll check Consolas.
  • Erwin Denissen
    Erwin Denissen Posts: 300
    On 6/2/2015, John Hudson wrote:
    > No. All glyphs including combining marks, have the same advance width

    Both Consolas and Courier New come close to this requirement.

    Consolas still includes 6 glyphs with a zero advance width:
    - 09, 0D (nonmarkingreturn)
    - 200C (zero width non-joiner)
    - 200D (zero width joiner)
    - 200E (left-to-right mark)
    - 200F (right-to-left mark)
    - FEFF (zero width no-break space)

    Courier New has one glyph:
    - 00, 08, 1D (.null)

  • John Hudson
    John Hudson Posts: 3,186
    Georg, I don't think the averageWidth field of the OS/2 table is actually used by software handling layout for monospaced fonts. Rather, the width of a representative glyph (e.g. /space/) is cached, and then used to advance the width of all painted glyphs, regardless of their encoding. This exlains the behaviour you see in e.g. InDesign if you try to make mark glyphs zero-width in a monospaced font: they end up getting assigned the same advance width as the others in line layout.
  • John Hudson
    John Hudson Posts: 3,186
    Erwin, those are all normally non-painted control characters, so the glyphs are not seen. Some of them may be displayed in editing modes, though, so I suppose some software might have special overrides for these characters, enabling them to be displayed as zero-width in some environments, but other software may simply display them on the common monospace advance width
  • Erwin Denissen
    Erwin Denissen Posts: 300
    edited June 2015
    Thank you for clarifying.

    Still odd that the nonmarkingreturn in Consolas is zero-width while the recommendations say it should have a positive advance width (which should be equal to the advance width of the space glyph).
  • Khaled Hosny
    Khaled Hosny Posts: 289
    AFAIK, the width cashing is only done when isFixedPitch bit is set. If one wants to do a mono space font the easy way, he can just not set that bit. Some software might not recognise the font as a mono space font but that mostly harmless AFAICT.
  • John Hudson
    John Hudson Posts: 3,186
    Erwin, yes, that's technically a bug.
  • Dave Crossland
    Dave Crossland Posts: 1,429
    Khaled, I think some applications (like terminal emulators) require it to be set
  • Khaled Hosny
    Khaled Hosny Posts: 289
    I have seen some applications that use that bit to list monospace fonts, but if you select a monospace font that does not have it set they will work just fine. If you know an application that refuses to use monospace fonts without isFixedPitch being set, I’d like to know about it. Also since isFixedPitch really have a very specific meaning (every signle glyph in the font have the same width) I’m with the opinion that OpenType should provide a better way to indicate monospaced fonts that does not have this requirement, may be one of the unused OS/2 fsSelection bits.
  • Viktor Nübel
    Viktor Nübel Posts: 13
    I’m working on a monospaced font and trying to get it to work in Sublime Text (code editor). Automatic syntax highlighting in Sublime Text works with italic, but this is lost. It works with other monospaced fonts like Consolas or Input.

    Naming and style linking in the four fonts (Regular, Italic, Bold, BoldItalic) are correct. Panose bProportion is 9, isFixedPitch is 1, advanceWidthMax and xAvgCharWidth is equal for all.

    Anything else I did forget?
  • Erwin Denissen
    Erwin Denissen Posts: 300
    The information you provided doesn't reveal any issues, but I don't fully understand the problem.

    > Automatic syntax highlighting in Sublime Text works with italic, but this is lost.

    Do you mean to say your regular font does work?
  • Viktor Nübel
    Viktor Nübel Posts: 13
    Apologize for not replying on this sooner ... haven’t been here for a while.

    The problem was that Sublime Text did not show the italic style of the font.
    I could not really figure out what the problem was, but in the  end it worked and everything showed up correctly in Sublime Text.

    One thing I found out was, that all 4 styles need to be installled (Regular, Italic, Bold, BoldItalic), even if Sublime Text would only use Regular and Italic. All four fonts need proper naming and style linking. I also used ttfautohint, and after runing all fonts through ttfautohint it worked fine with Sublime Text. Additionally I used the CA font family naming script for the naming.
  • Belleve Invis
    Belleve Invis Posts: 269
    John Hudson said:
    Georg, I don't think the averageWidth field of the OS/2 table is actually used by software handling layout for monospaced fonts. Rather, the width of a representative glyph (e.g. /space/) is cached, and then used to advance the width of all painted glyphs, regardless of their encoding. This exlains the behaviour you see in e.g. InDesign if you try to make mark glyphs zero-width in a monospaced font: they end up getting assigned the same advance width as the others in line layout.
    OS/2.xAverageWidth IS used when rendering monospaced fonts, at least by Windows GDI. GDI will apply this value to all "simple" glyphs, while CJK glyphs (like 中) will use this value times two.

Categories