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

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