From: Bastien N. <ha...@ha...> - 2003-02-27 16:16:55
|
On Thu, 2003-02-27 at 15:55, Frantisek Dvorak wrote: > Hi Miguel,=20 >=20 > >Od: Miguel Freitas [mailto:mi...@ce...] > >Odesl=E1no: 1. leden 0001 0:00 > >Komu: Frantisek Dvorak > > > >Hi, > > > >On Thu, 2003-02-27 at 05:43, Frantisek Dvorak wrote: > >> attached are the patches (for xine-lib and xine-ui) which fix problems= with OSD font encoding - non-ASCII > >> characters are bad displayed. > >> > >> Rendered text from frontend is converted from current locale encoding = 'nl_langinfo(CODESET)' to > >> targed encoding of OSD font (in the option 'misc.osd_font_encoding'). > > > >are you sure you are not reinventing the wheel here? > >what about the existing misc.spu_src_encoding and misc.spu_dst_encoding? > > >=20 > Options 'misc.spu_src_encoding' and 'misc.spu_dst_encoding' are used for = converting subtitles in libsputext decoder. > My conversion called from 'xine_interface.c' due only to frontends OSD te= xts. > Routine in 'utils.c' is usable also for libsputext, but why create new bu= gs in working code? :-). >=20 > About 'misc.spu_dst_encoding': I thing reusing isn't possible, because fr= ontend can set OSD font different from current SPU font. Wouldn't it be easier to use Unicode in the front-ends ? The whole SPU system using Unicode would definetely reduce the chances of this kind of fixes. Adding 2 new configuration options is not the best thing to do when it should "just work". --=20 /Bastien Nocera http://hadess.net #2 0x4205a2cc in printf ("Oh my %s\n", preferred_deity) from /lib/i686/libc.so.6 printf ("Oh my %s\n", preferred_deity); Segmentation fault |