I've just reread the mail w.r.t. glyph classes, and I think the
following simplified version will do.
classes
Alike = A :A 'A `A ... ;
CJKpunct = u3000-u303F;
Hiragana = u3040-u309F;
...
CJK = @CJKpunct @Hiragana ... ;
properties
@CJK width 24
...
@Alike kern
Hello Werner,
Thanks for all the answers.
> > economic both in space in the font file format and in memory, rather
> > than a representation that enumerates character after character.
>
> This is what I mean with `classes', something like this in a font
> description file, using two new sections:
> > classes
> > = A :A 'A `A ... ;
> > = U+3000 - U+303F;
> > = U+3040 - U+309F;
> > ...
> >
> > = ... ;
> >
> > properties
> > width 24
> > ...
> > kern V -3
>
> I see. I had imagined the same thing with just the properties and
> no classes, like the PO
> > until we have real 32bit input slots
>
> I'm not sure what you expect here. The way it's currently done is that
> characters with name "u" are used.
[Please read section
`gtroff' internals
for more information too.]
There are different levels.
. The first level is input characte
Hello Werner,
Thanks for your answers. There are some answers that I will need time to
understand...
> until we have real 32bit input slots
I'm not sure what you expect here. The way it's currently done is that
characters with name "u" are used. What is the need to use a
32-bit 'int' value f
> So far, I have a first draft of a patch that makes groff work with
> Unicode fonts without having to first register thousands of
> characters.
Great!
> Before submitting the patch slice after slice, may I have your
> opinion about four questions?
>
> 1) In nametoindex.cpp and troff/charinfo.
Hi,
So far, I have a first draft of a patch that makes groff work with Unicode
fonts without having to first register thousands of characters. Before
submitting the patch slice after slice, may I have your opinion about four
questions?
1) In nametoindex.cpp and troff/charinfo.h, the term "ascii
