Consequences of Some Typing Errors on 's command line

Small typing errors are so common, and yet undocumented (why are common mistakes not documented?), that I thought I'd list several that have tripped me up on innumerable occasions. After all, why reinvent the car crash?

Consider a source file `pics.mf' that contains `mag=1200/1000;', so it is automatically scaled by 1.2 (ie, by magstep 1). If the target printer has 300 dpi, then a 360 dpi GF font is wanted.

Here is the gist of what happens for various typing errors, when using emTEX's `mf186' on a 286 PC to process `pics.mf'.

  1. mf186 $\Longrightarrow$ will keep prompting for arguments: 
        **

    We can type the contents of the command line here; for example, I can now type `pics'. In fact, even if you use the command line, the .log (`transcript') file shows echoing its interpretation of the command line to a ** prompt.

  2. mf186 pics $\Longrightarrow$ proof mode: 

        ! Value is too large (5184)

    No TFM is produced, and the GF file has resolution 3122 dpi. (3121.72 dpi, to be precise.)

  3. mf186 mode=localfont; input pics $\Longrightarrow$ misinterpretation: 
        ! I can't find file `modes=localfont.mf'.

    So, `modes' needs that backslash, otherwise mf thinks it's the start of a source font's filename. Backslash (` \') and ampersand (`&') are escapes from this standard interpretation by of the first argument. (Ampersand is in fact only a temporary escape, as resumes the mf filename prompting attitude as soon as a base is read.)

  4. mf186 \mode=localfont input pics $\Longrightarrow$ weird effect: 
        >> unknown string mode_name1.2
    ! Not a string
    <to be read again>
                      ;
    mode_setup-> ...ode)else:mode_name[mode]fi;
    l.6 mode_setup
                  ;

    Wow! What a difference a semicolon can make!

  5. mf186 \mode=localfont pics $\Longrightarrow$ almost nothing happens: 
        ** \mode=localfont pics

    *

    There's the echo I mentioned. From the lack of activity, pics evidently needs to be `input'.

  6. mf186 \mode=localfont; pics $\Longrightarrow$

    Same as 5.

    So, yes, when the mode is specified, we need `input' before `pics'.

  7. mf186 &plain \mode=localfont; input pics $\Longrightarrow$

    Works.

    Just as without the `&plain', it writes a GF file, `pics.360gf', which is correct. (MS-DOS truncates the name to `pics.360'.) So, redundancy seems okay. Does it waste time, though?