Mike Guy <[EMAIL PROTECTED]> writes:
> Slaven Rezic <[EMAIL PROTECTED]> wrote
> > Does this mean that the replacement E<0xef> also causes problems on
> > such systems?
>
> Sadly, yes. Any appearance of characters > 127 in the nroff input
> causes trouble. How the characters are encoded in the POD source is
> irrelevant. :-(
>
> If we *really* want such characters in POD output, a possible way
> forward might be for pod2man (only) to substitute the offending
> characters. Or better still this controlled by a Configure option,
> set only in the hint file(s) for the offending systems.
>
> But personally, I don't think it's worth the trouble. (Read: *I'm* not
> going to provide a patch. :-)
>
I just checked: only named entities are recognized by pod2man. For
example "�" is converted to "i\*:". This causes groff to render this
character as "ie". The groff_char manpage suggests to use "\(:i"
instead, which is rendered correctly. Hexadecimal entities are not
recognized at all by pod2man. Seems that some work is needed...
Regards,
Slaven
--
Slaven Rezic - [EMAIL PROTECTED]
Tk-AppMaster: a perl/Tk module launcher designed for handhelds
http://tk-appmaster.sf.net
