Re: [Lcms-user] cmsBuildTabulatedToneCurve16

[<mar...@li...>]

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 <gr...@ar...> 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
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>