Re: [Groff] Re: groff: radical re-implementation

[Ted Harding]

Hi Werner (and all)

Thanks for this clarifying explanation. I have a couple of comments,
one explanatory, the other which, I think, may point to the core
of the question.

On 21-Oct-00 Werner LEMBERG wrote:
>> Troff's multi-character naming convention means that anything you
>> could possibly need can be defined, and given a name in the troff
>> input "character set" whenever you really need it, so long as you
>> have the device resources to render the appropriate glyph.
> 
> There are only 256 `multi-characters' named `charXXX'.  Everything
> else are glyph entities (even if they behave like a character in most
> cases).  The reality is that groff doesn't really make a difference
> between a character and a glyph, and it has high priority to me to
> implement this distinction.  I'll probably start with renaming a lot
> of troff internals.

1. Perhaps I should clarify: by "multi-character naming convention"
I mean the fact that you can decide to use the sequence of ASCII
characters, for instance, "\[O-ogonek]" as the name of a "character".

In passing: I see no _logical_ distinction between using a string
of ASCII characters to name a "character", and using a string of
bytes which implements a UTF-8 encoding.

2. Perhaps it is a good point of view to see troff (gtroff) as an
engine which handles _glyphs_, not characters, in a given context of
typographic style and layout. The current glyph is defined by the current
point size, the current font, and the name of the "character" which is to
be rendered, and troff necessarily takes account of the metric information
associated with this glyph.

The fact that ASCII characters and the iso-latin-1 characters
corresponding to byte-values > 128 are (by default) the troff names of
"characters" in a group of European languages -- together with certain
other marks and symbols -- is logically (in my view) an irrelevant
coincidence which happens to be very convenient for people using these
languages; but it is not at all necessary. Nothing at all stops you from
defining

  .char a \*a

as the name of Greek "alpha", and so on, if you want to simply the typing
of input in a passage of Greek using an ASCII interface.

Logically, therefore, troff could be "neutral" about what the byte "a"
stands for. From that point of view, a troff which makes no assumptions
of this kind, amd which consults external tables about the meaning of
its input and about the characteristics of what output that input
implies, purely for the purpose of correct formatting, is perhaps the
pure ideal. And from that point of view, therefore, unifying the input
conventions on the basis of a comprehensive encoding (such as UTF-8
or Unicode is intended to become) would be a great step towards
attaining this neutrality.

However, I wish to think more about this issue.

Meanwhile, interested parties who have not yet studied it may find
the "UTF-8 and Unicode FAQ for Unix/Linux" by Markus Kuhn well worth
reading:

  http://www.cl.cam.ac.uk/~mgk25/unicode.html

By the way, your comment that hyphenation, for instance, is not a "glyph
question" is, I think, not wholly correct. Certainly, hyphenation _rules_
are not a glyph question: as well as being language-dependent, there may
also be "house rules" about it; these come under "typographic style" as
above. But the size of a hyphen and associated spacing are glyph issues,
and these may interact with where a hyphenation occurs or whether it
occurs at all, according to the rules.

An interesting debate!

Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 284 7749
Date: 21-Oct-00                                       Time: 23:47:03
------------------------------ XFMail ------------------------------