Feat: allow custom converter from tag ParseSpecificCharacterSet to encoding names to support non-standard variants #292
Conversation
| for _, opt := range opts { | ||
| opt(&optSet) | ||
| } | ||
| return optSet | ||
| } | ||
|
|
||
| // WithTagSpecificCharacterSetToEncodingNameConverter allows parser to map | ||
| // non-standard character sets with standard ones when assessing encoding names | ||
| func WithTagSpecificCharacterSetToEncodingNameConverter(handler func(string) string) ParseOption { |
There was a problem hiding this comment.
question: can you tell me more about what kind of issues you're seeing in the wild? For example, is it always the case that the character set just need to be mapped to a "known" character set? Wondering if any of the below options might also be reasonable:
- Option to try common substitutions (e.g. replace underscores, etc) to try to map to an internal character set before returning an error.
- If this will always be a direct mapping, should we just take a map? Or will it be the case there might be some more complex logic that requires inspecting the input character set?
Overall though, having a user supplied function to help here could work but just want to understand the realistic space of possibilities. Ultimately allowing folks to register their own charsets could be useful too
There was a problem hiding this comment.
can you tell me more about what kind of issues you're seeing in the wild? For example, is it always the case that the character set just need to be mapped to a "known" character set?
Yes, we got error ParseSpecificCharacterSet: Unknown character set and it didn't process the further (I included this in the description so not sure if it didn't make sense or I don't get this question right)
Option to try common substitutions (e.g. replace underscores, etc) to try to map to an internal character set before returning an error.
when I thought about this approach, of adding option to replace spaces with underscores, I also thought variants may come (like instead of _, it'd be - or . ) and we'd need to deal with them (I predicted, we haven't encountered any other cases rather than this value ISO_2022_IR_6 yet). And for ISO_IR 13 or ISO_IR 110 or the like, replacing may not be ideal
If this will always be a direct mapping, should we just take a map? Or will it be the case there might be some more complex logic that requires inspecting the input character set?
this sounds equivalent for our problem, I was just thinking that function is more flexible, such as:
switch charset {
case x, y, z:
charset = w
case a, b, c:
charset = d
default:
charset = something_else
}
Ultimately allowing folks to register their own charsets could be useful too
charset will eventually go through ParseSpecificCharacterSet to be mapped to available encoding names, so I thought an arbitrary set of charsets wouldn't always be mapped to a working encoding name
|
close this pr as we made a fork and we work on that one for better flexibility |
This PR is a workaround to bypass error
ParseSpecificCharacterSet: Unknown character setwhen we process dicom files having non-standard value for tag SpecificCharacterSet (specificallyISO_2022_IR_6)