bug: Han Xin Code uses QR mode functions instead of Han Xin encoding spec

[productdevbook]

Summary

The Han Xin Code encoder in src/encoders/hanxin.ts incorrectly reuses QR Code mode and Reed-Solomon functions instead of implementing the Han Xin-specific encoding required by ISO/IEC 20830.

Details

1. Wrong mode indicators

import { pushBits } from "./qr/mode";
import { generateECCodewords } from "./qr/reed-solomon";

// Mode indicator: 0100 = byte mode  <-- This is QR's byte mode, not Han Xin's
pushBits(bits, 0b0100, 4);

Han Xin Code has its own mode set:

• Numeric mode: 0001
• Text mode: 0010 (Region One + Region Two subsets)
• Binary mode: 0011
• Chinese mode (GB 18030): 0100
• ECI mode: 0111

Using QR's mode indicator 0100 for byte data will be interpreted as Chinese mode by a Han Xin decoder.

2. Missing Chinese (GB 18030) encoding

Han Xin Code's primary advantage is efficient Chinese character encoding using GB 18030. The current code only supports UTF-8 byte mode via TextEncoder.

3. Wrong Reed-Solomon parameters

const ec = generateECCodewords(dataArr, Math.min(ecBytes, 255));

Han Xin uses its own RS configuration with specific GF(256) parameters that differ from QR Code's. The generator polynomial and block structure are different.

4. Capacity calculation is approximate

function hanxinCapacity(version: number): number {
  const totalModules = size * size;
  return Math.floor((totalModules * 0.6) / 8);  // "~60% usable"
}

The spec defines exact capacity tables for each version and EC level. Using 60% approximation will cause version selection errors.

5. Missing alignment patterns

Han Xin Code has alignment patterns at specific positions depending on the version. The current code only places finder patterns and timing patterns.

References

• ISO/IEC 20830:2021 (Han Xin Code bar code symbology specification)
• Han Xin Code overview
• GB/T 21049-2007 (Chinese national standard)

[productdevbook]

Fixed.