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.