If your display simulates a bigger virtual screen (i.e. an XFree server
with a bigger virtual screen), the size of the overall screen area must
to be entered (i.e. including the invisible part).
This is because ST/X computes the resolution from the
given screenSize and the display extent (in pixels).
However, there is usually no way to get information about the physical
dimensions.
The exact resolution is required if you want 1:1 display of graphics;
for example, the DrawTool demo program adjusts its scaling to draw its figure
in the actual size.
Also, the PostscriptGraphicsContext class needs those values, to adjust
the printing scale and to compute font sizes for systems which do not
provide postscript font metrics.
Finally, some popup dialogs compute their default extent to be sized
a certain number of millimeters or inches.
If the common-sizes list does not include a valid dimension for your actual monitor, you should specify the size by entering the numeric values.
Notice, that Smalltalk/X asks the display (i.e. the Xserver) about the screen dimensions. However, in practice the values as returned are not realistic on most - especially PC based - systems.
To have the screens size be set automatically at startup time,
add a line such as:
to your
Display widthInMillimeter:xxx; heightInMillimeter:yyy.
"display.rc" file
(or to a display-specific "d_xxx.rc" file).
Especially clear this, if you are running on a black & white laptop with a color VGA Xserver.
If disabled, your display may run out of available colors when images are displayed; this affects both smalltalk itself and other graphical applications.
Since no colors have to be allocated from the display,
image rendering is much faster if the fixColor option is enabled.
Especially, when viewing many images (for example: with the HTML browser).
On trueColor systems, the above cannot happen - there, this
setting is disabled.
Therefore, if you have a choice when setting up your display
hardware, we recommend using the trueColor mode, if possible.
A good compromise between speed and image display quality is obtained
by using a fix color palette combined with the error diffusion algorithm.
This will not run out of colors AND provides reasonably good image quality.
Owners of trueColor (i.e. 24bit/pixel) systems are lucky: they do not suffer from the limited color problem and do not have to care for those settings.
Typically, this error does not exist in newer (X11R5 and later) Xservers.
For example, when pasting japanese text which was selected in a netscape
browser, use "EUC" clipboard encoding.
For 'normal' ascii and iso8859 strings, this should be left as "untranslated" (this is the default).
For more information, read "Configuration & Customization".
Copyright © Claus Gittinger Development & Consulting, all rights reserved