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 <
<mailto:[email protected]>[email protected] <mailto:[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 <
<mailto:[email protected]>[email protected] <mailto:[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>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
>>> <mailto:[email protected]>[email protected]
<mailto:[email protected]>
>>
>>
>
>
> --
> Henry Minsky
> Software Architect
> <mailto:[email protected]>[email protected]
<mailto:[email protected]>
--
Henry Minsky
Software Architect
<mailto:[email protected]>[email protected]
<mailto:[email protected]>
