Reassigned to Ulf Stroehler

I confirm the bug.
For Latin2-PL keyboard,
z-acute, c-acute, s-acute won't display, whilst
e-acute, o-acute, l-strike will.

Please verify again in OO625 and make sure you have chosen a suitable Locale and
font. Please tell me about your findings regarding your Issue in OO625.

Verified with OO627 - there is some progress but not working anyway. There is an
option to input localised characters via "Insert-->Special Character-->", but
those encodings (or character codes) are not the same as in Solaris native (or
StarOffice 5.2). For example: latvian character amacron (long a ;-) with the
code 0x0e2 in Solaris is as character code 0x0101 in "Insert-->Special
Character-->"  "latin extended -A" subset of font in OO627 (I'm testing with
Arial Bal font, both in SO52, Solaris and OO627). I'm using Solaris
lv_LV....ISO-13 locale as Solaris desktop and have set up easy way of getting
latvian characters when typing in SO52, Netscape mail etc. (by xmodmap). With
OO627 (or any other previous release) those codes are different and not
compliant with Solaris locale. Probably - i've not checked - it might be unicode
or something, but again - it's not compliant with Solaris locale (for
ISO-....-xx localisation).

In deed it is Unicode, so verify again with a Unicode font.

OK. All required (for Latvian language) can be inserted via
"Insert-->Special...." procedure now. 

All Solaris 8 default (for ISO---13 locale) fonts with "Bal" in the font
description (except Courier Bal, which displays normaly) are giving "overlaping"
symbols - characters are so close to each other in the document (printed over
each other). But probably this is the fonts problem (why courier bal is working
then ?). 

As for input those symbols from keyboard (unicode, for Latvian locale) in
xmodmap or another way - Solaris 8 (and up) locale should be revisited to
support unicode characters/fonts (in case in OO there will no support for
ISO---13 type of encoding).

Thanks ! 

The Overlapping characters is a different (Solaris) problem, because a lot of
postscript fonts on the system share the same UniqueId. The problem is knowen
and work is in progress. 
I would not like to see this issue to shift over to different kind of problems.
So is your problem regarding the insertion of special characters solved? If yes,
I'd like to close this issue. Anybody problems with that?

Initial problem is fixed. Thanks.

This task is fixed or worked in OOo 1.1 beta2.

closed ...

Unless I am mistaken, this issue should be re-opened. A German keyboard cannot
enter accented characters in OOo although it can in all other applications. 
Using KDE and OOo 1.1.1rc3.

This is a mistake. Just because KDE handles XEvents different than xlib, all
other applications are not mistaken by default. It is wrong to simply focus on
one desktop environment like kde or anything else. If you think localization can
simply be achieved by doing some configuration inside kde than you have to stick
to kde applications. How should any other application using a different toolkit
notice what you have configured in kde without doing it the generic way for all
applications. All major Linux distributors are providing tools for localisation
(because you need a different Locale than C to make compose keys work). Why not
use them?
Besides there are issues underway to use the Xevent hadling of different
toolkits like gtk and qt for OOo 2.0 which solves this issue also. Refer to
issue 22713, issue 20381, issue 25130.

The different enhancement also around this single problem/user-misunderstanding
is issue 16318.

Thus there is no need from my point of view to reopen this old issue.

I have a friend who uses Gnome.  Same problem there.  All applications except
OOo handle the keyboard changes flawlessly.  OOo does not handle them at all. 
It is and remains a bug and has been reported more than a dozen times in the
past year -- always marked as a duplicate to a closed issue and never once
looked at to see why OOo alone fails to handle the keyboard issues correctly.