What a Windows editor saves, and a standard user's Windows install (from dev 9d6f66456a3d)

- CRLF line endings are read as newlines on every system (the reader used
  to delete the pair, collapsing a Notepad++ file into one line on Linux
  and macOS); a leading UTF-8 byte-order mark is ignored; a UTF-16 or
  Windows-1252 source is refused with the encoding, the place and the
  remedy named. .gitattributes pins LF in every clone.
- Windows source install: the repository path must hold no space (GNU
  Make), accented letters are fine (every linker input is relative now);
  python.org's Python is selected ahead of an MSYS2 one that poppler pulls
  in; TeX Live goes to its Windows default C:\texlive\2026.
- The Python binding needs an ASCII installation path on Windows, and its
  suite says so there.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

tst/filename_test.sh

@@ -36,6 +36,10 @@ mkdir "$DIR/my dir"
 printf 'ALPHA\n' > "$DIR/my file.kt"
 printf 'BETA\n'  > "$DIR/b.kt"
 printf 'GAMMA\n' > "$DIR/my dir/c.kt"
+printf '\357\273\277DELTA\n' > "$DIR/bom.kt"     # a UTF-8 byte-order mark, then the text
+printf 'EPSILON\r\nZETA\r\n' > "$DIR/crlf.kt"      # Windows line endings
+printf '\377\376h\000i\000\n\000' > "$DIR/utf16.kt"    # UTF-16LE with its byte-order mark
+printf 'ETA\nTHETA M\374ller\n' > "$DIR/cp1252.kt"   # Windows-1252: an umlaut that is not UTF-8
 cd "$DIR" || exit 1
 
 # check TEST_NAME EXPECTED_STDOUT EXPECTED_STDERR_SUBSTRING KTEXT_ARGS...
@@ -151,6 +155,37 @@ check_error "8. unrescuable name is reported as written" \
       "no such.kt" \
       "no such.kt" -d --klammersets none
 
+# A leading UTF-8 byte-order mark is ignored (2026-09-26): Windows tools write
+# one, and it was reported as "Word not parsed" at 1:1 with an invisible word.
+check "9. a leading UTF-8 BOM in the input file is ignored" \
+      "DELTA" "" \
+      bom.kt -d --klammersets none
+
+check "10. a leading UTF-8 BOM in a @read file is ignored" \
+      "DELTA" "" \
+      -s '@read bom.kt @' -d --klammersets none
+
+# Windows line endings are newlines (2026-09-26): the reader DELETED the pair,
+# so on Linux and macOS a CRLF file collapsed into one line.
+check "11. CRLF line endings are read as newlines" \
+      $'EPSILON\nZETA' "" \
+      crlf.kt -d --klammersets none
+
+# What a Windows editor can also save (2026-09-26): a UTF-16 file and an
+# ANSI (Windows-1252) file are named as such, with the remedy, instead of
+# "Word not parsed" or a failure inside the embedded Python.
+check_error "12. a UTF-16 file is named as such" \
+      "UTF-16" \
+      utf16.kt -d --klammersets none
+
+check_error "13. a Windows-1252 file is located at its first non-UTF-8 byte" \
+      "line 2, character 8" \
+      cp1252.kt -d --klammersets none
+
+check_error "14. ... through @read as well" \
+      "not UTF-8" \
+      -s '@read cp1252.kt @' -d --klammersets none
+
 echo
 echo "======================="
 echo "Results: ${green}$PASS passed${reset}, ${red}$FAIL failed${reset}"

tst/kpy_test.sh

@@ -49,6 +49,19 @@ trap 'rm -rf "$OUTF" "$ERRF" "$WORK"' EXIT
 if command -v cygpath >/dev/null 2>&1; then sep=';'; else sep=':'; fi
 export PYTHONPATH="$K/kpy${PYTHONPATH:+$sep$PYTHONPATH}"
 
+# On Windows the binding cannot load under a KLAMMERTEXT_HOME that holds a
+# non-ASCII character: inside python.exe, a process without Klammertext's
+# UTF-8 manifest, the narrow getenv() is the ANSI code page, and the engine
+# takes every path as UTF-8.  A documented limitation, not a defect to fix
+# (TODO 70 (f), Andy 2026-09-26): the binding needs an ASCII installation
+# path there.  Say so and skip, rather than fail every case with a decode
+# error that names no cause.
+if command -v cygpath >/dev/null 2>&1 && LC_ALL=C grep -q '[^ -~]' <<<"$K"; then
+    echo "SKIP kpy_test: KLAMMERTEXT_HOME ($K) holds a non-ASCII character, and the Python binding needs an ASCII installation path on Windows (TODO 70 (f))"
+    echo "Passed: 0, Failed: 0"
+    exit 0
+fi
+
 # A DEBUG=1 build instruments the module with AddressSanitizer, and an
 # instrumented extension imported into an uninstrumented python needs the
 # ASan runtime loaded FIRST -- the import otherwise fails with "ASan runtime