[tex-k] Potential bug in MF: path syntax inconsistencies regarding direction specifiers

[Dominik Leininger]

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