Hi Jörg, On Mon, May 17, 2021 at 3:49 PM Jörg Riesmeier <[email protected]> wrote: > > > 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).
Thanks for the clarification ! I've removed explicit usage of ICU, since support will be equivalent when using stdlibc (iconv), with the added bonus that we remove a dependency to ICU. https://salsa.debian.org/med-team/dcmtk/-/commit/666129093bee6d907ef763324835209e4416ff10 and documentation has been added for Debian users: https://salsa.debian.org/med-team/dcmtk/-/commit/a533a4acb57242e8c9e9f011e3ba083c8382da97 -M
