[tex-k] Potential bug in MF: path syntax inconsistencies regarding direction specifiers
Dominik Leininger
dominik.leininger at t-online.de
Sat Aug 19 18:40:58 CEST 2023
Hello everyone,
I noticed that on page C258 the tall `line' (l. 13906-13911 in
mfbook.tex) in the middle of the page seems to allow something like
(0,0){left}--{curl 4}(1,1). After -- expanded to {curl 1}..{curl 1},
this path becomes: (0,0){left}{curl 1}..{curl 1}{curl 4}(1,1). This
raises an error in MF and contradicts the rules on page C129 (l. 7580 in
mfbook.tex) which allow only one <direction specifier>.
I've tested this a bit and interestingly a path expression like p{A}
{B}..q (or with more direction specifiers {C} etc.) is accepted by MF
and the last direction specifier is used to build the path. A path
expression like p..{A} {B}q causes an error (! A tertiary expression
can't begin with `{'.) as suggested by the rules on page C129.
I also tried the path join `softjoin' combined with a <direction
specifier> as suggested on page C258. A path expression like p{A}
softjoin q is possible. Even p{A} {B} softjoin q works, but in this case
the first direction specifier is used instead of the last direction
specifier (as with the basic path join `..'). If you try to follow the
syntax suggested on page C258 and enter a path expression like p
softjoin {A}q, an error is raised, indicating another problem in the
tall `line' on page C258.
Furthermore, page C258 doesn't list the syntax of a direction specifier
like {1,3}, only {(1,3)} is allowed based on C258.
Summary of inconsistencies to be addressed:
- The path join syntax on page C258 contradicts the rules on page C129
regarding on the number of direction specifiers, since C258 allows `--'
with additional direction specifiers.
- The rules on page C129 only allow one direction specifier before
<basic path join>, whereas MF does accepts multiple direction specifiers
before <basic path join> without errors.
- Page C258 suggests that MF can process p--{A}q or p..{A} {B}q, but
this raises an error.
- As a consequence of the above: When it comes to what MF accepts as
input and can parse, the maximum number of direction specifiers before
<basic path join> is different from that after <basic path join>.
- A direction specifier after a softjoin (as suggested on page C258)
will cause an error.
- The syntax on page C258 doesn't list the direction specifier
{<numeric>,<numeric>}, while page C129 lists {<numeric
expression>,<numeric expression>} as a valid <direction specifier>.
I think there should be consistency between the syntax on page C129,
page C258 and the capabilities of MF. It is strange that something like
(0,0){left} {curl 4} {up} .. {up} {curl 4} {left}(1,0) doesn't work but
(0,0){left} {curl 4} {up}..{up}(1,0) is correct MF input.
I wrote this report from the perspective of the inconsistencies rather
than looking at possible solutions, as there are multiple options for
what to change and what to leave as is. I don't know if the possibility
of multiple direction specifiers is a bug in MF, and if this should be
fixed to e.g. throw errors for multiple direction specifiers (something
like: A basic path join can't begin with `{'.), or if the rules on page
C129/C258 should be adapted to the actual possibilities. In any case, I
think the tall `line' on page C258 should be fixed, as it suggests
things that throw errors.
Best regards,
Dominik
More information about the tex-k
mailing list.