> The reason I was using glyphs is because I was hoping the .cflags
> request mechanism could be coerced into implementing features needed
> for kinsoku shori.
This correct: The .cflags mechanism is the right place to assign
character flags for kinsoku shori.
> I was planning on loading the name
On Sun, Jan 06, 2008 at 11:00:13PM +0100, Werner LEMBERG wrote:
The range mechanism must rely not on glyph names (or indices), but on
Unicode values. This is, all (predefined) groff entities must be
mapped to the equivalent Unicode value(s) as given in file
glyphuni.cpp. Similarly, `u' enti
> > Additionally, we need support for handling Unicode ranges:
> >
> >CJKpunct u3000 - u303F;
>
> My intention was that any valid glyph name was to be valid as a
> class character, but name_to_glyph apparently doesn't handle
> Unicode characters. Should I be using a different functio
> >What do you think of this syntax which reduces redundant syntactical
> >sugar:
> >
> > classes
> >ClassName A B C D E;
> >EquivalentClassA - E;
> >UppercaseAlphabet @EquivalentClass
> > F - Z;
> >MostEfficient A - Z;
> >Identifier
On Fri, Jan 04, 2008 at 08:44:20AM +0100, Werner LEMBERG wrote:
A first remark without looking at the details of the patch (which
looks very clean, BTW):
Thank you.
What do you think of this syntax which reduces redundant syntactical
sugar:
classes
ClassName A B C D E;
Equiv
A first remark without looking at the details of the patch (which
looks very clean, BTW):
> character classes. The syntax is as follows:
>
> classes
>= A B C D E
>= A - E
>= F - Z
>= A - Z
>= - A - Z a - z
>= A - Z - a - z
What do you think of t
