[NTG-context] issue with scite module

Max Chernoff mseven at telus.net
Sat Jun 4 23:18:55 CEST 2022


> Could anyone confirm the issue or explain me what I am missing?

Confirmed on Win64 with the same version.

But I did find a workaround: if I convert your example from NFC 
(composed) to NFD (decomposed), it compiles fine.

     $ xxd xml.tex
     00000000: 5c75 7365 6d6f 6475 6c65 5b73 6369 7465  \usemodule[scite
     00000010: 5d0a 5c73 7461 7274 7465 7874 0a5c 7374  ].\starttext.\st
     00000020: 6172 7458 4d4c 20c3 b15c 7374 6f70 584d  artXML ..\stopXM
     00000030: 4c0a 5c73 746f 7074 6578 740a            L.\stoptext.

     $ context xml
     [...]
     ConTeXt  ver: 2022.05.11 11:36 LMTX  fmt: 2022.6.2
     [...]
     The file ended when scanning an argument.
     [...]
     mtx-context     | fatal error: return code: 1

     $ uconv -x any-nfd xml.tex | sponge xml.tex

     $ xxd xml.tex
     00000000: 5c75 7365 6d6f 6475 6c65 5b73 6369 7465  \usemodule[scite
     00000010: 5d0a 5c73 7461 7274 7465 7874 0a5c 7374  ].\starttext.\st
     00000020: 6172 7458 4d4c 206e cc83 5c73 746f 7058  artXML n..\stopX
     00000030: 4d4c 0a5c 7374 6f70 7465 7874 0a         ML.\stoptext.

     $ context xml
     [success]

This also gives us a hint as to what the problem is:

     $ echo -n 'ñ' | xxd
     00000000: c3b1                                     ..

     $ echo -n 'ñ' | uconv -x any-nfd | xxd
     00000000: 6ecc 83                                  ...

     $ xxd xml.tex
     00000020: 6172 7458 4d4c 20c3 b15c 7374 6f70 584d  artXML ..\stopXM
                                ^^ ^^
     $ xxd xml.log
     00000570: 5c73 6c78 6465 6661 756c 747b c37d 7d5c  \slxdefault{.}}\
                                             ^^

The character "ñ" in UTF-8 NFC is "0xC3, 0xB1". The "0xC3" starts a 
2-byte character, while "0xB1" is a continuation character. In the error 
message from the log, we have "0xC3, 0x7D" which is a 2-byte leading 
byte followed by an ASCII character, which is invalid UTF-8.

I'm guessing that what's happening is the module code is just grabbing 
one character at a time, which works for ASCII, but can lead to orphaned 
characters in Unicode. The NFD form fixes this since the first byte of 
the line is the plain ASCII "n", which can freely be treated as a single 
byte.

This NFD workaround should hopefully "fix" things for basic Latin 
characters with accents, but it probably won't help with non-Latin 
characters since there isn't an ASCII character to decompose them into.

-- Max


More information about the ntg-context mailing list