[Top][All Lists]

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

Re: [Groff] Character class support patch

From: brian m. carlson
Subject: Re: [Groff] Character class support patch
Date: Mon, 7 Jan 2008 18:16:20 +0000
User-agent: Mutt/1.5.17 (2007-12-11)

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

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 | | My opinion only
a typesetting engine:
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Attachment: signature.asc
Description: Digital signature

reply via email to

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