Here is some advice I have given out a few times in response to questions to Curl Support. It will probably show up in the documentation of our next major release.
just big enough to contain the text. Now somebody runs the applet on
a screen set to 120 dpi resolution. Since pixels are smaller on that
screen relative to points, the user of the applet will find that the
box is too small to hold the text, and some text will be clipped.
run time on a machine that is configured the same way as the
developer's machine, but since different displays (and printers) have
different pixel sizes, different fonts, etc., the VLE cannot give you
a perfect WYSIWYG view of how an applet will look on every possible
client platform. If you use a practice of specifying
heights and widths tightly in "px" units on every object, they will
be at risk for problems when applets are displayed on machines that
are not configured the same way as the developers' machines, and
possibly they will also find that applets do not look good when
printed. So if you want to develop applications in this
way, you should leave some margin for variation and not specify sizes
too tightly. You should also test the appearance of the applications
when printed and when displayed on all the different display
configurations that your customers may use.
constructed in this way is much more adaptable when executed on
differently configured machines.
interactions with other objects that have resolution-independent unit sizes.
There is a serious risk using "px" units to set widths and heights in layouts. Character font sizes on computer systems are conventionally specified in terms of points ("pt"). Suppose you use the VLE on a screen with 96 dots per inch resolution and you make a text object that contains some text using a 10pt font. Then you setthe height and width of the text box using "px" units so that it is
just big enough to contain the text. Now somebody runs the applet on
a screen set to 120 dpi resolution. Since pixels are smaller on that
screen relative to points, the user of the applet will find that the
box is too small to hold the text, and some text will be clipped.
The VLE does give you a good WYSIWYG view of how a layout will look at
run time on a machine that is configured the same way as the
developer's machine, but since different displays (and printers) have
different pixel sizes, different fonts, etc., the VLE cannot give you
a perfect WYSIWYG view of how an applet will look on every possible
client platform. If you use a practice of specifying
heights and widths tightly in "px" units on every object, they will
be at risk for problems when applets are displayed on machines that
are not configured the same way as the developers' machines, and
possibly they will also find that applets do not look good when
printed. So if you want to develop applications in this
way, you should leave some margin for variation and not specify sizes
too tightly. You should also test the appearance of the applications
when printed and when displayed on all the different display
configurations that your customers may use.
Curl's recommendation is to use containers like HBox, VBox, and Table, and let the Curl layout system calculate the sizes of objects based on their contents. An applet
constructed in this way is much more adaptable when executed on
differently configured machines.
Of course, it is reasonable to use px units for some things like bordersand tree-connector-width, where I think it is less likely to have the bad
interactions with other objects that have resolution-independent unit sizes.