iccToXml emits ISO-8859-1 bytes (0xB0) in XML

[xsscx]

Maintainer Repro

Wed Dec 31 09:47:51 PM UTC 2025

tl;dr iccToXml created XML 1.0 document, ISO-8859 text, with CRLF, LF line terminators

grep -n --text "ObserverAngle" ub-icDataBlockType-IccTagBasic_h-L1299.xml | xxd -g1
00000000: 31 35 33 37 3a 4d 45 41 53 55 52 45 4d 45 4e 54  1537:MEASUREMENT
00000010: 5f 53 4f 55 52 43 45 09 22 49 6c 6c 75 6d 69 6e  _SOURCE."Illumin
00000020: 61 74 69 6f 6e 3d 44 35 30 09 4f 62 73 65 72 76  ation=D50.Observ
00000030: 65 72 41 6e 67 6c 65 3d 32 b0 09 57 68 69 74 65  erAngle=2..White
00000040: 42 61 73 65 3d 41 62 73 09 46 69 6c 74 65 72 3d  Base=Abs.Filter=
00000050: 4e 6f 22 0d 0a                                   No"..

Summary

The output from iccToXml contains byte 0xB0 (ISO-8859-1 degree sign) where UTF-8 requires 0xC2 0xB0, making the XML invalid despite declaring encoding="UTF-8".

Step 1. Get PoC

cd Testing
wget https://github.com/xsscx/Commodity-Injection-Signatures/raw/refs/heads/master/graphics/icc/ub-icDataBlockType-IccTagBasic_h-L1299.icc

Step 2. file ub-icDataBlockType-IccTagBasic_h-L1299.icc

Expected Output of file command

ub-icDataBlockType-IccTagBasic_h-L1299.icc: Microsoft color profile 2.4, type APPL, CMYK/Lab-prtr device by LOGO, 2638280 bytes, 16-5-2006 13:56:05 "Xeikon FA Uncoated 320%"

Step 3. iccToXml ub-icDataBlockType-IccTagBasic_h-L1299.icc ub-icDataBlockType-IccTagBasic_h-L1299.xml

Unexpected Output for icc -> xml

IccProfLib/IccTagBasic.h:1299:45: runtime error: load of value 16777216, which is not a valid value for type 'icDataBlockType'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior IccProfLib/IccTagBasic.h:1299:45
IccXML/IccLibXML/IccTagXml.cpp:1730:7: runtime error: load of value 16777216, which is not a valid value for type 'icDataBlockType'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior Testing/tmp/iccDEV/IccXML/IccLibXML/IccTagXml.cpp:1730:7
XML successfully created

Step 4. file ub-icDataBlockType-IccTagBasic_h-L1299.xml

Unexpected Output of file command

ub-icDataBlockType-IccTagBasic_h-L1299.xml: XML 1.0 document, ISO-8859 text, with CRLF, LF line terminators

Create ICC Profile from XML

Step 5. iccFromXml ub-icDataBlockType-IccTagBasic_h-L1299.xml ub-icDataBlockType-IccTagBasic_h-L1299-from-xml.icc

Unexpected Output from iccFromXml

ub-icDataBlockType-IccTagBasic_h-L1299.xml:1537: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0xB0 0x09 0x57 0x68
MEASUREMENT_SOURCE      "Illumination=D50       ObserverAngle=2�        WhiteBase=Abs   Filter=No"
                                                               ^
Unable to Parse 'ub-icDataBlockType-IccTagBasic_h-L1299.xml'

Expected Output

• Proper UTF-8

Output from iccToXml

ub-icDataBlockType-IccTagBasic_h-L129901.xml

[ChrisCoxArt]

iccTagXML.cpp
icXmlDumpTextData()
bConvert = true
calls icAnsiToUtf8() ... which is a noop on everything but Windows.

There is a similar call icUtf8ToAnsi() which is also a noop on everything but Windows.

And the text data in question appears to be Windows codepage text.

[xsscx]

... iccToXml emits {insert any char set} in XML ...

[ChrisCoxArt]

Also seeing the CRLF line endings (0D0A), copied as-is from the original tag.
CRLF is easy enough to filter.
But since we don't know the codepage that the text tag was created with, we can't exactly reproduce the text in XML.
Code exists to "guess" a codepage based on the text - but it's messy, and near impossible to be complete, or test properly.
We can convert illegal UTF8 characters to a replacement (\uFFFD), which would work most of the time.
OR, we can detect illegal UTF8 and force the tag to dump as hexidecimal data - which renders it non-human readable, but preserves the data for vendor defined tags.

[ChrisCoxArt]

@maxderhak - need your input here.
I don't think there is a perfect answer for this case (see possibilities above).
We need to decide if it is best for the XML text to preserve human readability, or binary compatibility with third party software.

[maxderhak]

My desire would be that doing an iccToXML followed by an iccFromXML would result in the contents of text tags to be unchanged. Additionally, being able to preserve human readability is desirable.

The key is ensuring that we only have valid utf8 charactes in the generated XML. Perhaps we could utilize additional magic sequences to allow the non-utf8 charactes to be included using something like <[(< xxyyzz >)]> where xx yy and zz are 2 digit hex characters. For example the B0 character in the source data would be output as <[(< b0 >)]>.

If the source data text has the string "<[(<" in it then it would be encoded as <[(<3c5b283c>)]>.

When parsing in iccFromXML we would need to seek for and replace the magic sequence non-utf8 characters as needed. This mostly preservers readability and allows for the round trip data to be preserved while ensuring that characters encoded by iccToXML are valid utf8.

Thoughts?

[ChrisCoxArt]

So the priority is binary compatibility, with readability second.

There are already a few functions that check for valid UTF-8 data, we just need additional logic for CRLF and XML syntax filtering.
Trying to embed magic sequences and decode them correctly later is possible, but messy - especially when we need to remove XML from the text (Gretag), CRLF, and high ascii characters. Magic sequences would only be compatible with our own software, of course, and could not be easily decoded by other software.
Converting any text block containing invalid characters to hex is easiest and most reliable, is compatible with other software, but sacrifices readability more often.
I'll try to estimate what an escape/magic sequence would entail.

[ChrisCoxArt]

XML spec says that CR and CRLF are legal inside a CDATA block, along with other control characters.
And we do preserve them inside CDATA.
All other tag characters are valid inside CDATA except the CDEND string "]]>".
https://www.w3.org/TR/xml11/#sec-cdata-sect

And another part of the W3C XML spec says that CR is illegal and will get normalized to LF on XML parsing.... Sigh.

[ChrisCoxArt]

And we have more problems trying to round trip this profile....