
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--

/* Font Definitions */

@font-face

        {font-family:"Cambria Math";

        panose-1:2 4 5 3 5 4 6 3 2 4;}

@font-face

        {font-family:Calibri;

        panose-1:2 15 5 2 2 2 4 3 2 4;}

/* Style Definitions */

p.MsoNormal, li.MsoNormal, div.MsoNormal

        {margin:0cm;

        font-size:11.0pt;

        font-family:"Calibri",sans-serif;

        mso-fareast-language:EN-US;}

span.EmailStyle17

        {mso-style-type:personal-compose;

        font-family:"Calibri",sans-serif;

        color:windowtext;}

.MsoChpDefault

        {mso-style-type:export-only;

        font-family:"Calibri",sans-serif;

        mso-fareast-language:EN-US;}

@page WordSection1

        {size:612.0pt 792.0pt;

        margin:72.0pt 72.0pt 72.0pt 72.0pt;}

div.WordSection1

        {page:WordSection1;}

--></style><!--[if gte mso 9]><xml>

<o:shapedefaults v:ext="edit" spidmax="1026" />

</xml><![endif]--><!--[if gte mso 9]><xml>

<o:shapelayout v:ext="edit">

<o:idmap v:ext="edit" data="1" />

</o:shapelayout></xml><![endif]--></head><body lang=EN-AU link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>While looking at some NITF test data, I’ve found a problem in how we handle ECS-A (and ECS) characters. BCS-A (essentially ASCII) is fine. However MIL-STD-2500C CN2 allows some header fields to be ECS-A, and the test data does this.<o:p></o:p></p><p class=MsoNormal>I’ve also hit TREs with ľm, where the ľ character is encoded as 0xB5 in ECS-A (UTF-8 would be 0xCE 0xBC) <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’d appreciate some guidance on how to best address this. I can see two options – handle it internal to the NITF driver, or (somehow) modify CPLRecode or iconv to handle this special case. I’m currently planning the former.<o:p></o:p></p><p class=MsoNormal>If something else would be more appropriate, please let me know.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Brad<o:p></o:p></p></div></body></html>