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}"