Re: [PATCH] text layout implementation

[Sascha Brawer <brawer at dandelis dot ch>]

graydon hoare <graydon@redhat.com> wrote on Wed, 19 Nov 2003 15:38:19 -0500:

>Sascha Brawer <brawer@dandelis.ch> writes:
>
>> Also, does the proposed implementation work if there are changes in any
>> attributes other than font, such as TextAttribute.UNDERLINE? It seems
>> that all these attributes are lost by passing Strings.
>
>well, the CharacterIteratorProxy I've implemented (modified patch
>below) doesn't do the whole AttributedCharacterIterator interface, but
>there's no method on Font to create a glyph vector with an
>AttributedCharacterIterator anyways. I think we'd have to interpret
>extra attributes as calls to deriveFont or something, no?

Hm, it's really tricky... AttributedCharacterIterator is actually a
subinterface of CharacterIterator, so Font.createGlyphVector could handle
some of the attributes. But presumably only those which manifest in glyph
selection and placement -- probably BIDI_EMBEDDING, CHAR_REPLACEMENT,
JUSTIFICATION, NUMERIC_SHAPING, RUN_DIRECTION, SUPERSCRIPT. I guess one
would want to pass them to Font.createGlyphVector, but I'm not really sure.

FAMILY, FONT, POSTURE, SIZE, TRANSFORM, WEIGHT, WIDTH: Because all
elements of a GlyphVector belong to the same Font, these probably cannot
be handled by Font.creteGlyphVector. Handle them in TextLayout?

BACKGROUND, FOREGROUND, SWAP_COLORS; INPUT_METHOD_UNDERLINE,
STRIKETHROUGH, UNDERLINE: These are tricky. Should this information be
part of the GlyphVector?

INPUT_METHOD_HIGHLIGHT: There's a method
java.awt.Toolkit.mapInputMethodHighlight for mapping the value to a
visual TextAttribute.

Well, here's an observation that is easier to discuss: The first part of

  (fnt != null && fnt instanceof Font)

is redundant.

Best,

-- Sascha

Sascha Brawer, brawer@dandelis.ch, http://www.dandelis.ch/people/brawer/