Apache OpenOffice (AOO) Bugzilla – Issue 23792
find & replace : insert special character lack full unicode range
Last modified: 2017-05-20 11:13:32 UTC
Windows 2003 + Mandrake 8.2: edit -- find & replace -- context menu in "replace" -- insert special character: Only a limited set of special characters is offered. For exmple, No non-western languages are offered. This make replacing minus with maqaf difficult, as you can't select it from the charachters. The dialog should have the full unicode range, like the insert special characher diglog in the insert menu.
May be, it would be better to formulate the problem differently. When I call the "Special Characters" dialog from an input field (like in the "Search & Replace" dialog), the font used for character map by default has nothing to do with the font used in that input field. On my system this is simply the first font available in the list of fonts known to OOo. Nothing strange if this font doesn't contain some necessary characters. The problem is that I can't select another font because the "Font" combo is grayed out. So I think 2 changes should be made in this dialog's behavior: 1) by default the character map should be displayed in the font used in the input field the dialog is called from. Using an arbitrary font is a defect, which should be fixed; 2) However, the "Font" combo should be still available, so that user could select any font containing all Unicode characters he/she needs. I suppose this is an enchancement, but it should be easy to implement it.
These are obviously two Issues concerning > Edit > Find and Replace > Format > Font (a) The Font GUI in Replace doesn't provide a character map. Which makes it virtually impossible to select a special character or any foreign character for replacing. (b) The input field "Font" as well as "Typeface" and "Size" doesn't contain a default font. The user has to select from the list. This behaviour is different from the > Format > Character > Font GUI. I don't consider (b) the main Issue here, so let's focus on (a) here. If you find (b) still needs implementing, please open a separate Issue for (b). I will change the summary following (a) and will close other yet unconfirmed Issues as duplicates of this, as there are various.
*** Issue 23791 has been marked as a duplicate of this issue. ***
*** Issue 16378 has been marked as a duplicate of this issue. ***
DL->SBA: Would you please handle this?
set target OOo later
adding dina as cc
i think this not an defect because this is in all versions of OOo and staroffice, i just looked on So 5.2 i change the issuetype to enhancement and reassign this issue to the owner of enhancement issues
*** Issue 18105 has been marked as a duplicate of this issue. ***
Just a comment regarding the latest OOo 2.0 builds. When I run OOo 2.0 with a GTK theme, then press my right mouse button on an input field (not necessarily in the "search and replace" dialog!) and select "Special Character...", the character map is displayed in my default GUI font (e. g. Helvetica). So far, so good: I can't change the font in the dialog box, but at least I can select another GUI font in my GTK settings. However, when I run OOo without GTK theme, the Special Characters -> Font combo is still empty (nothing is selected), and the first available font in alphanumeric order is used. Of course, this is completely wrong. So, is it possible to force OOo to always use its default GUI font (Andale Sans UI or its currently used replacement) for displaying the character map when it is called from an input field (e. g. in the "Search and Replace" dialog)? And, finally, can anybody take a *pricipial* decision, if the font selection combo in the "Special Characters" dialog should be enabled, or such a solution should be avoided for some reasons? This issue should be very easy to fix, if we know which behavior we want to get ...
While you might not consider it a "defect" because OO never was able to use unicode as replacement text, it is a sorely lacking feature that both FrameMaker and Word contain. I'm trying to replace a few hundred instances of "X" with a real multiplcation symbol. Let me tell you that the only other way to do this is REALLY tedious: Find an X use the pull down menu Insert/Special Character Select the Symbol font. If you type S, you get to the head of the S fonts. Scroll down 77 lines to "Symbol"! Look for a Mult symbol. It's not there. Scroll down one miniscreen. There it is! Select it. Click Ok. Done....in 55 seconds. I'll do this a 2nd time just to make see if it's faster the second time. Nope...OO doesn't remember the last font used or the last screen within the character table. I might get the time down to 45 seconds/insert, but there's no way I'm going to do more than a dozen of these! Please add this funcionality. It's really important!
There is a work-around: Having inserted the × character in the text once, you can copy and paste it into the Replace field. That said, the existing behaviour does look buggy: when you press Ctrl-Shift-S, a character table is presented in an apparently random font, the name of which is sometimes displayed and sometimes not, and which can't be changed.
Still exists in 3.0. Target set to 3.2. Rafaella on cc. Reassign to mba.
Please let me summarize. The reason why not all Unicode characters can be used here is that we only allow to insert the characters that the font used by the ComboBox for the SearchString can display. There are two ways to fix that: - Users can change the GUI font - we can allow to change the font for this control only and so enable the font selection in the SpecialCharacter dialog I will investigate how much effort the second option is as it surely is better for the users. Caveat: as mixing fonts is not possible, so changing the font will change it for the whole search string. That shouldn't be a big problem, but I wanted to mention it (and it is true for both solutions).
2mba: The key problem with this issue IMO is that the dialog is currently initialized without a reasonable value assigned to the font selection combo box. For this reason the first option you have proposed doesn't work, because instead of the GUI font (also used for the search string) the dialog currently displays an random font, usually just the first one in the alphabetic list. This may well be a symbol font, lacking some important characters. So allowing users to select an appropriate face from the list is a good idea, but it is even more important to provide a reasonable default.
Oops, I overlooked that. Of course you are right, the selected font should match the one used by the ComboBox. That will be fixed then also. It stills leaves us with the two options and I will continue to evaluate the second one.
Obviously not fixed in 3.2
Reset assigne to the default "issues@openoffice.apache.org".