John Hudson wrote:
> At 13:13 6/20/2002, Peter_Constable@sil.org wrote:
>
> >If by "the options" you mean "what kind of mechanism would
> it take?", then
> >it would amount to a substitution rule along the lines
> (using some pseudo
> >notation) of
> >
> > gU1368 > gU1368_a [colour = red] gU1368_b [colour = black]
> >
> >or
> >
> > gU1368 > gU1368_a [colour = alt] gU1368_b [colour = default]
>
> Yes, that is the sort of thing I meant by 'options', but also more
> generally what are the different approaches that one might
> take to the problem?
The approach of having two overlapped glyphs is perhaps a little bit of a
hack, isn't it? In scripts where alternating colors is done more
extensively, this would require lots of glyph substitutions.
E.g., in some Arabic calligraphic codices, the dots have a different color
than the stems: this would require splitting each Arabic glyph into two
semi-glyphs. And I can't imagine the complexity this approach could leat to
if the Atztec writing(?) system would be encoded.
*If* there was a real need for such a feature, I think that it should be
implememted at the level of single contours, rather than at the level of
whole glyphs.
For instance, a "color" attribute could be added to each contour composing a
glyph. In True/Open Type terms, this would probably mean changing table
"glyf". If two (or four) colors are enough, the new "color" attribute could
be fitted in one (or both) reserved bits in the contours' "flags". Of
course, the color attribute would be meaningless and unused for countours
defining "holes".
Alternatively, the color attribute could be stored separately from the
contours themselves. For each contour not having the default color, the
following information should be stored in the font: { GlyphId,
CountourIndex, ColorCode }. In True/Open Type terms, I think this would mean
to add a new table (in which GlyphId is an index inside the "loca" table).
For bitmapped fonts this would require to increase the bits-per-pixel for
the glyphs having multiple colors. There also is an aproach that could fit
both contour and bitmapped fonts, but is probably very inefficient: a list
of flood-feel seed points, where each element should have the following
information: { GlyphId, X, Y, ColorCode }.
> I know of at least one other option, but I'm under NDA :)
I hope none of my wild ideas matched your proprietary solution...
_ Marco
This archive was generated by hypermail 2.1.2 : Fri Jun 21 2002 - 03:28:33 EDT