
    Copyright (C) 1996 Aladdin Enterprises.  All rights reserved.
    Unauthorized use, copying, and/or distribution prohibited.

This document presents the results of Aladdin's investigation of
discrepancies between the Genoa LaserJet 5 PCL6 Command-Level Emulation
Test, the published PCL XL Feature Reference Protocol Class 1.1
specification, and the behavior of the H-P LaserJet 6MP printer.

		Report on Genoa LaserJet 5 PCL6 CET and LaserJet 6MP

Introduction
============

In the course of validating our PCL XL interpreter using the Genoa LaserJet
5 PCL6 Command-Level Emulation Test (CET), we observed a number of
discrepancies that, after careful investigation, we concluded were due to
problems in the CET and/or the printer firmware.  In this document, we
present these in detail.

This document should be read in conjunction with our separate report on
discrepancies between the specification and the firmware independent of the
Genoa tests.

Changes in a given revision of this document are marked with the revision
number in [brackets].  Revision history:
		first issued December 12, 1996
		rev. [1] December 13, 1996
		rev. [2] December 19, 1996
		rev. [3] January 1, 1997
		rev. [4] January 17, 1997
		rev. [5] January 29, 1997

Command emulation tests
=======================

c101
----

On the pages that include both a UnitsOfMeasure command setting different
units for the X and Y axes and a PageScale command, text scaling appears to
be affected only by one of these and not the other.  (We didn't analyze the
output carefully enough to determine which one.)  This affects pages 16
through 19 of c101.  This is apparently caused by a LJ5 firmware bug that
has been corrected in the LJ6MP: the 6MP agrees with our reading of the
specification.

This bug affects other tests as well; we have tried to note every instance
of it below.

c102
----

The bug noted under c101 also affects page 4 of c102.

c302
----

The bug noted under c101 also affects pages 3 and 6 of c302.

c306
----

[5] On page 8 of c306, the patterns with an origin of -32767 in X or Y are
apparently incorrect: they appear as though the origin were +32767.

Specifying a NewDestinationSize for a raster pattern in the SetBrushSource
or SetPenSource command apparently changes the destination size permanently,
or at least for a subsequent SetBrush/PenSource command that doesn't specify
a NewDestinationSize.  Page 43 of c306 tests for this explicitly, and the
LJ5 fails the test.  This apparent firmware bug has [not] been fixed in the
LJ6MP.

c307
----

The bug affecting page 43 of c306 also affects page 44 of c307.

[1] c308
--------

[1] The text on page 23 says that "Printing a bitmap font at an angle
produces an error."  However, no error occurs.  By experiment, we have
determined that rotating the *page* causes bitmaps to rotate appropriately,
but setting the character angle, scale, or shear factor to a non-default
value causes an IllegalFontData error.

[2] c319
--------

The "PenWidth_UI = 600" shape on page 37 is actually created from a
lower-case 'e' in the Arial font, so it may appear different depending on
the details of the font and the rasterizer.

[1] c321
--------

[1] It appears that if the current clip mode is even/odd, SetClipIntersect
with an exterior clip region disregards the previous clip path and does the
equivalent of SetClipReplace.  The first, and simplest, example of this is
the upper right figure on page 3: the "intersection" clip region is simply
the exterior of the two lightly-drawn rectangles, with no relationship to
the darker-drawn rectangle which is the original clipping region.  This bug
shows up in the Genoa printouts and has also been observed on the LJ6MP.

[1] This bug also affects many other pages in this test.

[2] c330
--------

On the last page of this test, a partial 'B' should appear in portrait
orientation to the left of the partial 'A'.  The input data read as follows
(slightly abridged):

	0 6600 usp @PageOrigin SetPageOrigin
	90 ss @PageAngle SetPageRotation
	PushGS
	-2300 1900 ssp @PageOrigin SetPageOrigin
	2.23 1.1 rp @PageScale SetPageScale
	(Courier       Bd) ba @FontName 1000 us @CharSize
	  629 us @SymbolSet SetFont
	0 b @NullBrush SetBrushSource
	NewPath
	1500 0 3500 1200 usq @BoundingBox
	2100 0 ssp @StartPoint
	2600 0 ssp @EndPoint
	PiePath PaintPath
	0 b @ClipRegion SetClipReplace
	<79 7b 7d> ba @RGBColor SetBrushSource
	2500 900 ssp @PageOrigin SetPageOrigin
	0 0 usp @Point SetCursor
	-180 ss @PageAngle SetPageRotation
	(A) ba @TextData Text
	SetPageDefaultCTM
	2100 3600 usp @Point SetCursor
	(B) ba @TextData Text

