I had switched it ages ago to access the JIS X 0208 mappings in both directions for ISO-2022-JP as a wrapper around the EUC-JP mappings (clearing the high bits and constraining the lead bytes), to avoid using up disk footprint with an essentially redundant set of tables. I didn't quite realise that this meant its encoder half was no longer using the WHATWG-specified index iso-2022-jp-katakana one-way mappings for the halfwidth katakana to their fullwidth counterparts.
I had switched it ages ago to access the JIS X 0208 mappings in both directions for ISO-2022-JP as a wrapper around the EUC-JP mappings (clearing the high bits and constraining the lead bytes), to avoid using up disk footprint with an essentially redundant set of tables. I didn't quite realise that this meant its encoder half was no longer using the WHATWG-specified
index iso-2022-jp-katakanaone-way mappings for the halfwidth katakana to their fullwidth counterparts.This alters
gen_dbdata.krkagain to fix that.