Follow-up Comment #2, bug #59402 (group groff): [comment #1 comment #1:] > (Hmm, I should probably quote that last bit of syntax > since it can break, as shown.)
Does "man" disallow the \~ escape?
> Solving this problem would, I think, require that _every_
> character-resolvable-to-a-glyph that GNU _troff_ reads
> not be processed immediately, but held in some kind of
> staging area while input processing continues,
Yes, that all makes sense for the input side.
But this feels to me more like an output problem anyway. It's when outputting
the glyph nodes that the formatter has to worry about, for instance, how wide
each glyph is, in order to know when it has reached the line length. This is
significant because, potentially, the width of an o followed by a combining
diaeresis might be the width of the o, while the width of an i followed by a
combining diaeresis might be the width of the diaeresis, especially in a sans
serif typeface. Maybe there are even cases where the combined width is
neither value directly.
Since questions like this _cannot_ be resolved on input, it seems to make
sense for the input processor to merely encode any combining characters as
nodes without regard for _what_ they combine with, and let the output
machinery sort that out.
And the output machinery has to remember the contents of at least the current
output line, because it will sometimes have to go back and widen the spaces
for adjustment. So as long as there is no way for a combining character to
appear on a different line from what it combines with (and I can't offhand see
how such a thing would make any sense), the output side ought to be able to
handle all that mashing together of glyphs without having to retool the basic
way it works.
I realize that that "ought to" papers over a deep chasm of my ignorance on how
the output works. If the output mechanism makes the problem just as
intractable, you're welcome to say so without needing to feel compelled to
write an essay about how it works.
> I think the only thing to do here in the short-to-medium
> term is to fix the _preconv_ bug.
That would certainly improve on the status quo.
If changes to the formatter are deferred indefinitely, I'd reiterate my
documentation point from bug #57618: "Users can always directly embed \[uNNNN]
escapes directly in their source, meaning troff should be equally conversant
with '\[u006F_0308]' and 'o\[u0308]', unless we specifically document that the
latter is disallowed." (Maybe this has been documented since I wrote that six
years ago; I admit I didn't check.)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?59402>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
