I believe this is the last "issue" which would make the bunch of PCL5 files I just collected from various HP drivers work. The Bug 694989 - "ESC * g <nbytes> W" unimplemented - actually replaces the functions of the 3: "ESC * r # U" - Simple Color Mode "ESC * t # R" - Raster Graphics Resolution "ESC * v # W" - Configure Image Data Primarily because those aren't really good beyond K, CMY and RGB. There are 4 which does not work currently (note the last one was already mentioned in Bug 694082): - KCMY, 4 x 1 bit plane - KCMY, 1-bit k plane + 3 x 2-bit CMY planes - KCMY, 1-bit k plane + 3 x 2-bit CMY planes at 1/2 resolution of the k plane - K+RGB 1 bit k plane + 24-bit RGB plane The first one is probably easy to add, the last one is sort of the important one as newer printers use it.
This blocks bug 694082 .
Without test files I can't tell but this is probably resolved, at least as far as I plan on taking these issues for now, with the fix in bug #694082. So I'm closing this bug.
I would probably say this is a duplicate of bug 694989 - newer inkjects use some very strange colour models, and have a "super" instruction which replaces 3 of the older simple ones. Instead of simple cmyk 1bit, they have some thing like 1-bit k + 24-bit RGB, or 1-bit k plus 2-bit CMY. I have/had some test files, it is just that they are a lot more complicated than the one in 694082 or so no point in posting them if the simple one hasn't made any progress. I'll see if I can find them / re-make them.
Created attachment 24358 [details] deskjet 9xx test file Apparently this is a 1-bit K + 2-bit CMY file. On git head-ish, it shows the K plane stretched. On my misc-wip repo, it shows the K plane correctly but without the colour.
Dug up old files (apparently I just put them aside, waiting for the simplier bug 694082 and bug 694989 to get any further). Re-opening.
Created attachment 24359 [details] Deskjet 850 testfile This is apparently also 1-bit K + 2-bit CMY. It differs from the 9xx test file in that the 9xx test file the resolutions of all the planes are the same. In this file DJ850, the CMY planes have higher depth but half the resolution than the K-plane. HEAD renders this stretched horizontally 4x(?) and vertically 2x, I think? My WIP repo seems to be doing just the k-plane at 2x2 - ie. I see the b/w tiger at 2x2 .
(In reply to Hin-Tak Leung from comment #5) > Dug up old files (apparently I just put them aside, waiting for the simplier > bug 694082 and bug 694989 to get any further). Re-opening. I'm not planning to take this bug any further. Closing again. Still waiting for an email from you Hin-Tak, regarding bounties. See bug 694082, comment #15. You replied that you had fulfilled a CLA, but not the other part of the question.
Created attachment 24360 [details] Deskjet 9xxVIP testfile This is apparently for DJ9xxVIP . It seems to be 1-bit K + 32-bit RGB (24-bit + 8-bit nothing?). It is also almost identical to attachment 9724 [details] in in bug 694082 (and bug 694989). I think I didn't post any test file for this bug, but filed bug 694989 against bug 694082 because variation of the 1-bit K + 32-bit RGB (24-bit + 8-bit nothing?) is quite popular among a few models, so there are variants with small changes like this file compared to attachment 9724 [details] . (differs by only two bytes - haven't looked which those two bytes are). HEAD segfaults with the bits > 3 (and "works" for bits >2); my WIP does a "interpreter exited with error code -15 ... Flushing to end of job".
Created attachment 24361 [details] OJProKx50 testfile This is apparently also a 1-bit K + 32-bit RGB ; just with some model-specific variations.
Created attachment 24362 [details] Deskjet 6xx file This is apparently the 1 bit KCMY case. git head seems to be doing Nx2 (stretched sideways and also vertically). My WIP seems to be doing 2x2 just the black plane.
Created attachment 24363 [details] deskjet 350 test file Deskjet 350 test file. This is apparently 1bit CMY (not K). HEAD is doing b/w Nx2 . My WIP seems to be correct except at 2x2.
Hin-Tak, While, attempting to wrap my head around how "Configure Raster Data" (CRD) works, I think I figured out why the sizing is wrong. Reading HP's documentation, you can switch output resolution "per plane". So you can print the K plane at 600dpi, while each color plane would be at 300dpi. GhostPCL would have to switch resolutions on the fly. It would also have to keep track of where it is processing the CRD statement. Basically CRD does the following: -Specify the number of color pens. (sets the palette size) -Specify which color pens to use. (sets a custom palette) Then for each pen: -Specify plane or pixel major. -Specify the resolution. -Specify the intensity levels. -Specify the compression mode. Some of the above varies by printer and "format number". Supporting CRD completely would be a pretty hefty undertaking and documentation appears to be limited, particularly for for exotic printers like the 8+-color DesignJets. Personally I would focus on whatever subset PCL3GUI drivers use as this appears to be the most common "variant" and is documented in the hpijs source.