graydon hoare <[EMAIL PROTECTED]> wrote on Wed, 19 Nov 2003 15:38:19 -0500:
>Sascha Brawer <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
