You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2014/11/06 11:26:04 UTC
TextFlowLine recycling
I ran into an issue where I have a runtime error in TextFlowLine.getTextLine(). I’m having trouble stepping through things, but as best as I can figure, the issue is caused by the umber of lines in a paragraph becoming reduced.
The RTE happens inside TextFlowline.recreateTextLine() after requesting the line from the TextBlock. The function (I’m not sure if it’s createTextLine or recreateTextLine) returns null. The TextBlock.lastLine is the line before the current one.
The caller of this mess is ComposeState.composeNextLine.
If anyone is still following me, my problem is I’m not sure the best way to fix this. I’m not sure why this is breaking now. I’m not sure what I changed that’s causing this error. Should I fix TextFlowLine.getTextLine() to return null if there’s no more lines in the paragraph? Will there be any other repercussions from doing that? Should I fix ComposeState/BaseCompose so it does not try to compose the next line once the paragraph is out of lines?
Is anyone familiar enough with the composer to even give me suggestions? :-(
Harbs
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
I think my explanation might be more helpful, but here:
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at flashx.textLayout.compose::TextFlowLine/http://ns.adobe.com/textLayout/internal/2008::recreateTextLine()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/TextFlowLine.as:937]
at flashx.textLayout.compose::TextFlowLine/getTextLineInternal()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/TextFlowLine.as:891]
at flashx.textLayout.compose::TextFlowLine/getTextLine()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/TextFlowLine.as:855]
at flashx.textLayout.compose::ComposeState/composeNextLine()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/ComposeState.as:421]
at flashx.textLayout.compose::BaseCompose/composeParagraphElementIntoLines()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/BaseCompose.as:1154]
at flashx.textLayout.compose::BaseCompose/composeParagraphElement()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/BaseCompose.as:1010]
at flashx.textLayout.compose::ComposeState/composeParagraphElement()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/ComposeState.as:331]
at flashx.textLayout.compose::BaseCompose/composeBlockElement()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/BaseCompose.as:439]
at flashx.textLayout.compose::BaseCompose/composeInternal()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/BaseCompose.as:989]
at flashx.textLayout.compose::ComposeState/composeInternal()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/ComposeState.as:150]
at flashx.textLayout.compose::BaseCompose/composeTextFlow()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/BaseCompose.as:767]
at flashx.textLayout.compose::ComposeState/composeTextFlow()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/ComposeState.as:113]
at flashx.textLayout.compose::StandardFlowComposer/http://ns.adobe.com/textLayout/internal/2008::callTheComposer()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/StandardFlowComposer.as:681]
at flashx.textLayout.compose::StandardFlowComposer/internalCompose()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/StandardFlowComposer.as:765]
at flashx.textLayout.compose::StandardFlowComposer/updateToController()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/StandardFlowComposer.as:561]
at flashx.textLayout.compose::StandardFlowComposer/updateAllControllers()[/Users/harbs/Documents/ApacheFlex/flex-tlf/textLayout/src/flashx/textLayout/compose/StandardFlowComposer.as:522]
On Nov 6, 2014, at 8:06 PM, Joel Marks <jo...@workiva.com> wrote:
> What was the stack trace?
>
> On Thu, Nov 6, 2014 at 11:29 AM, Harbs <ha...@gmail.com> wrote:
>
>>
>> On Nov 6, 2014, at 7:15 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>> My memory is a bit fuzzy. I thought TextLine recycling wasn’t
>>> per-paragraph, or is there a TextBlock per paragraph?
>>
>> There’s generally one TextBlock per paragraph. My table work was actually
>> quite difficult because there was an assumption in many places that there
>> is ONLY one TextBlock per paragraph. Tables kind of blows that assumption
>> out of the water…
>>
>>
>>> The doc says that TextBlock.createTextLine/recreateTextLine returns null
>>> if the TextBlock is empty or if the width specified is less than the
>> width
>>> of the next element, and to check the TextBlock.textLineCreationResult
>>> property if you get a null.
>>
>> It looks to me that it’s null if you ask for a line beyond the last one as
>> well.
>>
>>> Could it just be that the number of lines in the paragraph when to zero?
>>
>> No. The TextBlock has more than one line. The last line in the TextBlock
>> is the line of the previous TextFlowLine.
>>
>>>
>>> -Alex
>>>
>>> On 11/6/14, 2:26 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> I ran into an issue where I have a runtime error in
>>>> TextFlowLine.getTextLine(). I’m having trouble stepping through things,
>>>> but as best as I can figure, the issue is caused by the umber of lines
>> in
>>>> a paragraph becoming reduced.
>>>>
>>>> The RTE happens inside TextFlowline.recreateTextLine() after requesting
>>>> the line from the TextBlock. The function (I’m not sure if it’s
>>>> createTextLine or recreateTextLine) returns null. The TextBlock.lastLine
>>>> is the line before the current one.
>>>>
>>>> The caller of this mess is ComposeState.composeNextLine.
>>>>
>>>> If anyone is still following me, my problem is I’m not sure the best way
>>>> to fix this. I’m not sure why this is breaking now. I’m not sure what I
>>>> changed that’s causing this error. Should I fix
>>>> TextFlowLine.getTextLine() to return null if there’s no more lines in
>> the
>>>> paragraph? Will there be any other repercussions from doing that? Should
>>>> I fix ComposeState/BaseCompose so it does not try to compose the next
>>>> line once the paragraph is out of lines?
>>>>
>>>> Is anyone familiar enough with the composer to even give me suggestions?
>>>> :-(
>>>>
>>>> Harbs
>>>
>>
>>
Re: TextFlowLine recycling
Posted by Joel Marks <jo...@workiva.com>.
What was the stack trace?
On Thu, Nov 6, 2014 at 11:29 AM, Harbs <ha...@gmail.com> wrote:
>
> On Nov 6, 2014, at 7:15 PM, Alex Harui <ah...@adobe.com> wrote:
>
> > My memory is a bit fuzzy. I thought TextLine recycling wasn’t
> > per-paragraph, or is there a TextBlock per paragraph?
>
> There’s generally one TextBlock per paragraph. My table work was actually
> quite difficult because there was an assumption in many places that there
> is ONLY one TextBlock per paragraph. Tables kind of blows that assumption
> out of the water…
>
>
> > The doc says that TextBlock.createTextLine/recreateTextLine returns null
> > if the TextBlock is empty or if the width specified is less than the
> width
> > of the next element, and to check the TextBlock.textLineCreationResult
> > property if you get a null.
>
> It looks to me that it’s null if you ask for a line beyond the last one as
> well.
>
> > Could it just be that the number of lines in the paragraph when to zero?
>
> No. The TextBlock has more than one line. The last line in the TextBlock
> is the line of the previous TextFlowLine.
>
> >
> > -Alex
> >
> > On 11/6/14, 2:26 AM, "Harbs" <ha...@gmail.com> wrote:
> >
> >> I ran into an issue where I have a runtime error in
> >> TextFlowLine.getTextLine(). I’m having trouble stepping through things,
> >> but as best as I can figure, the issue is caused by the umber of lines
> in
> >> a paragraph becoming reduced.
> >>
> >> The RTE happens inside TextFlowline.recreateTextLine() after requesting
> >> the line from the TextBlock. The function (I’m not sure if it’s
> >> createTextLine or recreateTextLine) returns null. The TextBlock.lastLine
> >> is the line before the current one.
> >>
> >> The caller of this mess is ComposeState.composeNextLine.
> >>
> >> If anyone is still following me, my problem is I’m not sure the best way
> >> to fix this. I’m not sure why this is breaking now. I’m not sure what I
> >> changed that’s causing this error. Should I fix
> >> TextFlowLine.getTextLine() to return null if there’s no more lines in
> the
> >> paragraph? Will there be any other repercussions from doing that? Should
> >> I fix ComposeState/BaseCompose so it does not try to compose the next
> >> line once the paragraph is out of lines?
> >>
> >> Is anyone familiar enough with the composer to even give me suggestions?
> >> :-(
> >>
> >> Harbs
> >
>
>
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
On Nov 6, 2014, at 7:15 PM, Alex Harui <ah...@adobe.com> wrote:
> My memory is a bit fuzzy. I thought TextLine recycling wasn’t
> per-paragraph, or is there a TextBlock per paragraph?
There’s generally one TextBlock per paragraph. My table work was actually quite difficult because there was an assumption in many places that there is ONLY one TextBlock per paragraph. Tables kind of blows that assumption out of the water…
> The doc says that TextBlock.createTextLine/recreateTextLine returns null
> if the TextBlock is empty or if the width specified is less than the width
> of the next element, and to check the TextBlock.textLineCreationResult
> property if you get a null.
It looks to me that it’s null if you ask for a line beyond the last one as well.
> Could it just be that the number of lines in the paragraph when to zero?
No. The TextBlock has more than one line. The last line in the TextBlock is the line of the previous TextFlowLine.
>
> -Alex
>
> On 11/6/14, 2:26 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> I ran into an issue where I have a runtime error in
>> TextFlowLine.getTextLine(). I’m having trouble stepping through things,
>> but as best as I can figure, the issue is caused by the umber of lines in
>> a paragraph becoming reduced.
>>
>> The RTE happens inside TextFlowline.recreateTextLine() after requesting
>> the line from the TextBlock. The function (I’m not sure if it’s
>> createTextLine or recreateTextLine) returns null. The TextBlock.lastLine
>> is the line before the current one.
>>
>> The caller of this mess is ComposeState.composeNextLine.
>>
>> If anyone is still following me, my problem is I’m not sure the best way
>> to fix this. I’m not sure why this is breaking now. I’m not sure what I
>> changed that’s causing this error. Should I fix
>> TextFlowLine.getTextLine() to return null if there’s no more lines in the
>> paragraph? Will there be any other repercussions from doing that? Should
>> I fix ComposeState/BaseCompose so it does not try to compose the next
>> line once the paragraph is out of lines?
>>
>> Is anyone familiar enough with the composer to even give me suggestions?
>> :-(
>>
>> Harbs
>
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
Phew!
Looks like I fixed this issue. Once I found the problem, the fix was straight-forward... There’s still some failures with FloatTests, but nothing as bad as what we were getting before.
I’m going to comment on the other FlexUnit discussion about the remaining errors.
On Nov 23, 2014, at 11:38 PM, Harbs <ha...@gmail.com> wrote:
> 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 <ha...@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 <ha...@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 <ha...@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 <ha...@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 <ah...@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" <ha...@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 <ha...@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 <ha...@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 <ha...@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 <ah...@adobe.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 11/6/14, 2:02 PM, "Harbs" <ha...@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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ha...@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 <ha...@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 <ha...@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 <ah...@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" <ha...@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 <ha...@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 <ha...@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 <ha...@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 <ah...@adobe.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/6/14, 2:02 PM, "Harbs" <ha...@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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ha...@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 <ha...@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 <ah...@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" <ha...@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 <ha...@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 <ha...@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 <ha...@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 <ah...@adobe.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/6/14, 2:02 PM, "Harbs" <ha...@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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ha...@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 <ah...@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" <ha...@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 <ha...@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 <ha...@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 <ha...@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 <ah...@adobe.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/6/14, 2:02 PM, "Harbs" <ha...@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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ah...@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" <ha...@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 <ha...@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 <ha...@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 <ha...@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 <ah...@adobe.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 11/6/14, 2:02 PM, "Harbs" <ha...@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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@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 <ha...@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 <ha...@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 <ha...@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 <ah...@adobe.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/6/14, 2:02 PM, "Harbs" <ha...@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
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: TextFlowLine recycling
Posted by Alex Harui <ah...@adobe.com>.
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" <ha...@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 <ha...@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 <ha...@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 <ha...@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 <ah...@adobe.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 11/6/14, 2:02 PM, "Harbs" <ha...@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
>>>>>
>>>>
>>>
>>
>
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ha...@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 <ha...@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 <ah...@adobe.com> wrote:
>>>
>>>>
>>>>
>>>> On 11/6/14, 2:02 PM, "Harbs" <ha...@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
>>>>
>>>
>>
>
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ha...@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 <ah...@adobe.com> wrote:
>>
>>>
>>>
>>> On 11/6/14, 2:02 PM, "Harbs" <ha...@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
>>>
>>
>
Re: TextFlowLine recycling
Posted by Joel Marks <jo...@workiva.com>.
We have had
if (_curElementStart == _curParaStart+_curParaElement.textLength)
break;
get off before because we accidentally edited the model during composition.
TLF really hates when you do that.
On Fri, Nov 7, 2014 at 2:50 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> No, please go ahead, I think showing progress and thoughts/ideas will be
> helpful to others, and it might even trigger someone with a solution.
>
> EdB
>
>
>
> On Fri, Nov 7, 2014 at 9:34 AM, Harbs <ha...@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 <ha...@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 <ah...@adobe.com> wrote:
> > >
> > >>
> > >>
> > >> On 11/6/14, 2:02 PM, "Harbs" <ha...@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
> > >>
> > >
> >
> >
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: TextFlowLine recycling
Posted by Erik de Bruin <er...@ixsoftware.nl>.
No, please go ahead, I think showing progress and thoughts/ideas will be
helpful to others, and it might even trigger someone with a solution.
EdB
On Fri, Nov 7, 2014 at 9:34 AM, Harbs <ha...@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 <ha...@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 <ah...@adobe.com> wrote:
> >
> >>
> >>
> >> On 11/6/14, 2:02 PM, "Harbs" <ha...@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
> >>
> >
>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ah...@adobe.com> wrote:
>
>>
>>
>> On 11/6/14, 2:02 PM, "Harbs" <ha...@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
>>
>
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com> wrote:
>
>
> On 11/6/14, 2:02 PM, "Harbs" <ha...@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
>
Re: TextFlowLine recycling
Posted by Alex Harui <ah...@adobe.com>.
On 11/6/14, 2:02 PM, "Harbs" <ha...@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
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
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.
On Nov 6, 2014, at 11:57 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 11/6/14, 1:50 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> Well, it does this:
>>
>> if (_curElementStart == _curParaStart+_curParaElement.textLength)
>> break;
>>
>> to normally break out of the loop.
>>
>> I’m a bit fuzzy though on how it handles SpanElements that span multiple
>> lines and how to break out of that.
>
> Doesn’t _curElementStart get updated after each textLine is composed?
> _curElementStart might be getting out of sync.
>
> -Alex
>
Re: TextFlowLine recycling
Posted by Alex Harui <ah...@adobe.com>.
On 11/6/14, 1:50 PM, "Harbs" <ha...@gmail.com> wrote:
>Well, it does this:
>
>if (_curElementStart == _curParaStart+_curParaElement.textLength)
> break;
>
>to normally break out of the loop.
>
>I’m a bit fuzzy though on how it handles SpanElements that span multiple
>lines and how to break out of that.
Doesn’t _curElementStart get updated after each textLine is composed?
_curElementStart might be getting out of sync.
-Alex
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
Well, it does this:
if (_curElementStart == _curParaStart+_curParaElement.textLength)
break;
to normally break out of the loop.
I’m a bit fuzzy though on how it handles SpanElements that span multiple lines and how to break out of that.
(I should really try to comment the code a bit so next time around the logic would be more self-explanatory…)
On Nov 6, 2014, at 11:28 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 11/6/14, 1:03 PM, "Harbs" <ha...@gmail.com> wrote:
>
>>
>> For some reason, the flowComposer has TextFlowLines beyond the end of the
>> paragraph which it’s trying to compose.
>> BaseCompose.composeParagraphElementIntoLines() should really break out of
>> the loop before this happens (if I’m understanding things correctly), but
>> it’s not.
>>
>
> I think that’s the key: how does the flow composer normally know to stop
> getting more TextLines?
>
> -Alex
>
Re: TextFlowLine recycling
Posted by Alex Harui <ah...@adobe.com>.
On 11/6/14, 1:03 PM, "Harbs" <ha...@gmail.com> wrote:
>
>For some reason, the flowComposer has TextFlowLines beyond the end of the
>paragraph which it’s trying to compose.
>BaseCompose.composeParagraphElementIntoLines() should really break out of
>the loop before this happens (if I’m understanding things correctly), but
>it’s not.
>
I think that’s the key: how does the flow composer normally know to stop
getting more TextLines?
-Alex
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
The error happens here:
// trace("Recreating line from", absoluteStart, "to", absoluteStart + textLength);
textLine = TextLineRecycler.getLineForReuse();
if (textLine)
{
CONFIG::debug { assert(textFlow.backgroundManager == null || textFlow.backgroundManager..getEntry(textLine) === undefined,"Bad TextLine in recycler cache"); }
textLine = swfContext.callInContext(textBlock["recreateTextLine"], textBlock, [ textLine, previousLine, _targetWidth, effLineOffset, true ]);
}
else
textLine = swfContext.callInContext(textBlock.createTextLine, textBlock, [ previousLine, _targetWidth, effLineOffset, true ]);
textLine.x = this.x;
The previousLine and textBlock are both valid. In fact, the previousLine is the lastLine of the textBlock.
For some reason, the flowComposer has TextFlowLines beyond the end of the paragraph which it’s trying to compose. BaseCompose.composeParagraphElementIntoLines() should really break out of the loop before this happens (if I’m understanding things correctly), but it’s not.
On Nov 6, 2014, at 10:21 PM, Joel Marks <jo...@workiva.com> wrote:
> I think the root of the problem is that BaseCompose.createTextLine() is
> returning null. The only reason why that would happen is if the line
> couldn't fit in the space provided. I am not sure why
> ComposeState.composeNextLine() is trying to do _curLine.getTextLine(true)
> when the textLine is null. I would think you would hit the same result or
> something worse like an RTE.
>
> What parameters are you passing into FTE when trying to create the line?
>
> On Thu, Nov 6, 2014 at 2:09 PM, Harbs <ha...@gmail.com> wrote:
>
>> Yes. It’s very reproducible.
>>
>> Not small at all… :-(
>>
>> It would be considerable work to try to put together a test case for this.
>>
>> On Nov 6, 2014, at 9:41 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>> Do you have a 100% reproducible test case? How small is it?
>>>
>>> On 11/6/14, 11:31 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> If someone has the time to walk through this with me off-list, that
>> would
>>>> be very helpful. I’d really like an extra set of eyeballs to make sure
>>>> I’m not missing something with this and I don’t blow things up. I don’t
>>>> have a good enough grasp on exactly how the management of TextFlowLines
>>>> is supposed to be working.
>>>>
>>>> On Nov 6, 2014, at 7:15 PM, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>>>> My memory is a bit fuzzy. I thought TextLine recycling wasn’t
>>>>> per-paragraph, or is there a TextBlock per paragraph?
>>>>>
>>>>> The doc says that TextBlock.createTextLine/recreateTextLine returns
>> null
>>>>> if the TextBlock is empty or if the width specified is less than the
>>>>> width
>>>>> of the next element, and to check the TextBlock.textLineCreationResult
>>>>> property if you get a null.
>>>>>
>>>>> Could it just be that the number of lines in the paragraph when to
>> zero?
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 11/6/14, 2:26 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>> I ran into an issue where I have a runtime error in
>>>>>> TextFlowLine.getTextLine(). I’m having trouble stepping through
>> things,
>>>>>> but as best as I can figure, the issue is caused by the umber of lines
>>>>>> in
>>>>>> a paragraph becoming reduced.
>>>>>>
>>>>>> The RTE happens inside TextFlowline.recreateTextLine() after
>> requesting
>>>>>> the line from the TextBlock. The function (I’m not sure if it’s
>>>>>> createTextLine or recreateTextLine) returns null. The
>>>>>> TextBlock.lastLine
>>>>>> is the line before the current one.
>>>>>>
>>>>>> The caller of this mess is ComposeState.composeNextLine.
>>>>>>
>>>>>> If anyone is still following me, my problem is I’m not sure the best
>>>>>> way
>>>>>> to fix this. I’m not sure why this is breaking now. I’m not sure what
>> I
>>>>>> changed that’s causing this error. Should I fix
>>>>>> TextFlowLine.getTextLine() to return null if there’s no more lines in
>>>>>> the
>>>>>> paragraph? Will there be any other repercussions from doing that?
>>>>>> Should
>>>>>> I fix ComposeState/BaseCompose so it does not try to compose the next
>>>>>> line once the paragraph is out of lines?
>>>>>>
>>>>>> Is anyone familiar enough with the composer to even give me
>>>>>> suggestions?
>>>>>> :-(
>>>>>>
>>>>>> Harbs
>>>>>
>>>>
>>>
>>
>>
Re: TextFlowLine recycling
Posted by Joel Marks <jo...@workiva.com>.
I think the root of the problem is that BaseCompose.createTextLine() is
returning null. The only reason why that would happen is if the line
couldn't fit in the space provided. I am not sure why
ComposeState.composeNextLine() is trying to do _curLine.getTextLine(true)
when the textLine is null. I would think you would hit the same result or
something worse like an RTE.
What parameters are you passing into FTE when trying to create the line?
On Thu, Nov 6, 2014 at 2:09 PM, Harbs <ha...@gmail.com> wrote:
> Yes. It’s very reproducible.
>
> Not small at all… :-(
>
> It would be considerable work to try to put together a test case for this.
>
> On Nov 6, 2014, at 9:41 PM, Alex Harui <ah...@adobe.com> wrote:
>
> > Do you have a 100% reproducible test case? How small is it?
> >
> > On 11/6/14, 11:31 AM, "Harbs" <ha...@gmail.com> wrote:
> >
> >> If someone has the time to walk through this with me off-list, that
> would
> >> be very helpful. I’d really like an extra set of eyeballs to make sure
> >> I’m not missing something with this and I don’t blow things up. I don’t
> >> have a good enough grasp on exactly how the management of TextFlowLines
> >> is supposed to be working.
> >>
> >> On Nov 6, 2014, at 7:15 PM, Alex Harui <ah...@adobe.com> wrote:
> >>
> >>> My memory is a bit fuzzy. I thought TextLine recycling wasn’t
> >>> per-paragraph, or is there a TextBlock per paragraph?
> >>>
> >>> The doc says that TextBlock.createTextLine/recreateTextLine returns
> null
> >>> if the TextBlock is empty or if the width specified is less than the
> >>> width
> >>> of the next element, and to check the TextBlock.textLineCreationResult
> >>> property if you get a null.
> >>>
> >>> Could it just be that the number of lines in the paragraph when to
> zero?
> >>>
> >>> -Alex
> >>>
> >>> On 11/6/14, 2:26 AM, "Harbs" <ha...@gmail.com> wrote:
> >>>
> >>>> I ran into an issue where I have a runtime error in
> >>>> TextFlowLine.getTextLine(). I’m having trouble stepping through
> things,
> >>>> but as best as I can figure, the issue is caused by the umber of lines
> >>>> in
> >>>> a paragraph becoming reduced.
> >>>>
> >>>> The RTE happens inside TextFlowline.recreateTextLine() after
> requesting
> >>>> the line from the TextBlock. The function (I’m not sure if it’s
> >>>> createTextLine or recreateTextLine) returns null. The
> >>>> TextBlock.lastLine
> >>>> is the line before the current one.
> >>>>
> >>>> The caller of this mess is ComposeState.composeNextLine.
> >>>>
> >>>> If anyone is still following me, my problem is I’m not sure the best
> >>>> way
> >>>> to fix this. I’m not sure why this is breaking now. I’m not sure what
> I
> >>>> changed that’s causing this error. Should I fix
> >>>> TextFlowLine.getTextLine() to return null if there’s no more lines in
> >>>> the
> >>>> paragraph? Will there be any other repercussions from doing that?
> >>>> Should
> >>>> I fix ComposeState/BaseCompose so it does not try to compose the next
> >>>> line once the paragraph is out of lines?
> >>>>
> >>>> Is anyone familiar enough with the composer to even give me
> >>>> suggestions?
> >>>> :-(
> >>>>
> >>>> Harbs
> >>>
> >>
> >
>
>
Re: TextFlowLine recycling
Posted by Alex Harui <ah...@adobe.com>.
On 11/6/14, 12:27 PM, "Harbs" <ha...@gmail.com> wrote:
>It’s all checked in to the tables branch.
>
>I can give you a swf to step through.
I’m willing to spend a little time looking into it. Probably not until
this evening (8 hours or so from now).
-Alex
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
It’s all checked in to the tables branch.
I can give you a swf to step through.
On Nov 6, 2014, at 10:18 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 11/6/14, 12:09 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> Yes. It’s very reproducible.
>>
>> Not small at all… :-(
>>
>> It would be considerable work to try to put together a test case for this.
>
> Can the current SWF you are debugging be made public so I can run it in a
> debugger, or do I need accounts, password, etc? Is all of the code
> involved checked in? If so, which branch?
>
> -Alex
>
Re: TextFlowLine recycling
Posted by Alex Harui <ah...@adobe.com>.
On 11/6/14, 12:09 PM, "Harbs" <ha...@gmail.com> wrote:
>Yes. It’s very reproducible.
>
>Not small at all… :-(
>
>It would be considerable work to try to put together a test case for this.
Can the current SWF you are debugging be made public so I can run it in a
debugger, or do I need accounts, password, etc? Is all of the code
involved checked in? If so, which branch?
-Alex
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
Yes. It’s very reproducible.
Not small at all… :-(
It would be considerable work to try to put together a test case for this.
On Nov 6, 2014, at 9:41 PM, Alex Harui <ah...@adobe.com> wrote:
> Do you have a 100% reproducible test case? How small is it?
>
> On 11/6/14, 11:31 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> If someone has the time to walk through this with me off-list, that would
>> be very helpful. I’d really like an extra set of eyeballs to make sure
>> I’m not missing something with this and I don’t blow things up. I don’t
>> have a good enough grasp on exactly how the management of TextFlowLines
>> is supposed to be working.
>>
>> On Nov 6, 2014, at 7:15 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>> My memory is a bit fuzzy. I thought TextLine recycling wasn’t
>>> per-paragraph, or is there a TextBlock per paragraph?
>>>
>>> The doc says that TextBlock.createTextLine/recreateTextLine returns null
>>> if the TextBlock is empty or if the width specified is less than the
>>> width
>>> of the next element, and to check the TextBlock.textLineCreationResult
>>> property if you get a null.
>>>
>>> Could it just be that the number of lines in the paragraph when to zero?
>>>
>>> -Alex
>>>
>>> On 11/6/14, 2:26 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> I ran into an issue where I have a runtime error in
>>>> TextFlowLine.getTextLine(). I’m having trouble stepping through things,
>>>> but as best as I can figure, the issue is caused by the umber of lines
>>>> in
>>>> a paragraph becoming reduced.
>>>>
>>>> The RTE happens inside TextFlowline.recreateTextLine() after requesting
>>>> the line from the TextBlock. The function (I’m not sure if it’s
>>>> createTextLine or recreateTextLine) returns null. The
>>>> TextBlock.lastLine
>>>> is the line before the current one.
>>>>
>>>> The caller of this mess is ComposeState.composeNextLine.
>>>>
>>>> If anyone is still following me, my problem is I’m not sure the best
>>>> way
>>>> to fix this. I’m not sure why this is breaking now. I’m not sure what I
>>>> changed that’s causing this error. Should I fix
>>>> TextFlowLine.getTextLine() to return null if there’s no more lines in
>>>> the
>>>> paragraph? Will there be any other repercussions from doing that?
>>>> Should
>>>> I fix ComposeState/BaseCompose so it does not try to compose the next
>>>> line once the paragraph is out of lines?
>>>>
>>>> Is anyone familiar enough with the composer to even give me
>>>> suggestions?
>>>> :-(
>>>>
>>>> Harbs
>>>
>>
>
Re: TextFlowLine recycling
Posted by Alex Harui <ah...@adobe.com>.
Do you have a 100% reproducible test case? How small is it?
On 11/6/14, 11:31 AM, "Harbs" <ha...@gmail.com> wrote:
>If someone has the time to walk through this with me off-list, that would
>be very helpful. I’d really like an extra set of eyeballs to make sure
>I’m not missing something with this and I don’t blow things up. I don’t
>have a good enough grasp on exactly how the management of TextFlowLines
>is supposed to be working.
>
>On Nov 6, 2014, at 7:15 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> My memory is a bit fuzzy. I thought TextLine recycling wasn’t
>> per-paragraph, or is there a TextBlock per paragraph?
>>
>> The doc says that TextBlock.createTextLine/recreateTextLine returns null
>> if the TextBlock is empty or if the width specified is less than the
>>width
>> of the next element, and to check the TextBlock.textLineCreationResult
>> property if you get a null.
>>
>> Could it just be that the number of lines in the paragraph when to zero?
>>
>> -Alex
>>
>> On 11/6/14, 2:26 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> I ran into an issue where I have a runtime error in
>>> TextFlowLine.getTextLine(). I’m having trouble stepping through things,
>>> but as best as I can figure, the issue is caused by the umber of lines
>>>in
>>> a paragraph becoming reduced.
>>>
>>> The RTE happens inside TextFlowline.recreateTextLine() after requesting
>>> the line from the TextBlock. The function (I’m not sure if it’s
>>> createTextLine or recreateTextLine) returns null. The
>>>TextBlock.lastLine
>>> is the line before the current one.
>>>
>>> The caller of this mess is ComposeState.composeNextLine.
>>>
>>> If anyone is still following me, my problem is I’m not sure the best
>>>way
>>> to fix this. I’m not sure why this is breaking now. I’m not sure what I
>>> changed that’s causing this error. Should I fix
>>> TextFlowLine.getTextLine() to return null if there’s no more lines in
>>>the
>>> paragraph? Will there be any other repercussions from doing that?
>>>Should
>>> I fix ComposeState/BaseCompose so it does not try to compose the next
>>> line once the paragraph is out of lines?
>>>
>>> Is anyone familiar enough with the composer to even give me
>>>suggestions?
>>> :-(
>>>
>>> Harbs
>>
>
Re: TextFlowLine recycling
Posted by Harbs <ha...@gmail.com>.
If someone has the time to walk through this with me off-list, that would be very helpful. I’d really like an extra set of eyeballs to make sure I’m not missing something with this and I don’t blow things up. I don’t have a good enough grasp on exactly how the management of TextFlowLines is supposed to be working.
On Nov 6, 2014, at 7:15 PM, Alex Harui <ah...@adobe.com> wrote:
> My memory is a bit fuzzy. I thought TextLine recycling wasn’t
> per-paragraph, or is there a TextBlock per paragraph?
>
> The doc says that TextBlock.createTextLine/recreateTextLine returns null
> if the TextBlock is empty or if the width specified is less than the width
> of the next element, and to check the TextBlock.textLineCreationResult
> property if you get a null.
>
> Could it just be that the number of lines in the paragraph when to zero?
>
> -Alex
>
> On 11/6/14, 2:26 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> I ran into an issue where I have a runtime error in
>> TextFlowLine.getTextLine(). I’m having trouble stepping through things,
>> but as best as I can figure, the issue is caused by the umber of lines in
>> a paragraph becoming reduced.
>>
>> The RTE happens inside TextFlowline.recreateTextLine() after requesting
>> the line from the TextBlock. The function (I’m not sure if it’s
>> createTextLine or recreateTextLine) returns null. The TextBlock.lastLine
>> is the line before the current one.
>>
>> The caller of this mess is ComposeState.composeNextLine.
>>
>> If anyone is still following me, my problem is I’m not sure the best way
>> to fix this. I’m not sure why this is breaking now. I’m not sure what I
>> changed that’s causing this error. Should I fix
>> TextFlowLine.getTextLine() to return null if there’s no more lines in the
>> paragraph? Will there be any other repercussions from doing that? Should
>> I fix ComposeState/BaseCompose so it does not try to compose the next
>> line once the paragraph is out of lines?
>>
>> Is anyone familiar enough with the composer to even give me suggestions?
>> :-(
>>
>> Harbs
>
Re: TextFlowLine recycling
Posted by Alex Harui <ah...@adobe.com>.
My memory is a bit fuzzy. I thought TextLine recycling wasn’t
per-paragraph, or is there a TextBlock per paragraph?
The doc says that TextBlock.createTextLine/recreateTextLine returns null
if the TextBlock is empty or if the width specified is less than the width
of the next element, and to check the TextBlock.textLineCreationResult
property if you get a null.
Could it just be that the number of lines in the paragraph when to zero?
-Alex
On 11/6/14, 2:26 AM, "Harbs" <ha...@gmail.com> wrote:
>I ran into an issue where I have a runtime error in
>TextFlowLine.getTextLine(). I’m having trouble stepping through things,
>but as best as I can figure, the issue is caused by the umber of lines in
>a paragraph becoming reduced.
>
>The RTE happens inside TextFlowline.recreateTextLine() after requesting
>the line from the TextBlock. The function (I’m not sure if it’s
>createTextLine or recreateTextLine) returns null. The TextBlock.lastLine
>is the line before the current one.
>
>The caller of this mess is ComposeState.composeNextLine.
>
>If anyone is still following me, my problem is I’m not sure the best way
>to fix this. I’m not sure why this is breaking now. I’m not sure what I
>changed that’s causing this error. Should I fix
>TextFlowLine.getTextLine() to return null if there’s no more lines in the
>paragraph? Will there be any other repercussions from doing that? Should
>I fix ComposeState/BaseCompose so it does not try to compose the next
>line once the paragraph is out of lines?
>
>Is anyone familiar enough with the composer to even give me suggestions?
>:-(
>
>Harbs