[Top][All Lists]
[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