[XeTeX] why does Latin Modern Mono have some stretch and shrink with XeTeX ?

[mskala at ansuz.sooke.bc.ca]

On Wed, 25 Jan 2017, Ulrike Fischer wrote:
> There was once a long discussion about this xetex problem around
> here http://tug.org/pipermail/xetex/2011-February/020072.html
> It is unclear if it is engine bug and imho no one ever added
> something to the issue tracker.

That was a long, complicated discussion touching on multiple issues:
between-sentence space, what actually is a monospace font, etc.  I
probably don't remember all the details clearly, and probably neither does
anyone else.  But I did skim through the archive just now and it does have
some useful information in it.  Worth reading the rest of the thread -
that particular posting isn't the last word on the issues it describes.

There is also an earlier thread in September 2010 about stretchability of
spaces in monospace setting, which may be relevant.

There were three items in the fontspec issue tracker and I think they've
all been long since dealt with.  But the goal in 2011 was for fontspec in
particular to correctly handle monospace spacing through size changes when
it had been told by the document that the font was monospace.  There
wasn't solid agreement on whether it's really a XeTeX bug that XeTeX
without fontspec initially sets those fontdimens nonzero.  Since fontspec
overrides them anyway, and that case wasn't important to the most vocal
complainers at the time (mostly myself), that particular point was never
explored further.

Using XeTeX without fontspec is a relatively unusual case and it's
unsurprising there hasn't been a lot of time spent on testing that.  The
engine and package go together.

The "monospace" flag in OpenType is unreliable.  It's probably not a good
idea to depend on its having a useful value.  Testing the comparative
widths of "i" and "m" is probably a better way to detect monospace fonts,
and as I understand it, that's what fontspec now does.  XeTeX itself could
do the same.

Even if the "monospace" flag in OpenType were reliably set according to
the OpenType specification (which we can't assume), it might not be
correct to use it. There is debate over correct interpretation of the
specification, but the consensus appears to be that the flag is supposed
to be set if and only if absolutely every glyph in the font with nonzero
width has the same width.  There are many fonts where more than one
distinct nonzero width exists, and so the flag ought to be turned off,
even though the fonts really are monospace in some important sense and
should be treated as such for purposes like sentence spacing.  For
instance, this is the usual case for CJK fonts, which are traditionally
set on a grid with CJK characters consuming a full square each and Western
characters consuming half a square each.  CJK fonts are especially
relevant to XeTeX.  Thus, we cannot trust the "monospace" flag in OpenType
to correctly tell XeTeX whether monospace-related adaptations like
unstretchable space, should be applied.

We cannot redefine the "monospace" flag to have a more useful value. Some
other software and maybe even hardware assumes that the OpenType
"monospace" flag is set if and only if absolutely every glyph in the font
with nonzero width has the same width.  These other systems will break if
their assumption is incorrect.  Thus even if we can edit font files to
have this flag set in a way that correctly tells XeTeX whether to apply
monospace-related adaptations, it would be a bad idea to use the flag
that way.

-- 
Matthew Skala
mskala at ansuz.sooke.bc.ca                 People before principles.
http://ansuz.sooke.bc.ca/