Meaning of head.flags.LSBearing

I can't figure out whether the LSBearing bit (bit 1) of head.flags controls the horizontal metrics, or is simply an "efficiency" bit that represents all the LSB values in the 'htmx' table. Does:

(A) head.flags.LSBearing mean "ignore the per-glyph LSB values in the 'hmtx' table"? ... or

(B) Is it more of an advisory bit that certifies that the 'hmtx' LSB values all match the xMin values declared in the 'glyf' table for the corresponding glyph? ... or

(C) Some other, undreampt-of, interpretation.

-Clint
Tagged:

Comments

  • ClintGossClintGoss Posts: 3
    edited April 16
    It appears that two popular font authoring apps consider the head.flags.LSBearing bit to be advisory.
    Current versions of FontCreator and the Python-based ttx tool, set this bit based on the presence of any glyphs that have an LSB settings that differs from xMin setting for that glyph.
    It appears that these tools to not let the font author override the setting of the bit. In the case of TTX, altering the bit by editing the <head><flags value= ...> of a .ttx file has no effect - TTX forces the bit based on the glyphs.
    ** However ** if head.flags.LSBearing is advisory, then that bit should be set iff the font has glyphs where the LSB does not match xMin. I ran a script over 1,894 Open Source fonts and it turned up 140 fonts where this rule is broken(!). That is, head.flags.LSBearing is on, but they have glyphs (sometimes hundreds) where the LSB for the glyph (in the 'htmx' table) does not match the xMin in the glyph (or the actual minimum xMin value in the points of the glyph).
    So again, I'm not sure how these fonts should be handled ... do I:
    (A) honor the head.flags.LSBearing bit and use xmin instead of the glyph's LSB declaration or
    (B) use the glyph's LSB declaration?
    By the way, I also compared the four bounding box values in each glyph against the bounding box implied by the most extreme points in each glyph. 368 of the 1,894 fonts had at least one error of this type (!! again)

    -Clint
  • Jens KutilekJens Kutilek Posts: 204
    The description of this bit in the OpenType spec on the Microsoft site says:
    Left sidebearing point at x=0 (relevant only for TrueType rasterizers)
    If I understand it correctly, the effective sidebearing of a glyph could be altered by the LSB value in the hmtx table.

    You could, for example, design a glyph without left sidebearing, which means xMin would be 0. The LSB in the htmx table could be used to give the glyph a LSB of e.g. 50 font units. In this case the head table bit must not be set.
  • Jens KutilekJens Kutilek Posts: 204
    ** However ** if head.flags.LSBearing is advisory, then that bit should be set iff the font has glyphs where the LSB does not match xMin. I ran a script over 1,894 Open Source fonts and it turned up 140 fonts where this rule is broken(!). That is, head.flags.LSBearing is on, but they have glyphs (sometimes hundreds) where the LSB for the glyph (in the 'htmx' table) does not match the xMin in the glyph (or the actual minimum xMin value in the points of the glyph).
    The question is, how big is the difference? If it is very small, it could simply be a rounding error. If the leftmost point of a contour is not an on-curve point, but a curve, the precise value may be a floating point value, but the LSB value must be rounded to an integer value.
  • ClintGossClintGoss Posts: 3
    Thanks Jens ... this is a real head-scratcher for me!

    So ... hmtx.leftSideBearing is an array of int16's, which I'm taking to be +/-funits. The glyph.xMin entries are also int16's. If head.flags.LSBearing is set, I was thinking that htmx.leftSideBearing for a glyph should be the same as glyph.xMin for that glyph, using integer comparison.
    If the leftmost point of a contour is not an on-curve point, but a curve, the precise value may be a floating point value, but the LSB value must be rounded to an integer value.
    Oh, that's a whole kettle of headaches. I was thinking that bearings and xMin values were both simply the location of some (left-most) point in the glyph. However, do we have to (essentially) extrapolate the curve shape pulled by an off-curve point and figure out where it's (left-most) bound is?? Is that the way it really works??

    (I'm gonna need some chocolate before I ponder this ...)

    -Cint
Sign In or Register to comment.