Re: [Groff] Character class support patch

[brian m. carlson]

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, `uXXXX' entities have to be converted too.
> For example,
>
>  foo  A - u1000 ;
>
> is the range U+0041 - U+1000.  For simplicity I think it's best to
> disallow composite entities in ranges (but not as single values).

Okay.  It didn't occur to me until just now that these were separate 
concepts, but I see how they are.  This will take some reworking.

> For a given class, the lookup process first checks the `ranges' array,
> then it walks over the `composites' array, and after something has
> been found it is converted to a glyph index.  [The above code is just
> for demonstration purposes, not to be meant for a real
> implementation.]

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.  I was planning on loading the names of glyphs, then 
iterating over the list of glyphs and manipulating the charinfo::flags 
field for each of those glyphs.

Is it still possible to use Unicode values, build the classes from those 
values, and then manipulate the corresponding glyph structs for each 
Unicode value?  That would be the easiest way, but maybe that can't be 
done and I'm not getting something you said. 

> Reason for using Unicode values everywhere and not directly glyph
> indices: The reuse of the class mechanism on the input side, and doing
> so should not depend on fonts.

Are glyphs specific to fonts?  It doesn't seem so to me, but if so, 
forget my question in the previous paragraph.

[storing character classes in font files]
> This is a bad limitation, I think.

Okay.  I suppose I'll have to implement a new file for declaring 
classes.  Either that or I could implement requests that do that.
Your choice.

> With other words, classes within a font description file should be
> local to this font's glyphs.  Contrary to that, classes on the input
> side should be indeed valid for all characters.

That makes sense.  I'm more interested in implementing input classes 
right now, but I might be able to be convinced to implement font classes 
later.  IMHO, they seem like different concepts, since one deals with 
input and one deals more with the output side.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

signature.asc
Description: Digital signature