[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Another technical question about arrow-building

My count of possible arrow-endings is 20:    

   bullet circ curlyhead dblhead dblheaddbl dblheaddown dblheadup
   harpoondbldown harpoondblup harpoondown harpoonup head headdbl hook
   lefthead mapsto none triangle trplhead turn

(these rather odd names are decyphered in the arrow-building kit
documents I sent round earlier).

One possible implementation of an arrow-building kit would therefore
be 20 left-facing demi-arrows and 20 right-facing demi-arrows, with
enough extensions and negation bits to construct every possible
combination of left arrow ending, extension, and right arrow ending.

However, there are three technical problems with such a kit:

1) Composite arrows take longer to build than arrows that are accessed
   directly.  On a SPARCStation IPC it takes 32 seconds to set a hundred
   thousand \rightarrows, and 66 sec to set a hundred thousand
   composite arrows, which is over twice as slow.  On the other hand,
   it's only one third of a millisecond more per arrow...

2) Composite arrows can't be set in unbraced subscripts, so $X_\foo$
   causes an error.

3) Composite arrows are subject to digitization errors by the dvi
   drivers.  For example, MF can guarantee that $\nleftrightarrow$ is
   rotationally symmetric, whereas if TeX puts
   <leftarrowhead><arrownegate><rightarrowhead> into the dvi file, some
   dvi drivers may adjust for drift between <leftarrowhead> and
   <arrownot> or between <arrownot> and <rightarrowhead>, and this may
   cause the composite glyph not to be rotationally symmetric.

Problems 1 and 2 can be addressed by making the more popular arrows
directly accessable as single glyphs via \mathchardef.  Problem 3 is
more difficult, and I need some advice from people who know the guts
of dvi drivers:

1) Are there many dvi drivers that will correct for drift between
   glyphs that have no space or kerning between them?

2) Does the dvi driver standard say anything about correcting for
   drift between glyphs?

And a more general question:

3) Is this worth worrying about, since the digitization errors will
   only be visible very rarely, and only on low-resolution printers?

Alan.