> I had gotten in a new printer recently, and I discovered that when printing
> medium-to-large files that it dropped/munged characters, causing printer
> errors.  I remembered a number of people reported this problem, but as far
> as I can remember, no one proposed a fix.
> Is this the "right" fix?  I don't have good documentation on the parallel
> port,
> so I don't know if this makes sense (the one documentation I do have put a
> small spin loop between the assert and de-assert of the strobe line, so I
> figured that maybe a delay in there was a good idea).

I saw this too on the interrupting driver, and found that switching to the
polled driver made the problem go away.  Changing the length of the strobe
didn't appear to help.  Strangely enough the polling driver uses exactly
the same code sequence as the interrupting driver for the actual data
transfer.

According to the manual with my printer, the data strobe is supposed to have
.5us of setup time, .5us of data strobe, and .5us of hold time.  I think that
the driver probably ends up cheating on those numbers on a fast processor,
but adding a delay(1) didn't seem to help.  (On the other hand, it was
recently mentioned that delay() isn't accurate for small values.)  I would
also suspect that it varies with different printers; I vaguely recall that
an older printer of mine required 1us for each of the above times, but I
can't find the manual.  Small fiddly timing details like this are always
a pain in the butt to get right in software (oh, but does this keep the
hardware guys from coming round saying "Hey, I figured out how to save a
GATE:  all you gotta do is have the software..."?  AAAARRRRGHGHGHGHGHGH!).