Re: [Groff] Character class support patch

[Werner LEMBERG]

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

Be careful here, because...

> 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.

Be careful here, because...

> > 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?

There are three different stages which must be carefully distinguished
to get the implementation right.

. First of all, there are input characters which groff processes to
  input tokens.  Examples: `a', `\[foo]', `\,'.

. Internally, groff stores everything as objects which I call `groff
  entities' (right now I'm in the process to review the documentation
  to get this right everywhere, among other things).  It holds the
  original input token and its associatiated parameters (most notably
  the hyphenation and input code values), a certain amount of state
  like current font, font size, colour, etc., and, after the input
  data has been processed, the output glyph.  (This is `charinfo_node'
  and its derived classes, mainly in troff's node.cpp).

. On the output side, we have glyphs, either with a name (like `a',
  `foo', etc.) or without a name (to be accessed by glyph index with
  \N'...'), and which have physical dimensions like width, height,
  depth, italic correction, etc., and are thus specific to fonts.

So the answer to your question is `yes'.

The difficult balance between input tokens and glyphs can be
demonstrated with the .char request:

  .char \[foo] abc

This \[foo] object could be considered as an input token (since I can
assign a hyphenation code to it, and it is not dependent on a specific
font (remember that objects created with .char are processed on the
fly and not in advance).

However, how shall I categorize this one?

  .char \[bar] \f[I]abc

I still can assign a hyphenation code to \[bar], however, it behaves
like a glyph because it no longer changes the appearance but is always
printed with font `I'.

Consequently it's best to consider those `groff entities' as the
central internal structure (comparable to LICRs, the LaTeX Internal
Character Representations).

> [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.

Hopefully, my explanations above have shown that we need both: on the
request side to provide classes support for input token attribute
manipulation, and on the font definition file side to do the same for
glyph properties.

> >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.

Maybe.  However, I think it would be beneficial to use the same syntax
more or less for both the input tokens and glyph classes.


    Werner