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?
*** Bug 159227 has been marked as a duplicate of this bug. ***
We discussed the topic in the design meeting. The use case is valid, actually both, and sometimes you want to remember a glyph for a certain font, for example when picking special symbols, and sometimes you want to insert glyphs that are available in most fonts and direct formatting is not needed. Some ideas come in mind: a) have a global option, b) do some smart comparison and use the current font if the glyph code pointer and the name match the stored item (and perhaps showing an infobar if the stored glyph is not available for the current font), c) introduce another command that allows the user to either store with the font "Add to favorites with font" or to remember just the unicode pointer per "Add to favorites" (or with different labels).
(In reply to Heiko Tietze from comment #11) > We discussed the topic in the design meeting. I don't think you did. The minutes indicate you discussed bug 159227. My concrete suggestions here were not discussed, nor were the implications on most-recently-added special chars. > The use case is valid, actually both, and sometimes you want to remember a > glyph for a certain font, for example when picking special symbols, and > sometimes you want to insert glyphs that are available in most fonts and > direct formatting is not needed. It's stronger than that. Usually (although certainly not always) - it is important for there _not_ to be DF. It's not just unneeded, it's detrimental. That's why this bug suggests that both use cases be supported, but the default be no-DF. > Some ideas come in mind: My suggestions were apparently not discussed, unfortunately. > a) have a global option, That doesn't agree with the legitimacy/viability of both use-cases. Unless you mean a global option for whether the default is with-DF or without-DF? Please elaborate. > b) do some smart comparison and use the current font if the glyph code > pointer and the name match the stored item No no no, this would offer almost no improvement over the current state of affairs, because I would still get DF I did not ask for nor expect. As Heiko often reminds me, being overly Smart is usually a bad thing. > (and perhaps showing an infobar > if the stored glyph is not available for the current font), An infobar is too animated and distracting, especially on a dialog rather than the document window. Also, the "current font (face)" in the context of the dialog is not the font face where the cursor is at (not to mention that that's actually at least 3 font faces: Western, RTL-CTL, CJK). Rather, the current font (face) is the one that's selected in the drop-down in the dialog. The user sees that and is can't be assumed to also keep in mind the three fonts (or more than three, in the future) at the cursor. Considering that fact, the visual indication we might want to consider is making the glyphs available in the current font face (or set-of-font-faces) be black/full-intensity, and make the missing glyphs appear gray and/or have a dotted background etc. I'm not so sure about this idea though. It's a bit too complex, and I think my suggestions below make things clearer. > c) introduce another command that allows the user to either store with the > font "Add to favorites with font" or to remember just the unicode pointer > per "Add to favorites" (or with different labels). Reminding you of my suggestions a-minus-2) A checkbox for whether to insert with a DF'ed choice of font or not; when unselected, the font selection dialog is grayed-out. a minus 1) The default chosen entry in the font selection drop-down is a non-font, e.g. "(current font)" or "fonts at cursor" or "(no font specified)". This will also let us allow for actually having a set of current fonts. See also https://bugs.documentfoundation.org/show_bug.cgi?id=151215#c19 about how the current font face may involve lots of fonts.
(In reply to Heiko Tietze from comment #11) > We discussed the topic in the design meeting. > > The use case is valid, actually both, and sometimes you want to remember a > glyph for a certain font, for example when picking special symbols, and > sometimes you want to insert glyphs that are available in most fonts and > direct formatting is not needed. > > Some ideas come in mind: > a) have a global option, > b) do some smart comparison and use the current font if the glyph code > pointer and the name match the stored item (and perhaps showing an infobar > if the stored glyph is not available for the current font), > c) introduce another command that allows the user to either store with the > font "Add to favorites with font" or to remember just the unicode pointer > per "Add to favorites" (or with different labels). Thank you for taking the issue(s) seriously. My simple proposal was to use DF only for characters from PUAs. Your option b) is probably closest to this. I'm no expert on fonts, and so your proposal is probably more correct in technical terms. If you are collecting ideas for a more robust solution, here is mine: The Special Character dialog could have three tabs: "Unicode", "Scripts", and "Fonts". On the "Unicode" tab, there would be no font selector; the block selector and the search field would of course be present. This tab would serve as a SW keyboard, inserting characters without DF. All Unicode characters, except for those in PUAs, should be available here. However, the tabular display should be restricted to the selected block or to search results, because scrolling the whole of Unicode would be impractical. Characters would be shown here just as in a text--using the current or substitute font. The "Scripts" (or possibly "Languages") tab would be similar to the previous one; only the block selector would be replaced by a script selector. There are dedicated fonts for specific scripts, and so these should be utilized. I'm not sure if this needs DF when inserting the letters. The "Fonts" tab would probably be the most similar to the present form of the dialog--it would display only characters available in the selected font. The font selector should be the first thing here (before the search field). Characters would be inserted with DF. Favourites and Recent would insert characters with or without DF--according to the tab from which they were added to the Favourites or Recent.