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
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Reply via email to