The characters "o" are printed as garbages when
printing the attached sheet. From our investigation,
this may be caused by a bug of gs_image_next_planes()
in Ghostscript. This problem is confirmed to be
happened with NPDL driver. Canon's LIPS IV driver does
not cause this problem, although there is a fishy
transaction between gs_image_next_planes() and
TransferDrawImage().
Here is the detail investigation report:
1. Phenomenon
When printing Linux_2.6_Kernel.ps (attached),
characters "o" are printed as garbages. Confirmed with
NPDL driver.
2. Data pipeline between Ghostscript (GS) and driver
In case of printing "o" in above case, calling sequence
from GS to Glue Code to driver is as follow;
3. Investigation Result (so far)
There is a processing to compare transfered number of
lines with the total number of lines of image data in
opvp_image_plane_data() (the caller of
TransferDrawImage() in Glue Code), which is called
after sending image data to the driver.
The data "o" has total 56 lines and the number of lines
to be sent at first time is set to 55. This number is
set by data given by ghostscript. Therefore, 1 line is
remained to be sent after the 1st transfer, error value
(0) is returned to gs_image_next_planes() of GS, then
Glue Code prepares to send remaining data. However,
remaining data count managed in gs_image_next_planes()
becomes "0" for some unknown reason. As a result, it
thinks no more data is remained, no data transfer
happens, an error value (0) is returned to
image_proc_continue() of GS, which is the caller of
gs_image_next_planes(). After that, same data for "o"
is processed to be sent again. This caused the driver
to receive data for "o" twice, aligning vertically.
The information sent to driver for this bitmap is width
and height for single "o", and bitmap alignment is
calculated from width, height and data count for double
"o", which causes the garbage printout.
For Canon's driver, same processing seems to be
happened, but the printout has no problem. This is
guessed the calculation of alignment is different or
something.
printing the attached sheet. From our investigation,
this may be caused by a bug of gs_image_next_planes()
in Ghostscript. This problem is confirmed to be
happened with NPDL driver. Canon's LIPS IV driver does
not cause this problem, although there is a fishy
transaction between gs_image_next_planes() and
TransferDrawImage().
Here is the detail investigation report:
1. Phenomenon
When printing Linux_2.6_Kernel.ps (attached),
characters "o" are printed as garbages. Confirmed with
NPDL driver.
2. Data pipeline between Ghostscript (GS) and driver
In case of printing "o" in above case, calling sequence
from GS to Glue Code to driver is as follow;
image_proc_continue() : GS
-> gs_image_next_planes(): GS
-> opvp_begin_image(): Glue Code
-> StartDrawImage(): Driver
-> opvp_image_plane_data(): Glue Code
-> TransferDrawImage(): Driver
-> EndDrawImage(): Driver
3. Investigation Result (so far)
There is a processing to compare transfered number of
lines with the total number of lines of image data in
opvp_image_plane_data() (the caller of
TransferDrawImage() in Glue Code), which is called
after sending image data to the driver.
The data "o" has total 56 lines and the number of lines
to be sent at first time is set to 55. This number is
set by data given by ghostscript. Therefore, 1 line is
remained to be sent after the 1st transfer, error value
(0) is returned to gs_image_next_planes() of GS, then
Glue Code prepares to send remaining data. However,
remaining data count managed in gs_image_next_planes()
becomes "0" for some unknown reason. As a result, it
thinks no more data is remained, no data transfer
happens, an error value (0) is returned to
image_proc_continue() of GS, which is the caller of
gs_image_next_planes(). After that, same data for "o"
is processed to be sent again. This caused the driver
to receive data for "o" twice, aligning vertically.
The information sent to driver for this bitmap is width
and height for single "o", and bitmap alignment is
calculated from width, height and data count for double
"o", which causes the garbage printout.
For Canon's driver, same processing seems to be
happened, but the printout has no problem. This is
guessed the calculation of alignment is different or
something.