flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: TextFlowLine recycling
Date Mon, 17 Nov 2014 11:27:05 GMT
Just to be a little clearer:

I’m not sure why this used to work, and now it doesn’t.

It seems to me that if the parcel changes on a TextFlowLine, the outerTargetWidth could be
changed and the TextLine regenerated. (Then the Slug and the outerTargetWidth should match.)
The thing is, the code did not used to do that and I’m not sure how/why.

Another issue with this approach is what happens if we add the ability to have non-rectangular
parcels. The the TextFlowLine width should need to be refigured every time it’s composed
(which is something that I don’t think is happening currently). Of course there’s no reason
to worry about that until we might be adding that support…

I’m also not entirely sure what the check that’s failing is supposed to be checking for…

Harbs

On Nov 17, 2014, at 12:29 PM, Harbs <harbs.lists@gmail.com> wrote:

> I took a little break on this to deal with some other crises.
> 
> I found where it’s going off:
> 
> In BaseCompose.fitLineToParcel() this check was failing:
> 
> 			// check to see if we got a good line
> 			if (Twips.to(_lineSlug.width) != _curLine.outerTargetWidthTW)
> 				return false;
> The reason it’s failing is because the _lineSlug width does not match the new width
of the line. (The first column/parcel is wider than the second.)
> 
> When it fails, the composer tries to keep getting the next line and upping the line absolute
start but the _currentElementOffset does not get increased until we get an error.
> 
> So, I’m back to my original question. What’s the correct way to deal with this situation?
I’m not 100% sure how line slugs and TexFlowLines are supposed to interact.
> 
> Any suggestions?
> 
> On Nov 7, 2014, at 10:34 AM, Harbs <harbs.lists@gmail.com> wrote:
> 
>> A bit more progress: It looks like things go off where the text flows from one container
into another mid-paragraph…
>> 
>> (Sorry for polluting the mailing list with this. I’ll try to be quiet until I figure
it out…)
>> 
>> On Nov 7, 2014, at 9:55 AM, Harbs <harbs.lists@gmail.com> wrote:
>> 
>>> It’s pretty big.
>>> 
>>> It consistently gets out of whack at the end of the second paragraph. I’m getting
closer to where it’s going off…
>>> 
>>> 
>>> On Nov 7, 2014, at 1:01 AM, Alex Harui <aharui@adobe.com> wrote:
>>> 
>>>> 
>>>> 
>>>> On 11/6/14, 2:02 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>>>> 
>>>>> I think it’s _curElementOffset which gets updated.
>>>>> 
>>>>> It does look like something is getting out of sync. I’m just not sure
yet
>>>>> what. This is one of those areas that’s way too fragile IMHO… Every
time
>>>>> I’ve run into these kinds of issues it’s taken me days to figure
out
>>>>> exactly what’s off.
>>>> 
>>>> Is the paragraph huge?  In the past I simply have to watch each line get
>>>> created, figure out what is in the line, and how much the offset should
>>>> change and verify it changed.  This was when I was dealing with some
>>>> unicode character issues where an atom could be made of more than one
>>>> character.
>>>> 
>>>> -Alex
>>>> 
>>> 
>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message