At the moment, when we use the Special Characters dialog, we choose a specific font, and a character from that font. In one sense, this is unavoidable - as one can't insert a character abstractly, and not all fonts have glyphs for all characters. In another sense, however, this is wrong: A character is not a specific font's glyph for that character. Fixing a specific font for the inserted character is DF, direct formatting - and it currently cannot (?) be avoided. This kind of DF makes our documents brittle and easy to break: When one changes the font in the text's style, the special character will not change along with the style. (There is also the question of text following the special character which I will open a second bug about). This can be ameliorated manually, by selecting the inserted special character and choosing to clear direct formatting; but the user should really not have to do this. It should, in fact, be the default action to insert a character with no DF. The dialog currently doesn't offer an option to do this. It should. This could be: * A checkbox which grays out the font selection * A default entry in the font selection drop down which is a non-font, e.g. "(normal text)" or "(no font specified)". I believe that's what MS Office uses. The problem is compounded with the most-recent-symbols available in the menu-bar on the Format toolbar: One can't even know which font is used for those characters. That should be rectified in one of the following ways: * Only keep non-DF-ed characters in the most-recently-used slots * Indicate slots which override the font, e.g. with some kind of background color or hatching, and also with tooltip text when hovering.
Some feedback at bug 139359
I don't see why we need to discuss this in an extra ticket. While unnecessary DF should be avoided, the few attributes wont break many documents and don't outweigh a more complex and cluttered UI.
(In reply to Heiko Tietze from comment #2) > I don't see why we need to discuss this in an extra ticket. > > While unnecessary DF should be avoided, the few attributes wont break many > documents and don't outweigh a more complex and cluttered UI. This is a different request. I'm suggesting we _explicitly_ distinguish between forced font family and non-forced; bug 139359 suggests inserting the minimum necessary, with some suggesting it _implicitly_ insert none.
(In reply to Eyal Rozenberg from comment #3) > I'm suggesting we _explicitly_ distinguish between forced font family > and non-forced; bug 139359 suggests inserting the minimum necessary, > with some suggesting it _implicitly_ insert none. Cannot follow why we need to force DF beyond the needed amount. And as commented before in c2 I'm against more options in the dialog.
(In reply to Heiko Tietze from comment #4) > Cannot follow why we need to force DF beyond the needed amount. I believe you've misunderstood me. The needed amount is no forcing at all. Forcing is never needed. Forcing can be useful if the font you're using doesn't have the relevant character - but it's not _needed_. It would be just as though you had used the keyboard to insert a character with a glyph missing from the font - which is how "Insert Special Character" should intuitively behave.
*** Bug 138966 has been marked as a duplicate of this bug. ***
(In reply to Jonathan Clark from comment #6) > *** Bug 138966 has been marked as a duplicate of this bug. *** So, can we confirm this now? :-\
I'm not entirely sure about the status of this discussion or this constellation of bugs. I'm provisionally treating this bug as the correct location to discuss the no-direct-formatting case, while bug 139359 discusses somehow minimizing the set of inserted direct formatting. (In reply to Heiko Tietze from comment #2) > While unnecessary DF should be avoided, the few attributes wont break many > documents and don't outweigh a more complex and cluttered UI. See bug 138966 for an example of a user trying to use Insert Special Characters as a soft keyboard for typing uncommon diacritics in their language. We do a much better job now rendering diacritics that are in a separate span from the base text, but it's not perfect, and it isn't what most users of diacritic-heavy languages would want or expect. Currently, we are trading possible UI clutter for having to externally educate users that if they insert diacritics or other combining characters, they must clear formatting to get the output they expect. (In reply to Eyal Rozenberg from comment #7) > (In reply to Jonathan Clark from comment #6) > > *** Bug 138966 has been marked as a duplicate of this bug. *** > > So, can we confirm this now? :-\ Yes. In my opinion, there is an unaddressed need for a soft keyboard for uncommon diacritics in LO. I think we still need common understanding of what should be done, but the need exists.
(In reply to Jonathan Clark from comment #8) > Yes. In my opinion, there is an unaddressed need for a soft keyboard for > uncommon diacritics in LO. My basic argument that it's a soft keyboard for uncommon any-character in LO :-) > I think we still need common understanding of > what should be done, but the need exists. You mean, how we support both DF'ing and no-DF'ing?