Hi,
I've been working on fixing this bug, and while it is clear that LCMS
was never written to do this, it can be made to work. I've got a patch
that passes the JCK tests in this area.
While writing jtreg tests for this, though, I've stumbled across
something odd, and I was hoping that someone on this list with more
knowledge about ICC profiles would help me. The ICC specification
(ICC.1:2004-10) states:
"All tagged element data, including the last, shall be padded by no more
than three following pad bytes to reach a 4-byte boundary"
and
"This implies that the length must be a multiple of four"
However, if one looks at GRAY.pf supplied with OpenJDK, it is only 554
bytes long, which is NOT a multiple of four. Dumping the contents of the
file and parsing by hand, I see that the last tagged element data in
this file is (all other data is properly padded):
63 75 72 76 00 00 00 00 00 00 00 01 01 00
This is clearly not padded to a four-byte boundary. Am I
misunderstanding something or is this a known problem? [I have not
investigated the cause of this: it could simply be a bug in the profile
or it could be a more serious LCMS bug with padding the last tagged
element data.]
Keith
