It occurred to me that maybe we should slightly alter the meaning of S<...>.
Currently, S<happytime coding> means the text "happytime coding" with the
proviso that the space between the words cannot be the point at which the
line is broken. I.e., that this is not a good rendering:
...bluh bluh bluh bluh bluh bluh bluh bluh happytime
coding bluh bluh bluh bluh bluh bluh bluh bluh...
However, a literalist construal of the spec doesn't say anything about
rendering S<happytime coding> like this:
...bluh bluh bluh bluh bluh bluh bluh bluh happy-
time coding bluh bluh bluh bluh bluh bluh bluh bluh...
or otherwise splitting the content of the S<...> by hyphenating it.
Clearly this is not a problem for formats like HTML where (typically) there
is no chance of a hyphenated rendering.
But for applicable formats, I think it's reasonable to say that S<...>
means not only "don't use any spaces in here as potential
line-breakpoints", but also "don't hyphenate anywhere in here".
Thoughts?
Notably:
In what applicable formats is this feasable?
In RTF, I don't think there's any code that means "turn hyphenation off for
these few words" -- although I'm guessing you could fake it by either:
* inserting a \zwnbo ("zero width non-break opportunity", which I think is
Redmondese for what Unicode calls a "zero width no-break space", o+FEFF)
between every pair of characters, or:
* turning off the "language features" for this stretch of text, i.e.,
\noproof and/or \langNNNN where NNNN is the code for an innocuous language
that no-one will have a hyphenation file for.
Neither solution sounds terribly elegant, and I blame on the predictable
awfulness of the design of RTF.
Is there a tidier way in other formats where hyphenation could occur, like
*roff?
--
Sean M. Burke http://www.spinn.net/~sburke/
