The dc-fonts contain in position 23 ("17) an empty character which is coded
in the pk-file as character with width, height, h_offset and v_offset as
zero dots but with the proper tfm_width and horizontal escapment in pixels.

Converting this empty character by the internal `pktopxl' routine for 
downloading the character leads to a character header with the corresponding
printer values, followed by an empty pixel stream, e.g. nothing. Such
a downloaded character will not processed by the printer at all, neglecting
the horizontal escapement for the next character's reference point. 

This strange behaviour is not mentioned in the technical reference manual,
and, since the cm-fonts don't have empty characters, this bug was never
detected before. The solution I have chosen now, converts the empty
character in a nonempty dummy character with width, height and top_offset
of just one dot but the correct horizontal escapement followd by a
pixel pattern of just one white pixel. Such a downloaded character will
be processed as usual, followed by the correct horizontal escapement.

Look at the date in BANNER of `dvihp.c' and `crereshp.c', resp. as of
Oct 18, 1991, to make sure, you have the updated code. I didn't found
this bug not from the dc-font, but in trying to process the chess fonts
from Piet Tutelaers, where the white square is coded as an empty character
with an horizontal escapement and tfm_width corresponding to the square
width. The chosen solution solves the occurence of empty character at all.

				   Helmut Kopka, Oct 18, 1991
