RES home
The encoding is designed in such a way that one does not have to be aware whether one encodes for a left-to-right or for a right-to-left direction. In particular, there is nothing in the encoding that corresponds to 'right' or 'left'. Instead, there are some arguments that refer e.g. to the start ('s') or the end ('e') of a glyph or a group of glyphs. In a left-to-right direction, 's' refers to the left and 'e' to the right, but in a right-to-left direction, 's' refers to the right and 'e' to the left.
Consequently, if one replaces 'hlr' (or 'hrl', 'vlr', 'vrl') in the header by 'hrl' (or 'hlr', 'vrl', 'vlr', respectively), then the new appearance will be the exact mirror image of the former one, with one exception: a string in a note should always appear as a normal sequence of characters in the (Latin) alphabet. This does not hold for characters in short_strings (cf. the definition of named_glyph), which may be mirrored just like other glyphs.
Similar to 's' and 'e', we also have the attributes 'before' and after, which are used to place parts of glyphs outside a virtual bounding box. For a left-to-right direction, 'before' (or 'after') is interpreted as 'to the left of' (or 'to the right of', respectively).
For boxes, 'opensep' and 'closesep' refer to the left and right sides in the case of a horizontal left-to-right direction, to the right and left sides in the case of a horizontal right-to-left direction, or to the top and bottom sides in the case of a vertical direction. The attributes 'undersep' and 'oversep' refer to the bottom and top sides in the case of horizontal directions, to the left and right sides in the case of a vertical left-to-right direction, or to the right and left sides in the case of a vertical right-to-left direction.
If this implementation-determined direction and the direction in the encoding are both horizontal, or both vertical, then the difference amounts to a mirror image, apart from the notes as explained above. However, when the implementation-determined direction is vertical and the direction in the encoding is horizontal, or vice versa, then it is less trivial exactly how the implementation is to handle the encoding.
Central in switching between vertical and horizontal directions is the operator '-', which can indicate both horizontal arrangement and vertical arrangement of top_groups, depending on whether the text direction is horizontal or vertical. It is recommended that the encoder makes use of '-' next to '*' and ':' in such a way that a switch between vertical and horizontal directions preserves an esthetically pleasing result.
For boxes that are rotated by 90 degrees as a result of an implementation-determined switch of direction from horizontal to vertical, shade_patterns should be interpreted so that 't' is read as 'e', 'b' is read as 's', 's' is read as 't' and 'e' is read as 'b'. For a switch of direction from vertical to horizontal, the reverse mapping should be applied.
There is no infallible way to map shade_patterns attached to occurrences of '-' intended for a horizontal direction to those suitable for a vertical direction, or vice versa. One may however choose reasonable strategies such as to make the entire area shaded if at least one shade_pattern is given, or apply the same mapping as in the case of boxes.
Another complication is the argument 'fit' at occurrences of '-'. When an implementation-determined switch takes place from a horizontal to a vertical direction, or vice versa, we assume such arguments are ignored.
Also uses of the attributes 'before' and 'after' (or 'above' and 'below') that were intended for a horizontal direction (or vertical direction, respectively), may not give satisfying results if there is a switch of text direction to a vertical (or horizontal) one. For this reason, the implementation is free to ignore some or all occurrences of such attributes in this case.