Return-Path: X-Original-To: apmail-flex-dev-archive@www.apache.org Delivered-To: apmail-flex-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 15DA2C340 for ; Sun, 23 Nov 2014 21:57:01 +0000 (UTC) Received: (qmail 56935 invoked by uid 500); 23 Nov 2014 21:57:00 -0000 Delivered-To: apmail-flex-dev-archive@flex.apache.org Received: (qmail 56899 invoked by uid 500); 23 Nov 2014 21:57:00 -0000 Mailing-List: contact dev-help@flex.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@flex.apache.org Delivered-To: mailing list dev@flex.apache.org Received: (qmail 56876 invoked by uid 99); 23 Nov 2014 21:57:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Nov 2014 21:57:00 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of harbs.lists@gmail.com designates 209.85.212.182 as permitted sender) Received: from [209.85.212.182] (HELO mail-wi0-f182.google.com) (209.85.212.182) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Nov 2014 21:56:32 +0000 Received: by mail-wi0-f182.google.com with SMTP id h11so4005037wiw.9 for ; Sun, 23 Nov 2014 13:54:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=bbFpa+mnR4sKadG0ZIrRXJE4b29prvyTiFzKs8NpTFA=; b=Ucd81/W4J9tEG2B43GYRB7JyFNnAm1SmhK3rB0HDzemKiVuOG/d9uuN6xWc/cNyw3T VG/lEUX/PKQ7kTTyPFmquQQLIMD1UYyePnxwscOvBxpcL9jY+ve1XXIFxcvPJHRA44EB NiMCKdDkUvdG1V/5EOcqw1fcYhE3wwVTTgrcEh8ElSeSamTvuz6LAjutlEpTIamFWyoj iXxgR5kXjLFpHzPUTZmu5zQR3BMjyZgFzx4F6YM5VM5eKFGCnsvprNPlXFgh/XBv+f5c zy34MGQ4SZphit7ZYEySICQNARHJ4kQJF3s6qruLxYm5D6G3Obg837LI5Fig7Q4kX+cL 0wEQ== X-Received: by 10.194.187.164 with SMTP id ft4mr27734394wjc.76.1416779656524; Sun, 23 Nov 2014 13:54:16 -0800 (PST) Received: from [192.168.0.4] ([5.102.211.165]) by mx.google.com with ESMTPSA id fl1sm9293953wib.15.2014.11.23.13.54.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Nov 2014 13:54:15 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: TextFlowLine recycling From: Harbs In-Reply-To: Date: Sun, 23 Nov 2014 23:54:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7BB1BB3E-7106-4016-A47B-960272858D35@gmail.com> <0580B6BA-6AFA-475D-90AC-1C68D354D1EA@gmail.com> <5033B4EF-FC0D-4496-9212-07CCB0011B20@gmail.com> <1938CEA9-13F8-41E9-B437-06EEF8B5237B@gmail.com> <7D31E35C-A8DB-4E2B-B674-7C561A61DD0D@gmail.com> <9880725D-F289-41AA-8195-443D43857688@gmail.com> <97CB0527-1D9D-41B2-B1C1-32FF63D56A1B@gmail.com> <31F05195-B0EA-4B91-9C4B-4AA7A8400A91@gmail.com> <7452BF89-6973-4DDB-A268-627892A14235@gmail.com> To: dev@flex.apache.org X-Mailer: Apple Mail (2.1878.6) X-Virus-Checked: Checked by ClamAV on apache.org Phew! Looks like I fixed this issue. Once I found the problem, the fix was = straight-forward... There=92s still some failures with FloatTests, but = nothing as bad as what we were getting before. I=92m going to comment on the other FlexUnit discussion about the = remaining errors. On Nov 23, 2014, at 11:38 PM, Harbs wrote: > Duh! >=20 > I=92ve actually been working on this for so long, I forgot what I=92ve = done! :-( >=20 > I just looked through the git logs and I see, that I=92m 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. >=20 > Since it=92s my mistake, I can fix this with impunity! Phew! :-p >=20 > No back to our regular programing=85 ;-) >=20 > On Nov 23, 2014, at 11:22 PM, Harbs wrote: >=20 >> Here=92s what I *think* is happening: >> 1) ComposeState.composeNextLine() calls createTextLine() and gets a = TextLine. >> 2) Part of what BaseCompose.createTextLine() does is: _curLineStart = +=3D _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. >>=20 >> I=92m really nervous about fixing this, because I=92m not sure why = it=92s failing now, but was not failing before. >>=20 >> The above logic makes no sense to me, but it=92s not something that I = changed. Without understanding how it=92s *supposed* to be working, I = run the risk of breaking other areas by fixing this. I=92m obviously = missing some nuance in the logic here. >>=20 >> Anyone interested in sticking their noses into this mess? >>=20 >> On Nov 23, 2014, at 11:00 PM, Harbs wrote: >>=20 >>> I went through all the ParagraphElements and TextFlowLines. I added = it up, and it=92s 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. >>>=20 >>> Now I just need to figure out where that=92s happening=85 >>>=20 >>> On Nov 23, 2014, at 9:55 PM, Harbs wrote: >>>=20 >>>> I=92m back on this. I have a simpler case where things are getting = out of sync. >>>>=20 >>>> I have a line where the _curElementOffset is 382, the = _curElementStart is 803 (total 1201). >>>>=20 >>>> The total textLength of the textFlow is 1201. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> It looks like the whole paragraph and TextBlock is somehow out of = whack >>>>=20 >>>> Sorry for the noise, but I=92m writing this in the hope that the = lightbulb will come on for either me or someone reading this=85 >>>>=20 >>>> Harbs >>>>=20 >>>> On Nov 18, 2014, at 12:23 AM, Harbs wrote: >>>>=20 >>>>> Right. My question is more related to TextFlowLines than Slugs = though. >>>>>=20 >>>>> Let=92s 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=92m having trouble = understanding the architecture here. >>>>>=20 >>>>> What I would have done if I was designing the engine would be to = recalculate geometry of the TextFlowLine each time I=92m composing it. = If the geometry changed, I=92d throw out the old TextLine and ask the = textBlock for a new one. Getting new TextLines, I see, but recalculating = the geometry I don=92t. >>>>>=20 >>>>> I assume I=92m missing something obvious. If someone can help me = spot it, that would be great! >>>>>=20 >>>>> (BTW I just fixed a vertical placement issue with table blocks. = I=92m committing it now.) >>>>>=20 >>>>> On Nov 18, 2014, at 12:17 AM, Alex Harui wrote: >>>>>=20 >>>>>> I don=92t know for sure, I just looked up the Slug class. It = says it is >>>>>> created by Parcels to track geometrical line information. >>>>>>=20 >>>>>> 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=92m 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. >>>>>>=20 >>>>>> If the table work has changed the recalculation of the Slugs = because >>>>>> you=92ve deferred it in order to compute table cells, that might = be the >>>>>> cause. >>>>>>=20 >>>>>> I=92m not sure how well the code works for non-rectangular = parcels. >>>>>>=20 >>>>>> Good luck, >>>>>> -Alex >>>>>>=20 >>>>>> On 11/17/14, 3:27 AM, "Harbs" wrote: >>>>>>=20 >>>>>>> Just to be a little clearer: >>>>>>>=20 >>>>>>> I=92m not sure why this used to work, and now it doesn=92t. >>>>>>>=20 >>>>>>> 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=92m not sure how/why. >>>>>>>=20 >>>>>>> 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=92s composed (which is something that = I don=92t >>>>>>> think is happening currently). Of course there=92s no reason to = worry about >>>>>>> that until we might be adding that support=85 >>>>>>>=20 >>>>>>> I=92m also not entirely sure what the check that=92s failing is = supposed to >>>>>>> be checking for=85 >>>>>>>=20 >>>>>>> Harbs >>>>>>>=20 >>>>>>> On Nov 17, 2014, at 12:29 PM, Harbs = wrote: >>>>>>>=20 >>>>>>>> I took a little break on this to deal with some other crises. >>>>>>>>=20 >>>>>>>> I found where it=92s going off: >>>>>>>>=20 >>>>>>>> In BaseCompose.fitLineToParcel() this check was failing: >>>>>>>>=20 >>>>>>>> // check to see if we got a good line >>>>>>>> if (Twips.to(_lineSlug.width) !=3D = _curLine.outerTargetWidthTW) >>>>>>>> return false; >>>>>>>> The reason it=92s failing is because the _lineSlug width does = not match >>>>>>>> the new width of the line. (The first column/parcel is wider = than the >>>>>>>> second.) >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> So, I=92m back to my original question. What=92s the correct = way to deal >>>>>>>> with this situation? I=92m not 100% sure how line slugs and = TexFlowLines >>>>>>>> are supposed to interact. >>>>>>>>=20 >>>>>>>> Any suggestions? >>>>>>>>=20 >>>>>>>> On Nov 7, 2014, at 10:34 AM, Harbs = wrote: >>>>>>>>=20 >>>>>>>>> A bit more progress: It looks like things go off where the = text flows >>>>>>>>> from one container into another mid-paragraph=85 >>>>>>>>>=20 >>>>>>>>> (Sorry for polluting the mailing list with this. I=92ll try to = be quiet >>>>>>>>> until I figure it out=85) >>>>>>>>>=20 >>>>>>>>> On Nov 7, 2014, at 9:55 AM, Harbs = wrote: >>>>>>>>>=20 >>>>>>>>>> It=92s pretty big. >>>>>>>>>>=20 >>>>>>>>>> It consistently gets out of whack at the end of the second = paragraph. >>>>>>>>>> I=92m getting closer to where it=92s going off=85 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Nov 7, 2014, at 1:01 AM, Alex Harui = wrote: >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On 11/6/14, 2:02 PM, "Harbs" wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I think it=92s _curElementOffset which gets updated. >>>>>>>>>>>>=20 >>>>>>>>>>>> It does look like something is getting out of sync. I=92m = just not >>>>>>>>>>>> sure yet >>>>>>>>>>>> what. This is one of those areas that=92s way too fragile = IMHO=85 Every >>>>>>>>>>>> time >>>>>>>>>>>> I=92ve run into these kinds of issues it=92s taken me days = to figure out >>>>>>>>>>>> exactly what=92s off. >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> -Alex >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20