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 (paper) 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 ST/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
Screen default 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 enabled, Smalltalk/X preallocates 6x6x4 colors and
only uses those when bitmap images are displayed.
If disabled, colors are allocated as required.
Enabling the fix colorMap, usually results in suboptimal image quality,
but the system will never run out of colors
- also, some colors remain to be used by other applications.
If disabled, your display may run out of available colors when images are displayed; this might affect 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 displays (i.e. 5x5x6 or even 8x8x8 available colors),
the above situation 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