A decisison needs to be made if Xman should be tossed, deprecated but provided
'as is', or fixed. xman may not be i18n capable and I would think the incentive
to fix it is not very high as there are other ways to view manual pages.
Is xman still shipped with Solaris?

Egbert Eich wrote:
> A decisison needs to be made if Xman should be tossed,

Please no... ;-(

> deprecated but provided
> 'as is', or fixed.

Well, a possible fix may be simply to switch the default font to a japanese
encoding "on demand". The problem is how "xman" should detect a japanese manual
page (there are some nice algorithms for charset autodetection) ... or whether
the user should do that manually.
For a Motif application this would be easy... but I have no clue how I can force
the Xaw text widget into doublebyte mode (e.g. 16bit font) - does anyone know
examples for that ?

[snip]
> Is xman still shipped with Solaris?

Yes, it's even in the default ${PATH} ...
% which xman
/usr/openwin/bin/xman
... and Alan did recently some bugfixing for Solaris and added support for
DocBook manual pages.

After some investigation and experiments with "XMore" it seems that i18n support
in Xaw mainly works like in Motif - basically all the XFontStruct stuff has to
be replaced with XFontSet objects, |XtNinternational| must be set to |True| and
that's all in theory.
In reality I am getting "<<< FILE CONTENTS NOT REPRESENTABLE IN THIS LOCALE >>>"
on my SuSE8.2 installation... does anyone have any ideas why this happens ?

I may have a fix for this . but currently I am stuck in bug 696 ("Cannot build
own libX11.so on Solaris which uses Solaris locale objects") and cannot test
whether my patch works... ;-(

Is this still an issue?

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Created attachment 40077 [details]
Japanese manual for chfn

Using the git version of xman, xserver 1.9.0 (from Ubuntu 10.10), and the attached manual, I see this bug.

The output I get is :

eqn:/tmp/xmanMiVXXR:35: invalid input character code `144'
eqn:/tmp/xmanMiVXXR:35: invalid input character code `141'
eqn:/tmp/xmanMiVXXR:35: invalid input character code `137'
eqn:/tmp/xmanMiVXXR:35: invalid input character code `141'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `131'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `131'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `130'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `129'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `143'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `144'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `141'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `130'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `132'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `131'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `133'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `130'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `146'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `137'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `155'
eqn:/tmp/xmanMiVXXR:36: invalid input character code `129'
...(snipped by me)

This output suggests that this is really a problem with eqn not being able to handle Japanese output.

I should also mention that I did no locale editing, and that man was able to render the characters properly.

What is the output of running 'locale'?

If you do this first:
export LC_ALL=ja_JP.PCK
export LANG=ja_JP.PCK

are you able to browse it?

I don't think that this is an xman bug.  It's just the unfortunate nature of 
icky character sets and locales.

Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.