The !set keywords below affect the `!' commands available from the keyboard. Commands of this form that are not recognized as internal commands are assumed to be operating system commands, and are executed in a separate window under a command shell.
xterm -e sudo %s
As an example, a reasonable alternative might be
xterm -e su root -c \"%s \"which would use su rather than sudo, and require the root password.
The characters ``%s'' are replaced with a script invocation command that actually performs the installation. If this does not appear in the given string, this command will be added to the end, following a space character.
The internal script invocation command calls /bin/sh to run the shell script upd_install.sh found in the startup directory of the installation location. The three arguments to this script are the distribution file path, the distribution name token (such as ``Linux2''), and the installation location prefix (such as ``/usr/local''). This script, too, can be customized or replaced.
The default strings pop-up a terminal (xterm) window, and ask for a (root) password. The user, who needs to know a bit about Unix shell programming, can modify this behavior by setting this variable to a new string.
This sets an upper bound on the number of vertices in polygons created by a join operation. The default is 600 vertices. If set to 0, no limit is applied.
There is no internal limit on the vertex count of a polygon in memory. Although setting JoinMaxPolyVerts to 0 allows arbitrarily large polygons to be created, one should be reasonable. Huge polygons can be cumbersome and inefficient. Oversize polygons and wires will be broken up, if necessary, when a file is saved to disk. For the different formats, the limits are
native | no limit |
CIF | no limit |
CGX | 8000 vertices |
GDSII | depends on GdsOutLevel, max is 8000 vertices |
OASIS | no limit |
For CIF files, Xic can read/write arbitrarily large polygons and wires, but beware that other tools may have built-in limits.
When a collection of trapezoids is being combined into polygons during a join operation, the collection is first divided into connected groups, each of which will be converted to one or more polygons. This variable limits the number of trapezoids in the groups. The default value (when this variable is unset) is 0, meaning that there is no limit. Generally, applying a limit (for example, 300) provides faster join operations, however this will leave as separate objects more polygons that could have been joined.
When objects are being joined, they are first decomposed into trapezoids. The trapezoids from the objects are saved in a single list, and when the list length exceeds a certain value the list is sent to the function that recombines the trapezoids into polygons. This variable is used to set the length threshold. The default value (when this variable is unset) is 0, which allows the list to grow without bound. Generally, applying a limit (for example, 1000) provides faster processing, but will produce more polygons.
In a join operation, when building up the polygons and the vertex limit (JoinMaxPolyVerts) is reached, ordinarily the present polygon is output, and a new one is started immediately. This generally produces a set of polygons with complicated and seemingly arbitrary borders. If this variable is set, then the polygons are initially built ignoring the vertex limit, and polygons that exceed the vertex limit are split into pieces along Manhattan bisectors, so that no piece exceeds the vertex count. This gives a much nicer looking layout, but is more compute intensive.
By default, wires do not participate in join/split operations, these operate on boxes and polygons only. Wires, however, will be joined with other wires on the same layer it they share an endpoint and have the same width.
If this variable is set, then wires will be treated like polygons in join and split operations, but wires never participate in the join operation when new objects are created.
In releases prior to 3.0.0, this variable was named ``LayerPartSize''.
When geometrical operations are performed over a large area, a logical square grid is created over the area relative to the lower-left corner. The operations are performed for each grid element that intersects the area, and the results are combined. This can be more efficient than performing the operations over the entire area in one shot. Performance rapidly degrades as the amount of geometry per grid area increases. Best performance is probably obtained with 10000 or fewer trapezoids per grid.
This variable specifies the size of the grid, in microns, set as a floating-point number. If not set, the default grid size is 100 microns. Acceptable values are 1.0 - 10000.0, or 0. If set to 0, partitioning is not used.
The variable tracks the Partition size set in the Evaluate Layer Expression panel from the Edit Menu.
Under Microsoft Windows, the value must be a full path name to the shell executable, and the COMSPEC environment variable is also consulted for the default shell, after the SHELL variable.
This variable can be set to the spot size in use, specified in microns. Thus, if the spot size is 0.1 micron, one would use
!set SpotSize 0.1If the SpotSize variable is unset or set to 0, the feature is disabled. The maximum value accepted is 1.0. With the SpotSize variable set to a positive value, objects created with the round and donut buttons will be created so that all vertices are placed at the center of a spot, and a minimum number of vertices will be used. The sides number is ignored. This applies only to figures with minimum radius 50 spots or smaller; the regular algorithm is used otherwise. An object with this preconditioning applied should translate exactly to the e-beam grid. This conditioning, with SpotSize set nonzero, applies only to objects created with the round and donut commands, and not the arc command or general polygons.