Bridge bug: MIF filter does not expose <Char Tab> as inline text

[asgeirf]

Surfaced by the spec contract audit (spec/mif).

Symptom

The Okapi MIFFilter does not expose the inline <Char Tab> statement as a literal tab character (\t, U+0009) in the extracted text. Native core/formats/mif/ decodes <Char Tab> to a literal \t inside the surrounding paragraph (matching the Adobe MIF Reference contract that <Char Tab> represents an inline tab character). The bridge-extracted block text omits the tab — the two <String> runs flanking the <Char Tab> come through joined without any separator, so a downstream has_block_with_text: ["\t"] assertion fails on the bridge side.

The same divergence likely applies to the other inline <Char …> variants the spec covers under special_char_statements: HardSpace (U+00A0), SoftHyphen (U+00AD), EnSpace (U+2002), EmSpace (U+2003), ThinSpace (U+2009). The current example only exercises Tab — additional examples can be added once this is resolved upstream.

Reproduction

core/formats/mif/spec.yaml feature special_char_statements::tab_between_strings:

input MIF:
  <Para
   <PgfTag `Body'>
   <ParaLine
    <String `Before tab'>
    <Char Tab>
    <String `after tab.'>
   >
  >

native:  block contains "Before tab", "\t", "after tab."  (correct per MIF Reference)
bridge:  block contains "Before tab", "after tab."        (tab character missing)

Spec tags

The example is tagged expected_fail: in core/formats/mif/spec.yaml so the parity gate downgrades it to a warning until the bridge is fixed (or until we agree the bridge's placeholder representation is intentional and adjust the spec assertion accordingly). Once the bridge fix lands, drop the expected_fail: block.

Repro test

KAPI_PARITY_SANDBOX=$PWD/.parity \
  go test -tags parity -run TestParityMifSpec -count=1 -v ./parity/...

(from cli/, on branch spec/mif)

Affected upstream code

okf_mif Java filter — net.sf.okapi.filters.mif.MIFFilter (Okapi 1.47.0 / 1.48.0). Likely in the <Char …> statement handler that converts the structural character into a TextFragment / inline code — the inline placeholder is not being re-expanded to its Unicode equivalent in the source string.

[asgeirf]

Moved from neokapi/neokapi#509

Transferred during tracker housekeeping. The defect stays open here rather than being closed: okapi-bridge continues as a standalone product — the reference implementation of a third-party kapi plugin in a non-Go language (neokapi/neokapi#1073) — so a divergence in the okf_mif filter remains actionable independently of what neokapi ships natively.

What changed on the neokapi side

neokapi/neokapi#1079 removed the native mif format package. The reproduction path recorded in the body above therefore no longer resolves:

• core/formats/mif/spec.yaml (and its expected_fail: tag) was deleted with the package
• TestParityMifSpec and the spec/mif branch no longer exist
• the related native-parity issue, Native parity: mif — spec-first; FrameMaker MIF format reader/writer audit neokapi#558, was closed as moot

The report itself is unaffected. Input, the expected reading per the Adobe MIF Reference (<Char Tab> denotes an inline tab character), and the observed filter output all stand on their own.

Reproducing here

Exercise net.sf.okapi.filters.mif.MIFFilter directly from this repository's test suite with the <Para>/<ParaLine> input recorded above, asserting that the extracted text contains U+0009 between the two <String> runs. The <Char …> variants named above (HardSpace, SoftHyphen, EnSpace, EmSpace, ThinSpace) are worth covering in the same test.