Indeed. I guess we should duplicate this comment from `getTextHeight` to `getTextWidth`:
> * @devnote NOTE: [2008-06-24 ptw] tip 'o the pin to > * [email protected] for finding this illustration, which shows > * the relationship of textHeight and textfieldHeight: > * > http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/images/text-metrics.jpg On 2010-04-02, at 11:25, André Bargull wrote: > Just as a reminder to understand the flash text properties: > http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/images/text-metrics.jpg > > textWidth reports the width of text without the 2px gutter. _width includes > the gutter, so textWidth + 2*2 == _width (only if autoSize!='none'). > > > On 4/2/2010 4:51 PM, P T Withington wrote: >> 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] >> <mailto:[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 < >>> <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]> >>> >>>
