Geert Bevin - 12/May/07 10:30 AM Firefox 2.0.0.3 MacOSX

Geert Bevin - 12/May/07 10:34 AM If I use setText(), like this (web/panes/displaylists.lzx line 79): setText(value+' <font size="9" style="font-size: 9px" color="#999999">(sharing)</font>'); I'm able to force the font size through CSS

Benjamin Shine - 14/May/07 02:03 PM I can reproduce this problem at http://localhost:8080/blablalist.lzx?lzr=dhtml in Firefox 2.0.0.3 on Mac OS X. It looks correct in swf and wrong in dhtml, with ridiculously large text that gets clipped vertically.

Benjamin Shine - 14/May/07 02:26 PM To reproduce in a few lines of code: <!-- Copyright 2007 Laszlo Systems --> <canvas>     <class name="formlabel" extends="text" resize="true" fontsize="14"/>     <formlabel><b>Name your new list </b><font size="11"><i>(Eg: "Things I need to do today")</i></font></formlabel> </canvas>

Benjamin Shine - 14/May/07 02:34 PM This can be further reduced to     <text>i become <font size="17">bigger</font> in the middle</text> That renders as expected in swf, but insanely large and clipped in dhtml.

Mamye Kratt - 15/May/07 05:24 PM Ben's example: I think LPP-3965 (filed by Geert Bevin, ridiculously large text) is a dhtml kernel bug, if I remember how this all works. Just this demonstrates the bug: <text>i become <font size="17">bigger</font> in the middle</text>

Benjamin Shine - 16/May/07 10:56 AM I can't figure this one out yet.

Benjamin Shine - 16/May/07 11:21 AM Using css makes it work in DHTML, <text>better become <font style="font-size:17px">bigger</font> in the middle</text> but causes a compilation warning in swf: fontsize.lzx:11:54: attribute "style" not allowed at this point; ignored

Benjamin Shine - 16/May/07 12:17 PM In dhtml, <font size="17"> means huge, because <font size="1"> is the default font size. The units of the size attribute of the font tag are not pixels in dhtml; In swf, the units of the size attribute of the font tag *are* pixels. The css specification doesn't work in swf. In other words, there doesn't seem to be a single pattern for specifying font size in the same units in swf and dhtml. This is a problem. I think the solution is something like having the compiler transform input lzx into "do-what-i-mean" output code. For dhtml, we should use the style attribute with css; for swf, we should use the non-standard-units size attribute. How do we know whether the developer meant 17px or semantic size 17 when they write <font size="17">? If they are thinking htmlishly, they mean semantic size 17; if they are thinking swfishly, they mean 17px. We like to be standards-compliant, so we should interpret <font size="17"> in a htmlish way, as the huge size 17, not 17px. Then the problem becomes, "how do we monge the swf output to look the same as the dhtml output, despite different units?" That will probably be a compiler trick.

Geert Bevin - 16/May/07 12:26 PM Hmm ... that means that the font sizes app existing apps will have to be adapted if people want to port them to dhtml? Not so good imho.

Amy Muntz - 09/Jan/08 11:29 AM Mamye - please push this to the top of the queue and verify that it is still a bug? If it is, assign to Max. We think this might ahve been caught mid-stream.

Mamye Kratt - 09/Jan/08 12:04 PM (trunk 4 build r7751 - ringding) This test file works now: <!-- Copyright 2007 Laszlo Systems --> <canvas>     <class name="formlabel" extends="text" resize="true" fontsize="14"/>     <formlabel><b>Name your new list </b><font size="11"><i>(Eg: "Things I need to do today")</i></font></formlabel> </canvas>