https://bugs.documentfoundation.org/show_bug.cgi?id=172947
--- Comment #2 from Ótzï fón GlüϷgor <[email protected]> --- (In reply to Robert Großkopf from comment #1) > Tested this one: > "Straße" and then set as capital letters for text. Will work and show the > capital Sharp-S. > Then written directly with capital letters (U+1E9E for capital Sharp-S). > Will be shown as incorrect. > Then copied ß from the first "Straße" to the second "STRAßE". Will be shown > as correct. > > Don't know why there is a difference. > > I would set this one to NEW Thanks for confirming, Robert. Both of your observations have the same cause, and it sits in the hunspell library rather than in LibreOffice or in the dictionary. ### Why the cases differ Up to and including hunspell 1.7.3, U+1E9E is classified as a non-letter with no case mapping, in `src/hunspell/utf_info.hxx`: ``` /* 0x00df */ { true, 0x00df, 0x00df }, <- ß /* 0x1e9e */ { false, 0x1e9e, 0x1e9e }, <- ẞ ``` The all-caps code path therefore never folds ẞ back to ß, and the word is rejected. `CHECKSHARPS` in the German affix file does not help, because its logic only looks for the literal sequence `SS`. That is also why your third case passes: a real lowercase ß between capitals is exactly what `CHECKSHARPS` together with `KEEPCASE` was designed to accept, so `STRAßE` is considered correct even though it is not a sanctioned spelling. Your first case is most likely not a real case conversion. If you applied the character effect (Format ▸ Character ▸ Effects ▸ Case ▸ UPPERCASE), the stored text is still `Straße`, and that is what the spell checker receives — only the rendering is uppercase. You can check by pasting the word into a plain text editor: if it comes back lowercase, it was display only. ### Verified outside LibreOffice hunspell 1.7.2 with the unmodified German dictionary reproduces the exact suggestion list from the spelling dialog: ``` $ echo 'STRAẞE' | hunspell -i UTF-8 -d de_DE -a & STRAẞE 3 0: STRAFE, STRASSE, STRAßE ``` Built from hunspell master, that same unmodified dictionary accepts `STRAẞE`, `GROẞ`, `MAẞE`, `FUẞBALL`, `WEIẞ` and `GROẞMANN`, and still rejects the mixed-case `Straẞe`. No dictionary change is required. ### Upstream status master corrected the table in 4ad885b / 5aef308 (2026-05-05, part of a Unicode 16.0 refresh). v1.7.3 was tagged one day earlier, deliberately, so that the accumulated changes and the table refresh would not ship together — with the result that no release carries the fix. I raised this as hunspell/hunspell#1139; a regression test covering U+1E9E was merged as hunspell/hunspell#1142, and the maintainer expects a new release reasonably soon. For LibreOffice this means `download.lst` pins `hunspell-1.7.3.tar.gz` and the bundled copy needs updating once upstream releases. Linux builds using `--with-system-hunspell` additionally depend on the distributions; Ubuntu 26.04 still ships `hunspell 1.7.2+really1.7.2-11`, which is what I reproduced this on. ### A second, independent defect The German dictionary bundled in the `dictionaries` repository, `de/de_DE_frami.aff` and `.dic`, is still encoded in ISO-8859-1 (`SET ISO8859-1`). U+1E9E cannot be represented in that encoding at all, so even a fixed hunspell fails: ``` $ hunspell -i UTF-8 -d ./de_DE_frami -l # input: STRAẞE, hunspell built from master error - iconv: UTF-8 -> ISO8859-1 STRAẞE ``` This does not affect the reproduction above, which uses the distribution's igerman98-based dictionary — that one is already UTF-8 and works as soon as the library is fixed. It does affect Windows and macOS, where the bundled frami files are used. Converting `de_DE_frami`, `de_AT_frami` and `de_CH_frami` to UTF-8 is therefore needed in addition to the hunspell update, and adding ẞ to `WORDCHARS` and `TRY` would round it off. I will file that as a separate bug unless there are objections: it needs a different fix in a different repository, and this bug will presumably be closed by the hunspell version bump. I have also written to the frami maintainer. -- You are receiving this mail because: You are the assignee for the bug.
