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]
