V Ne, 25. 01. 2004 v 22:41, Rene S. Hollan p=C3=AD=C5=A1e:
> That's what I thought. I'm running a patched RH 7.2 system, but a Googl=
> search onm iconv() only turned up documentation that matched what mine=20
> does: convert as many samples as possible from the input. If the output=
> buffer has too little space, it returns E2BIG. As coded, the output=20
> buffer was spec'd as two bytes, and the input was nominally 10, so I=20
> always got E2BIG.
It's right. You should always get E2BIG and converted one
multibyte-character to UCS-2 (in the machine endian).
> When that happened, a character code was substituted that rendered as a=
> upside down exclamation point.
> When I fixed the iconv issue (having it convert only one sample at a=20
> time), like what appeared was expected, the conversion codes came back=20
> in a manner that I had to byte swap.
Problem with your patch is, it will not work with multibyte (source)
encoding, UTF-8 for example.
> > Can you please give me some other info?:
> > - which exactly text isn't displayed correctly (playing status,
> > subtitles and their encoding, other text, all texts?)
Thanks. All looks OK.
I forgot - we should check also next thing:
New xine requires new format of fonts and doesn't check the version of
the format. Do you have some old font in '~/.xine/fonts' or
Also would be interesting console output with defined LOG in the file