[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Another technical question about arrow-building
- To: firstname.lastname@example.org
- Subject: Another technical question about arrow-building
- From: email@example.com (Alan Jeffrey)
- Date: Wed, 11 Aug 93 19:58 BST
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?