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 10:29:33 GMT
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