groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Some thoughts on glyphs


From: Werner LEMBERG
Subject: Re: [Groff] Some thoughts on glyphs
Date: Fri, 19 Apr 2002 16:34:47 +0200 (CEST)

> > 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]?

Why shall I invent something new?  The AGL is in use since a few
years and has been working fine.

> 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.

Note that I need more than Unicode: Positive values will be real code
points, while negative values will represent internal characters
(there are about 20 IIRC).

> 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.

Using \z or \o we can easily convert a spacing glyph into a
non-spacing one.  This is not an issue.  The real problem is that we
can't stack accents properly without manual intervention.

> 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.

Please use \*[foo bar] since you can already call a macro with \*.


    Werner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]