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 msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -------------------------------------------------- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
