This was/is not a flash-bug, it's the way how they treat text-metrics.
Even today, if you don't add the 4px padding, the text will be cropped,
e.g. that's why I've added this line for the swf9-kernel implementation
of LzTextSprite:
if (this.sizeToHeight) {
//text and format is set, measure it
var lm:TextLineMetrics = textclip.getLineMetrics(0);
var h = lm.ascent + lm.descent + lm.leading;
/[...]/
*h += 4;//2*2px gutter, see flash docs for flash.text.TextLineMetrics *
this.setHeight(h);
}
On 6/24/2008 12:46 AM, Henry Minsky wrote:
As a historical note, there was some reason to have the padding of 4
px, I think I recall in early Flash players, there was a bug in text
rending such that without that padding, the text was clipped off at
one end.
On Mon, Jun 23, 2008 at 6:33 PM, André Bargull <[EMAIL PROTECTED]> wrote:
[...] getTextHeight is actually supposed to return the height of the text.
This was my reading of these functions, so "LzTextSprite#getTextHeight()"
returns the "Text height", whereas "LzTextSprite#getTextfieldHeight()"
returns the "Text Field height" [1]. That makes: "sprite.getTextHeight() +
2*2 == sprite.getTextfieldHeight()" (swf, single-line text, auto-sizing,
uniform text-format).
In dhtml, there is no distinction between a "Text height" and "Text Field
height". What we did to get the same results for dhtml compared to swf, was
to add a 4px padding, see "LzTextSprite.prototype.getTextSize(..)". At that
point, "swfsprite.getTextfieldHeight() == dhtmlsprite.getTextfieldHeight()"
should have yield the same result.
This also explains, why we went round in circles...
-LzInputTextSprite.prototype.getTextHeight = function () {
- var h = this.getTextfieldHeight();
- *if (this.quirks.emulate_flash_font_metrics) {*
- * h -= 4;*
- *}* - return h;
-}
[1]
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/images/text-metrics.jpg
On 6/23/2008 11:12 PM, P T Withington wrote:
I'm sure there is confusion, because we have this horrible quirk in DHTML
that adds 4 to all font measurements. But comparing the swf and DHTML
versions of getTextHeight, I see that the 4 is _not_ added there in DHTML,
so perhaps this is my mistake, getTextHeight is actually supposed to return
the height of the text.
I'll try reverting that bit of the change and see what happens...
On 2008-06-23, at 17:04 EDT, André Bargull wrote:
If there is any confusion about flash text-metrics, you can take a look
at the ref for "TextLineMetrics" [1], which explains how flash treats
text-height (especially the 2px-gutter).
From "LzTextSprite.prototype.getTextHeight":
* This is the height of a single line of text in the current format
* *NOTE: this is not the clip textHeight, which "when autoSize is true
* is always 4 pixels less than _height" (which might explain the need
* for emulate_flash_font_metrics in DHTML?)*.
[1]
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/text/TextLineMetrics.html
This is surely fallout from r9824 which was to fix the computation of
getTextHeight (c.f., LPP-4651). So, either I got that fix wrong, or, apps
were compensating for that measurement being wrong and now look wrong
because the measurement is right.
Feel free to ping me if you have questions, but perhaps you should
start by reviewing r9824 to see if you can spot an error. Max did review
it, Henry it is still awaiting your review, and Don, feel free to chime in!
On 2008-06-23, at 16:17 EDT, Henry Minsky wrote:
I see this in the weather demo input text box. The text appears
scrunched in the upper left, and not even close to centered, in
Firefox/swf8/OSX.
I can't find any existing bug report filed on this, though
I'm sure I saw it mentioned in email in the last week or so.
On Mon, Jun 23, 2008 at 3:44 PM, Donald Anderson >
<[EMAIL PROTECTED]> wrote:
Hello all,
I've been assigned LPP-6503, which seems to be a more general
problem
with <edittext>. To see this, open:
http://localhost:8080/trunk-doc5/docs/reference/lz.edittext.html
In the example, notice how the text in the edit box is very high.
Start
adding
more text and it moves up another pixel or two. I see this on >>
Safari
and Firefox on OSX. Maybe it has been reported already?
- Don
On Jun 23, 2008, at 3:17 PM, Lou Iorio (JIRA) wrote:
[
http://www.openlaszlo.org/jira/browse/LPP-6503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lou Iorio updated LPP-6503:
---------------------------
Summary: refGuide - text input field on the Contents tab of the
>> nav pane
cutting off text (was: refGuide - textinput field in refGuide tab
>> browser
not functioning properly)
Assignee: Donald Anderson (was: Lou Iorio)
refGuide - text input field on the Contents tab of the nav pane >>
cutting off
text
--------------------------------------------------------------------------------
Key: LPP-6503
URL: http://www.openlaszlo.org/jira/browse/LPP-6503
Project: OpenLaszlo
Issue Type: Bug
Components: Documentation - RefGuide
Affects Versions: RingDingTools (4.1 Ref Guide + Tools)
Environment: FF3/XP
Reporter: Lee Lundrigan
Assignee: Donald Anderson
when you type data into the text input field the text is not >>
centered in the
field but raised up towards the top, some parts of the text leaving
>> the
field.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the >>
administrators:
http://www.openlaszlo.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
--
Don Anderson
Java/C/C++, Berkeley DB, systems consultant
voice: 617-547-7881
email: [EMAIL PROTECTED]
www: http://www.ddanderson.com
-- > Henry Minsky
Software Architect
[EMAIL PROTECTED]
