On another look: TabElement and BreakElement both subclass SpanElement, so they
get SpanElement behavior for free.
So, it looks like the only two cases which are not covered by SpanElement are
InlineGraphicElement and TableLeafElement. Both of these are now handled by
custom code. So, unless anyone has a reason what that’s wrong. I think I can
call this fixed.
Harbs
On Dec 13, 2015, at 8:26 PM, Harbs <harbs.li...@gmail.com> wrote:
> Looking at this more, it seems like it’s a more general problem.
> FlowLeafElement has the following code:
>
> /**
> * The text associated with the FlowLeafElement:
> * <p><ul>
> * <li>The value for SpanElement subclass will be one character
> less than <code>textLength</code> if this is the last span in a
> ParagraphELement.</li>
> * <li>The value for BreakElement subclass is a U+2028</li>
> * <li>The value for TabElement subclass is a tab</li>
> * <li>The value for InlineGraphicElement subclass is
> U+FDEF</li>
> * </ul></p>
> *
> * @playerversion Flash 10
> * @playerversion AIR 1.5
> * @langversion 3.0
> *
> * @see flashx.textLayout.elements.SpanElement#replaceText()
> */
> public function get text():String
> {
> return _text;
> }
>
> So, the text getter seems to return the correct content for each element
> type. InlineGraphicElement does in fact define the _text property, but
> FlowLeafElement does not implement getText().
>
> It seems to me that FlowLeafElement should implement getText() which should
> return text. The only exception is SnapElement which overrides getText()
> already.
>
> On Dec 13, 2015, at 6:36 PM, Harbs <harbs.li...@gmail.com> wrote:
>
>> Good question.
>>
>> I just did a search in the code and besides the Element classes, getText()
>> comes up 3 times in TLF code:
>>
>> 1. TextAccImpl.searchText()
>> 2. TextContainerManager.getText()
>> 3. IMEClient.getTextInRange()
>>
>> None of those seems to have a “right” or “wrong” behavior.
>>
>> It’s also used in Squiggly, and I don’t think there’s a right or wrong there.
>>
>> It’s not been consistent for third party code to date, so I don’t think
>> there’s an issue there.
>>
>> On Dec 13, 2015, at 6:23 PM, Alex Harui <aha...@adobe.com> wrote:
>>
>>> Is this used to put text on the clipboard?
>>>
>>> Sent from my LG G3, an AT&T 4G LTE smartphone
>>>
>>> ------ Original message------
>>> From: Harbs
>>> Date: Sun, Dec 13, 2015 5:29 AM
>>> To: dev@flex.apache.org;
>>> Subject:[TLF] getText() for InlineGraphicElement
>>>
>>> I have a question in reference to
>>> https://issues.apache.org/jira/browse/FLEX-34988
>>>
>>> It seems like getText() was never implemented for InlineGraphicElements. By
>>> default it returns an empty string.
>>>
>>> In FTE, ContentElement has two properties: text and rawText. text returns
>>> the text minus any non-text items. rawText returns non-text (such as inline
>>> graphics) as \uFDEF.
>>>
>>> ParagraphElement.getText() uses rawText if the TextBlock for the paragraph
>>> exists and recursively calls getText() on all the sub elements if it does
>>> not. This causes the bug mentioned in the JIRA.
>>>
>>> There’s two ways to fix this:
>>>
>>> 1. We can return \uFDEF in getText() of InlineGraphicElement.
>>> 2. We can use text rather than rawText in ParagraphElement.
>>>
>>> I’m not sure which way is “correct”. I think the first way is more “right”.
>>>
>>> Thoughts?
>>
>
