From: John Hudson (tiro@tiro.com)
Date: Fri Aug 08 2003 - 21:01:53 EDT
At 05:27 PM 8/8/2003, Kenneth Whistler wrote:
>Because the mechanism for doing so -- application to SPACE or
>to NBSP -- has been specified by the standard for a decade now.
True enough, but I'm also a bit concerned about this mechanism because
white space characters are another pesky thing that not all applications
paint. TEX, perhaps most famously, uses its own 'glue' instead of the space
glyph in the font. And what happens when word spacing is expanded or
contracted in text? The diacritic mark ends up being shoved to the left or
right of where it should be. Of course, if the space glyph is not painted
you have to rely on blind offsets for mark positioning, because unpainted
glyphs can't be found for smart positioning lookups. As someone who cares
about typography, I don't like blind offsets because they don't offer
precise enough control: I would much rather have a mechanism that I can
reliably and precisely use with glyph positioning lookups. I'm not
suggesting that the use of space/nbspace for this purpose should be
deprecated, only that an alternate mechanism would be useful for those who
want more control of how combining marks are rendered on a blank base.
A similar but not identical issue was raised by Peter Constable when we
were talking about Qere vs Ketiv readings in Biblical Hebrew. There are
cases in which vowels are applied to ellided consonants, which in some
texts results in marks applied to a blank base in mid-word. In this case,
my concern about using space or nbspace is that these imply a word break
where there is not, in fact, any break in the word: the blank base is part
of the word.
John Hudson
Tiro Typeworks www.tiro.com
Vancouver, BC tiro@tiro.com
The sight of James Cox from the BBC's World at One,
interviewing Robin Oakley, CNN's man in Europe,
surrounded by a scrum of furiously scribbling print
journalists will stand for some time as the apogee of
media cannibalism.
- Emma Brockes, at the EU summit
This archive was generated by hypermail 2.1.5 : Fri Aug 08 2003 - 21:37:21 EDT