In order to avoid specifying each attribute by hand, a mechanism of automatically
setting these attributes is in place. If you set none of a triplet for a block,
and it is not a single child, it inherits the alignment attributes from
the running style for that direction. Two styles row
and
col
are defined containing the default alignment attributes for
row and column-oriented arrangement, respectively. The box
, shape
and row
blocks automatically add the style row
to the running style,
while the boxcol
and col
blocks add the style col
. You can
also manually add these styles by adding use col;
or use row;
anywhere. Subsequent boxes will be arranged such.
![]() | ![]() |
The col
style can be defined as
defstyle col [mtop=prev@mbottom, center=prev];
making each block "stick" to the previous one from below and to center horizontally to it. Applying it to a block or to the running style will make these the default value for that and any following block.
Note that, since applying this to the first block would case an error (there is no
prev
of a first block and it also cannot align to itself), alignment
attributes referring to invalid prev
, next
, first
or last
block names are silently ignored if the attribute is coming from a style. If, on
the other hand, you specify top=prev@bottom
on a first block
explicitly, you will get an error.
Unfortunately, the above definition is not sufficient,
since if we have a series of blocks and assign a
custom alignment for one in the middle, then it will stop "sticking" to the
previous one. Like on the example below (where we specified all alignment
attributes manually, to prevent any of the defaults to apply.
This makes blocks A
and B
(as a group) unrelated to any other
block vertically. (Clearly block B
"sticks" to block A
, but none
of them have any other vertical alignments.) Since Msc-generator strives to
minimize the size of each block, it will overlap blocks A
and B
with
blocks C
and D
to minimize the height of the unnamed column they are in.
![]() | ![]() |
To prevent this and always provide a suitable default the style col
is actually defined such that each block "sticks" to both to its previous and next blocks.
defstyle col [mtop=prev@mbottom, mbottom=next@mtop, center=prev];
This can lead to unwanted effects, if you specify alignment for two blocks in a
row, with specifying no special alignment for the block in between them. On the figure
below we tied block M
and O
to the left and right side of the row above
and kept the default (sticky) behaviour for block N
in-between. We gave
on where to position block N
, just that it shall align to the blocks left and
right to it. Msc-generator has chosen to break the stickiness between blocks N
and O
quite at random.72
![]() | ![]() |
To fix this situation, clear one of the alignment attributes of N
, like below.
![]() | ![]() |
This prevented inheriting the default alignment attribute left
but still allowed all other alignment attributes (specifically right
)
to apply to block N
.
To summarize the rules for inheriting alignment attributes:
Finally, sometimes one wants to break this mutual alignment reference between two neighbouring boxes, perhaps, because alignment will be fully specified for the subsequent one and we don’t want the former one to keep "sticking" to it.
![]() | ![]() |
While this can be done by clearing one attribute of D
(right=
),
it is not so intuitive. So as syntactic sugar
we can use the break;
command. Any alignment attribute
referencing this zero-sized block is silently dropped (even values, you explicitly assign).
![]() | ![]() |
Specifically, alignment requirements of blocks deeper in a nester block hierarchy or earlier in the source file take precedence, if the two alignment has the same priority. See Block Layout Conflicts.
...with the horizontal alignment
attributes being: left
, center
, right
,
mleft
, xcenter
, xcenter
, mright
and xpos