Issue 23792

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".