Hi Brad,
yes you're right. A 19-year old bug now gone in
https://github.com/OSGeo/gdal/pull/13450. Perhaps the erroneous addition
of the NUL byte was to imitate oldish Kakadu version since the jpylyzer
manual mentions that about their 'nullbyte' option?
Even
Le 20/11/2025 à 01:56, Brad Hards via gdal-dev a écrit :
It looks like there is a trailing null in the character data written
inside the XML box in JPEG 2000 (only tested with OpenJPEG).
I'm seeing a validation error in jpylyzer about not well formed XML,
which I think is probably related to this. Or at least goes away with
this change:
*diff --git a/gcore/gdaljp2metadata.cpp b/gcore/gdaljp2metadata.cpp*
*index 439b7e6625..a247cad9f8 100644*
*--- a/gcore/gdaljp2metadata.cpp*
*+++ b/gcore/gdaljp2metadata.cpp*
@@ -3333,7 +3333,7
@@GDALJP2Metadata::CreateGDALMultiDomainMetadataXMLBox(GDALDataset
*poSrcDS,
GDALJP2Box *poBox = new GDALJP2Box();
poBox->SetType("xml "); -
poBox->SetWritableData(static_cast<int>(strlen(pszXML) + 1),
+ poBox->SetWritableData(static_cast<int>(strlen(pszXML)),
reinterpret_cast<const GByte *>(pszXML));
CPLFree(pszXML);
However that +1 looks deliberate. So is that trailing null
intentional, in that its required for some interoperability or
backwards compatibility reason, even though it isn't strictly allowed
in XML?
Brad
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
