I guess we need to dig deeper. 8 is a multiple of 4, so it's probably
related. Perhaps the 4 us being added somewhere where it should have
been subtracted? We just need to be careful not to throw in a random
4 and throw eveything else off.
On Apr 2, 2010, at 10:30, Henry Minsky <[email protected]> wrote:
From this test case
<view>
<inputtext fontsize="28" fgcolor="red" bgcolor="#cccccc"
id="it6">DEWWW</inputtext>
</view>
<text x="500" y="80" text="${'it6.getTextWidth() '+
it6.getTextWidth() + ' it6.width = '+it6.width}"/>
When the inputtext is created, it gets a width 128, and that's what
the view's width gets set to, but when you call getTextWidth() to
examine the value it returns a value of 136.
The funny thing is that the sprite appears to be returning the
'correct' value when an input text is constructed, and then
subsequent calls to getTextWidth are returning a different value.
The first time (which is during text field construct) getTextWidth
returns the 'correct' (e.g., swf8 LPS 4.2 compatible) value.
The second time it's called, it returns a value 8 pixels wider.
Now, it's kind of an uncommon use case, because in most
applications, I don't think people let input text fields autosize
their width, but it's disturbing to have two different values
returned.
On Thu, Apr 1, 2010 at 9:06 PM, P T Withington <[email protected]> wrote:
I think this is the history:
1) we used to use this Flash API that for unknown reasons reports
the text width 4px too small, but only when 'autosize' is on.
2) this caused italics to get clipped, so we always added 4 pixels
to the width.
3) we split the lfc, but left the compensation for the "4 pixel bug"
in the general part
4) we decided we wanted HTML metrics to match flash, so we had to
fake the 4-pixel delta in the DHTML kernel
5) we discovered that the Flash 4-pixel offset only happened
sometimes (when 'autosize' is on), but we had it always on in the
DHTML kernel.
6) I got rid of the 4-pixel offset in the general lfc and switched
the Flash API to be one that doesn't conditionally subtract 4 pixels.
7) So now everyone should be in agreement, as long as they use the
LFC API.
What is the bug that you are seeing? I claim the numbers should all
be the same at the LFC API, all we did was change the kernel
(sprite) API to be consistent across platforms.
On 2010-04-01, at 16:58, Henry Minsky wrote:
> I'm confused now -- what does it mean to have
> I'm going around in a little circle here for some reason..
>
> We have as a goal to have text fields with the same font style and
content
> measure the same width and height across all platforms, right?
>
> So we set target pixel values for what we want to see, and
we've picked
> whatever was the old 4.2 swf8 LzText behavior for backward
compatibilty
> reasons.
>
> So isn't the contract for LzTextSprite.getTextWidth() for each
platform to
> ensure that
> it returns the same value as the old swf8 "monolithic LFC" returned?
>
>
>
>
> On Thu, Apr 1, 2010 at 4:32 PM, P T Withington <[email protected]>
wrote:
>
>> Before I did this, I would _really_ want to understand why it was
changed.
>> It seems this was the end result of a _lot_ of discussion related
to:
>>
>> http://jira.openlaszlo.org/jira/browse/LPP-6580
>>
>> You, Max, and André all had input on this.
>>
>> getTextWidth is a Kernel API, which is used by the LFC. So, it
needs to
>> have a contract that is the _same_ for all platforms.
>>
>> I changed this and left a note as to why:
>>
>> /**
>> * Calculates the current width of the text held by the text field.
>> *
>> * @devnote NOTE: [2009-03-01 ptw] this is _not_ the clip
textWidth, which
>> * "when autoSize is true is always 4 pixels less than
_width" (which
>> * is why we have to add 4 pixels for emulate_flash_font_metrics
>> * in the DHTML version of this method, and why Henry used to add
>> * PAD_TEXTWIDTH to the textWidth!)
>> *
>> * @devnote NOTE: [2009-03-28 ptw] But if the text is empty, we
return
>> * 0. <sigh />
>> */
>>
>> The way I read that, when we split the LFC to have platform
kernels we
>> screwed up the abstraction and left part of the platform-specific
stuff
>> (this 4px offset from the Flash API) in the general part of the
kernel.
>> This change fixes that, so that _all_ the kernels are measuring
the same
>> thing.
>>
>> You clearly cannot just change the Flash kernel, because then it
would be
>> skewed from the other kernels.
>>
>> On 2010-04-01, at 14:08, Henry Minsky wrote:
>>
>>> We used to measure text width in LzTextSprite by looking at the
Flash
>>> 'TextField.textWidth' property (and adding
>>> 4 pixels of padding because it clipped otherwise).
>>>
>>> At some point that method was changed to look at the
TextField._width
>>> instead, which gives different values (slightly larger ones).
>>>
>>> Anyone remember what the thinking there was? I'm inclined to
revert that,
>> so
>>> that we're compatible with the
>>> 4.2 text width in swf8.
>>>
>>>
>>>
>>> r13517 by ptw has the last assignment according to svn blame
>>>
>>> " Fixed getTextWidth, getTextHeight, getTextfieldHeight,
>>> to obey kernel API contract."
>>>
>>>
>>>
>>> --
>>> Henry Minsky
>>> Software Architect
>>> [email protected]
>>
>>
>
>
> --
> Henry Minsky
> Software Architect
> [email protected]
--
Henry Minsky
Software Architect
[email protected]
