Hi Graeme, In my implementation the count is canonical and then the ascii string (or unicode) may contain trailing zeros for alignment. This particular case of double terminator is indeed a bug in my side, although I've seen other profiles using padding as well. I will remove the padding in next release in order to make CMMs to agree.
Regards Marti. Graeme Gill <gra...@argyllcms.com> escribió: > Marti Maria wrote: > >> Humm... A binary dump of the profile you are attaching shows no script >> code but only correct unicode data, and both 'desc' tags are similar. >> Any other software complaining? >> Regards >> Marti >> >>> tag 0: >>> sig 'desc' >>> type 'desc' >>> offset 264 >>> size 116 >>> TextDescription: >>> ASCII data, length 8 chars: >>> 0x0000: sRGB\000\000\000 >>> No Unicode data >>> ScriptCode Data, Code 0x0, length 9 chars >>> 0x0000: 00 73 00 52 00 47 00 42 00 > >> From 6.5.17: > > 01f0: 00 00 00 00 00 00 00 00 00 00 00 00 64 65 73 63 ............desc > ^^^^^^^^^^^ type signature. > > 0200: 00 00 00 00 00 00 00 08 73 52 47 42 00 00 00 00 ........sRGB.... > ^^^^^^^^^^^ reserved > ^^^^^^^^^^^ Ascii count > ^^^^^^^^^^^^^^^^^^^^^^^ 8 bytes of Ascii > > 0210: 00 00 00 00 00 00 00 09 00 73 00 52 00 47 00 42 .........s.R.G.B > ^^^^^^^^^^^ Unicode language code > ^^^^^^^^^^^ Unicode description count (chars) > ^^^^^^^^^^^^^^^^^^^^^^^ > 0220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > There's a couple of things going on here. > One is that this tag isn't conformant to the specifications: > > "The count field for each types are defined as follows: > ASCII: The count is the length of the string in bytes including the > null terminator. > Unicode: The count is the number of characters including a Unicode > null where a > character is always two bytes." > > This is not the case with this tag. The count is longer than the strings for > both strings. This is revealing a "bug" in icclib - it is taking the lengths > of the strings as canonical, instead of the count field. Since the > specification > says that the length of the string and the count should be the same, it > has no guidance as to which takes priority if they disagree. I'll > fix the next release of icclib to take the count as canonical (since I guess > this is likely to be the case), and to emit an error if it is compiled > with "STRICT" turned on. > > Graeme Gill. > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Lcms-user mailing list > Lcms-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lcms-user > ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
