https://bugs.documentfoundation.org/show_bug.cgi?id=151215
--- Comment #20 from Jonathan Clark <[email protected]> --- The current approach handles the trivial Western-only monolingual case well. With a few snags in script assignment for punctuation, it also seems to handle the monolingual non-Western with embedded Latin runs case well. Take Japanese, for instance. Without any input language switch, you can type Latin characters, fullwidth Latin variants, or hiragana/katakana/kanji. It's normal to see runs of "English" in what are factually and conceptually monolingual Japanese Writer documents. Users are trained to expect these runs to be picked up automatically by the word processor, and be formatted using the "English" style and layout algorithm, rather than CJK ones. This is the way things work currently. If this scheme were implemented naively, I would expect Japanese users would have to spend a lot of time selecting text and setting its language to English. That's not ideal. The current partitioning of languages into script families is highly questionable for all of the reasons discussed previously. However, when further designing this change, we should be very careful not to regress the user experience in the handful of situations where it does seem to be working well. (In reply to Mike Kaganski from comment #19) > Look how MS already realized that the font should be bound to a *language*, > and the three "groups" are just a compatibility artifact. That may be too generous. A single font physically can't support all writing systems, so a scheme like this one is your only option if you want to ship document themes that are globally useful. No deeper insights needed; just reality paying a visit. When you start typing in one of these writing systems, Word grabs the font from the list and blithely stuffs it into the font field for one of the three categories, as usual. -- You are receiving this mail because: You are the assignee for the bug.