Even when we modified the test data to paint an entire page of 'B' at this
point, no characters appeared.  We assume this results from a firmware bug,
but we have no theories as to its nature.

[4] c333
--------

In the "Effect on CharAngle" and "Effect on CharShear" lines of page 16, the
character appears to be scaled by the page scale before being rotated by the
character angle or sheared, rather than vice versa.  We believe this is a
firmware bug because we verified, by testing all 125 possible sequences of 3
operations chosen from the set {SetCharAngle, SetCharScale, SetCharShear,
SetPageRotation, SetPageScale}, that the character transformations uniformly
occur before the page transformations.

The bug noted under c101 also affects pages 18 through 20 of c333.

Error emulation tests
=====================

[2] e120
--------

The H-P implementation apparently supports only the little-endian binary
binding: [3] an "unavailable binding" error occurs when the file attempts to
start an input stream with big-endian binding.  Furthermore, there is an
apparent data error in the subsequent big-endian data: at byte position 101
in the big-endian section (counting the first byte of PCL XL data after the
stream header as byte 0), the length of the font name "Courier" is
incorrectly coded as (16,0) (little-endian) rather than (0,16) (big-endian).
The resulting 4096-byte count causes the entire remainder of the file to be
interpreted as a data stream; since this exceeds the length of the file, the
test terminates.

		Report on HP-PCL XL 2 0 protocol generated for
		Laserjet 8000 with device reference Color Laserjet
		4600
                ==================================================

C305.BIN page 13.  An undefined error code 0x15 is reported for
operator 20 (SetBrushSource) on the 4600.  The color laserjet
apparently cannot use the referenced pattern.  We print page 13
without an error.


               Report on HP-PCL XL 3.0 4600
               ============================


C318.BIN page 33: On the HP 4600 the 4th patterned box has a filled
black area.  On the artifex interpreter the black area is the same as
the other patterned boxes.  This is certainly a bug in the HP
firmware.  The black area in each patterned box is a rectangle edged
with a dashed line stroke.  The rectangle is then filled with the null
brush which should produce no output.  However for raster operations
0, 17, 68, 85, 136, 153, 204, 221, 250, 255 it appears the null brush
is "locked out" and the previous pattern (in this case the fill for
the patterned box) is used.  We don't think it worthwhile to emulate
this bug.

C420.BIN page 9 and C703 page 1.  Rectangles' color incorrect.  In the
current architecture the result of combining image (source) and
pattern (texture) may not work correctly using the default
"UseCIEColor" mode.  To print these rectangles correctly run the
interpreter with -J"@PJL SET USECIECOLOR=OFF" as a workaround.

C705.BIN page 36. Extra blank page.  We assume this is a bug in the HP
firmware.  In full page passthrough mode the blank page is suppressed,
but extracting the relevant embedded pcl produces a blank page on the
Color Laserjet.

C705.BIN page 19. Passthrough missing wedges.  We think this is a bug
in the Color Laserjet 4600 firmware.  Full page passthrough is used to
send a partially initialized hpgl/2 job to the pcl interpreter.
Without any commands to indicate gl/2 should reset the color space
(IN, DF) gl/2 will use the color space in the graphics state.  In
order to print this job correctly it would be necessary to have
different initialization routines for gl/2 depending on whether it was
invoked from pcl or pclxl.  We do not think this is desirable nor is
it what HP intended.

C705.BIN page 3.  Merge control problem in passthrough mode.  This
problem is a PCL5C problem and is not related to PCLXL.  The HP 4600
produces incorrect results for MC mode 1 for some colors.  Below is a
simple example.  Using the default palette the blue (pen 5 0x0000ff)
is used to fill a simple rectangle.  Pen 6 (magenta 0xff00ff) is used
to paint a box above the blue box.  The default raster operation with
Merge Control 1 is 168 which (after simplification) "and's" the
current paint value with the destination's value.  The predicted paint
value for the second box is 0xff00ff & 0x0000ff = 0x0000ff (blue).
The HP produces magenta and the artifex interpreter the expected blue.

example (quoted printable)

=1BE=1B%1BIN;SP1;PA150,4900;SD3,12;IP150,4900,4075,9750;SC0,100,0,100;P=
A5,90;SP5;MC1;SP5;PA20,25;RA40,45;FT;LT6;SP6;PA23,28;RA37,42=1B%1B=1BE=


