I'm having discussions with the TLF team about making FlowElements such as 
<span> understand CSS styles. I agree that this would be very useful. (In 
current Gumbo builds, CSS styles are applied at the level of a TextGraphic or 
TextView to determine the default formatting; they can't be used with 
individual FlowElements within the TextFlow.)

However, this is a somewhat complicated design problem because TLF must be 
usable either with or without the Flex framework. So it can't require Flex's 
CSS subsystem, but should be able to take advantage of it if it is present.

So the bottom line is that what you ask for is our goal, but it isn't a 
definite Gumbo feature yet.

Gordon Smith
Adobe Flex SDK Team

From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Ethan 
Miller
Sent: Wednesday, November 19, 2008 9:57 AM
To: [email protected]
Subject: [flexcoders] Re: Text Layout Framework in Flex 4


Id' like to add to this request list the ability to have html tags (in 
htmlText) be sensitive to
both CSS Element and class selectors such that I could use <span 
class=foo">arbitrarily
styled text string</span>...

cheers, ethan

>
> Gordon Smith recently responded to a TextArea HTML text issue and he
> stated:
>
> "Adobe is developing a new Text Layout Framework (TLF) which works
> with the new Flash Text Engine (FTE) APIs in Player 10. (It will be
> used in Flex 4.) TLF will not support all of HTML, but it will be
> more capable than TextField's htmlText."
>
> I don't know what features are slated for TLF, but I'd like to put in
> a plug for some features that I desparately need in my work at
> customizing a TextArea/TextField component.
>
> 1) Better support for filtering keystrokes. We should have the
> ability to filter (call event.preventDefault() or equivalent) in the
> keyDownHandler() function. This allows to avoid the stupid hack of
> working around DELETE, BACKSPACE and keyboard navigation keys not
> being cancelable.
>
> 2) More control over copy/paste to clipboard. I recently posted an
> issue where if you set the htmlText property, copy to the clipboard
> loses all line breaks (unless I explicitly use <br/>). Ideally,
> there'd be an event or protected overridable function that indicates
> we're trying to do a copy/paste.
>
> 3) Ability to represent custom HTML tags or custom HTML attributes in
> a standard tag. I tried to store some metadata inside a <FONT> tag
> using a custom attribute, but I found that when I set the htmlText,
> and then examined the htmlText property after the set, the whole
> markup had been altered and "normalized", losing my custom
> attributes. It would be nice if this normalization did not occur.
>
> 4) Better support for caret to coordinates functions. There is a
> getCharBoundaries() function, but that returns a rectangle in virtual
> coordinates that does not account for the scroll positions. Adjusting
> for the horizontal scroll position is fairly easy because that is
> measured in pixels, but the vertical scroll position is measured in
> lines and calculating the correct viewport position is non-trivial
> and expensive (there are some posts on how to do this). Not to
> mention the fact that getCharBoundaries() returns null if the char is
> at EOL or in an empty line. This support is incomplete. Just adding a
> function like getCoordinatesAtCharIndex(charIndex:int):Point would
> help, or something similar to that.
>
> 5) A function get get the caret Index within the htmlText would also
> be useful, or more generally, getCharIndexInHtmlText
> (charIndex:int):int where charIndex is the character index in the raw
> text property.
>
> Thanks for your attention,
> Pete
>

Reply via email to