Duh! I’ve actually been working on this for so long, I forgot what I’ve done! :-(
I just looked through the git logs and I see, that I’m the one that added _curLineStart. The code used to get the index from the TextBlock, but that is no longer a reliable method of getting the index, so I added _curLineStart. Since it’s my mistake, I can fix this with impunity! Phew! :-p No back to our regular programing… ;-) On Nov 23, 2014, at 11:22 PM, Harbs <harbs.li...@gmail.com> wrote: > Here’s what I *think* is happening: > 1) ComposeState.composeNextLine() calls createTextLine() and gets a TextLine. > 2) Part of what BaseCompose.createTextLine() does is: _curLineStart += > _curLine.textLength. That increases the index of where the line is supposed > to start from. _curLineStart is the number used to initialize the > TextFlowLine and determines its absoluteStart. > 3) ComposeState.composeNextLine() then does a check for fitLineToParcel() on > line 425. > 4) If that fails, _curLine is set to null without adding it to the > flowComposer. > 5) The loop continues and a new line is created and initialized at > _curLineStart which was increased by the theoretical length of the line that > was never actually used so things get out of whack. > > I’m really nervous about fixing this, because I’m not sure why it’s failing > now, but was not failing before. > > The above logic makes no sense to me, but it’s not something that I changed. > Without understanding how it’s *supposed* to be working, I run the risk of > breaking other areas by fixing this. I’m obviously missing some nuance in the > logic here. > > Anyone interested in sticking their noses into this mess? > > On Nov 23, 2014, at 11:00 PM, Harbs <harbs.li...@gmail.com> wrote: > >> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
