Re: [Groff] Some thoughts on glyphs

[Bernd Warken]

On Fri, Apr 19, 2002 at 08:55:44AM +0200, Werner LEMBERG wrote:
>
> I believe we need a generalization of the glyph accessing
> mechanism.

Definitely :)

> It doesn't make sense to invent more and more glyph names.  Following
> the AGL (Adobe Glyph List) algorithm is probably the best we can do;
> this is, having glyph names like `uni2317.ugly', where `uni2317' is
> Unicode character U+2317, and the suffix after the comma the glyph
> variant.

What about U+2317.whatever and \[U+2317]?                 

> My main concern in this mail is not Unicode (which causes a bunch of    
> different problems)

Yes, 32-bit characters won't make it into groff 1.18.            
The ANSI C++ Standard Library provides automatic Unicode support;              
unfortunately, we cannot use it for compatibility and security reasons.
It's quite a hazzle to write a container/character library without          
using streams and templates, but it seems to be possible.

> In LaTeX, the natural answer would be `\k{A}' -- \k is a macro which         
> takes `A' as a parameter, converting it directly to an Aogonek glyph
> if available, putting an ogonek accent below the A glyph otherwise.
> In troff, I don't see an immediate answer.  The latter solution is
> available, i.e., putting the ogonek accent below the `A' (using \z or
> something similar in case both glyphs are spacing), but the former
> isn't possible, except by defining a string for each possible
> ogonek-baseglyph combination.
>
The combination of characters is an essential part of Unicode, maybe
we can find a solution by implementing parts of the Unicode standard.
The Unicode book describes in ch. 2.6 "Combining Characters" that some
characters are defined as "combining" or "nonspacing" characters, most
of which are in the range from U+3000 to < U+3700.

groff could define such combining characters as well and map some of
them to existing glyphs, but without spacing.  So far, the groff accents
correspond rather to the "spacing" equivalents found in the range
U+02B0 to U+02FF.      

> Thus I suggest to extend the \[...] escape:
>
>   \[<base glyph> <accent glyph 1> <accent glyph 2> ...]      
>
This looks reasonable.  I still plan to implement an extension for
calling a macro with arguments from within an escape.  To avoid name
clashes with your intended character syntax above, I could use
\[.macro arg ...] for the macro call.

Bernd Warken