I went through all the ParagraphElements and TextFlowLines. I added it up, and it’s clear to me that the _curElementOffset and _cur is being upped by 41 which is the length of the current line before the line is initialized. That seems to be throwing everything out of whack.
Now I just need to figure out where that’s happening… On Nov 23, 2014, at 9:55 PM, Harbs <harbs.li...@gmail.com> wrote: > I’m back on this. I have a simpler case where things are getting out of sync. > > I have a line where the _curElementOffset is 382, the _curElementStart is 803 > (total 1201). > > The total textLength of the textFlow is 1201. > > The _curLineStart is 1185 and the rawTextLength of the TextLine returned by > the TextBlock is 41. This adds up to more than the total length. > Interestingly, the length of the previous line is 41 as well. > > Adding up all the lengths of the TextLines in the TextBlock only comes to > 389, but the paragraph (and span) has a length of 398. > > It looks like the whole paragraph and TextBlock is somehow out of whack > > Sorry for the noise, but I’m writing this in the hope that the lightbulb will > come on for either me or someone reading this… > > Harbs > > On Nov 18, 2014, at 12:23 AM, Harbs <harbs.li...@gmail.com> wrote: > >> Right. My question is more related to TextFlowLines than Slugs though. >> >> Let’s say a flowComposer has an array of TextFlowLines and the geometry of >> them does not fit in the new composition space. What is supposed to happen >> to the old TextFlowLines? I’m having trouble understanding the architecture >> here. >> >> What I would have done if I was designing the engine would be to recalculate >> geometry of the TextFlowLine each time I’m composing it. If the geometry >> changed, I’d throw out the old TextLine and ask the textBlock for a new one. >> Getting new TextLines, I see, but recalculating the geometry I don’t. >> >> I assume I’m missing something obvious. If someone can help me spot it, that >> would be great! >> >> (BTW I just fixed a vertical placement issue with table blocks. I’m >> committing it now.) >> >> On Nov 18, 2014, at 12:17 AM, Alex Harui <aha...@adobe.com> wrote: >> >>> I don’t know for sure, I just looked up the Slug class. It says it is >>> created by Parcels to track geometrical line information. >>> >>> Maybe a simpler test case would help you understand the desired behavior? >>> I would think at some point if the composable areas change, the Parcels >>> and their Slugs get updated. It would probably be either at the beginning >>> when the composition is given new bounds, or more likely, gradually as the >>> composer works its way down through the container and on to the next >>> container. If a Parcel and its Slugs (I’m going to start a band with that >>> name!) gets moved to a different container, you would think there would be >>> some invalidation of that Parcel if any information is cached, or maybe no >>> old information is supposed to matter and everything gets recomputed >>> during composition. >>> >>> If the table work has changed the recalculation of the Slugs because >>> you’ve deferred it in order to compute table cells, that might be the >>> cause. >>> >>> I’m not sure how well the code works for non-rectangular parcels. >>> >>> Good luck, >>> -Alex >>> >>> On 11/17/14, 3:27 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>> >>>> 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.li...@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.li...@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.li...@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 <aha...@adobe.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/6/14, 2:02 PM, "Harbs" <harbs.li...@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 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
