Hi Dne Thu, 12 Feb 2009 11:43:42 +0000 Colin Watson <[email protected]> napsal(a):
> I tried to warn about this problem in the policy manual:
>
> Due to limitations in current implementations, all characters in the
> manual page source should be representable in the usual legacy
> encoding for that language, even if the file is actually encoded in
> UTF-8.
>
> ... and you can see the problem like this:
>
> $ iconv -f UTF-8 -t ISO-8859-2 gammu-smsd-mysql.7 >/dev/null
> iconv: illegal input sequence at position 325
>
> In other words, what's happening here is that the middle dot (U+00B7) at
Oops, that came from wrongly using some translation tool and are
already fixed upstream. That's why I had that hard time to find what
actually causes the problem, when trying to reproduce it with current
SVN. Unfortunately diff between those versions was too big to spot
these dots...
> position 325 isn't representable in ISO-8859-2. Unfortunately, manconv
> isn't currently smart enough to distinguish between "conversion failed
> because this isn't valid UTF-8" and "conversion failed because this bit
> of UTF-8 isn't available in the target encoding", and therefore it falls
> back to recoding from ISO-8859-2 to ISO-8859-2 (i.e. a no-op) and then
> you see the mess when it tries to interpret UTF-8 as if it were
> ISO-8859-2.
>
> I think it might be possible to fix this, albeit more slowly, by
> recoding the page to UCS-4, which should always succeed as long as the
> text matches the input encoding being tried, and then recoding from
> there to ISO-8859-2 and just throwing away characters that don't fit.
> Alternatively, by the time we've done that we might have a groff that
> supports UTF-8 input!
Yes, that would be great.
> For the meantime, you can work around this problem by ensuring that your
> manual page passes 'iconv -f UTF-8 -t ISO-8859-2 gammu-smsd-mysql.7
> >/dev/null'.
Thanks, will do that.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
signature.asc
Description: PGP signature
