Apache OpenOffice (AOO) Bugzilla – Issue 9359
Insert Special Character dialog needs re-think
Last modified: 2013-08-07 14:38:26 UTC
The dialog displays in one big range all the Unicode values supported by the given font. However, a font may have no glyphs for some sub-range, and the dialog will behave as though it did, displaying question marks in the missing slots. There is a pop-down menu that moves to different ranges of unicode. This is good, but it should have a bigger effect. It would be better if the dialog displayed only the ranges of unicode for which the font actually has glyphs, and not to allow scrolling out of these ranges. I mean, that 'Subset' menu should show only ranges supported by the font, and when one is chosen from it, the table should show only that range. Finally, the Unicode value is displayed in hex, with no explanation. How about explaining it's a Unicode index, and displaying it in decimal? That would make it useful for users other than programmers and mathematicians.
ES->BH: I don't agree on displaying only used ranges I agree about the char count unit: should be also decimal.
Reassigned to BH
You don't agree with displaying only used ranges... Then what do you propose to address the problem I'm talking about: a table with 60K slots, only a tiny fraction of which may be filled??? Do you think the user should hunt for those few slots that contain glyphs? It should be possible to make this dialog much easier to use.
Yes, I confirm. This dialog needs to get changed. As this is not a keyfeature for the 'Q', this is taken for 'Office Later'.
Hmm, as far as I can see, in 2.1 and 2.2 only the charaters actually present in a font are displayed in the Insert Special Character menu? But that actually is not an entirely good thing in my opinion. Different fonts have slightly different coverages, and that means that the column in the array where a character appears differs from font to font. This means it will be more difficult for a user to find some certain character that they need often in different fonts, as they can't rely on memory rules like "scroll down about ten lines, then it's at the fifth column." The ideal would be to always keep characters aligned to that those whose Unicode code point ends in hex zero are in the first column, etc. Rows that lack characters completely should be left out, obviously.
Some of you have raised good points. Let's look at it from a user's perspective. The user wants to insert a character into their document; the dialog is meant to facilitate that activity. They don't know squat about Unicode. If the character isn't represented at all in the dialog (for a given font), how are they to find it? Should they search all the tables, for each available font, for their character? It would seem that all Unicode characters should be there, arranged in a way that is easy for a layperson to navigate. (I don't think the Unicode range names are particularly obvious--they are a historical artifact. And what's with those tiny pop-down menus?) On the other hand, if all unicode characters are presented, but the character the user wants is not available in the current font, how is the situation to be conveyed to the user, and what is the user to do about it? I can imagine ways: For example, when the box for the character is right-clicked, a dialog could open showing that character in all the fonts that support it. If it's clicked and the character is supported by the current font, that character is immediately inserted. Another note: this dialog is unfortunately very familiar. I think somebody peeked at somebody else's (poor) solution. Ingenuity should be brought to bear.
To grep the issues easier via "requirements" I put the issues currently lying on my owner to the owner "requirements".