[Debian-med-packaging] Bug#988644: Defined Term: ISO 2022 IR 87 is not supported

[Jörg Riesmeier]

> Could you please clarify the following statement then:
> 
> [...]
> As far as I understand it ISO 2022 JP is also a set containing
> multiple character sets that can be switched via escape sequences. The
> ICU handles these escape sequences internally whereas the libiconv
> doesn't. This is why the existing code in DCMTK that was orignally
> written for libiconv parses these escape sequences itself, therefore,
> the ICU does not perceive them and cannot chose the correct character
> set. The only way to fix this would be to disable parsing the escape
> sequences when the ICU is used and then set all character sets similar
> to your proposition.
> [...]

I personally implemented support for the character set conversion based on 
libiconv into the DCMTK. So, the original implementation of the OFCharacterSet 
and DcmSpecifificCharacterSet classes were designed in a way that allowed for 
using libiconv for the various (i.e. all) specific character sets defined in the 
DICOM standard, i.e. including ISO 2022 switching of character sets.

The ICU and stdlibc (iconv) support was added later by a colleague from the 
OFFIS institute based on this original implementation but, unfortunately, 
without adapting the parsing approach (e.g. searching for the escape sequences 
used for ISO 2022), so that when ICU support is enabled all DICOM character 
sets can be used in the same manner as before (also see comments in the 
respective DCMTK class).