[vdr] Re: VDR Plugin System - First Step

[Sergei Haller <Sergei.Haller@math.uni-giessen.de>]

On Fri, 10 May 2002, Klaus Schmidinger (KS) wrote:

KS> Sergei Haller wrote:
KS> >
KS> > On Fri, 10 May 2002, Alessio Sangalli (AS) wrote:
KS> >
KS> > AS> Sergei Haller wrote:
KS> > AS>
KS> > AS>
KS> > AS> > there are several languages using non-latin letters
KS> > AS> >  - tere are some for which font files could be easily created
KS> > AS> >    (like cyrillic and greek)
KS> > AS> >  - and some which are much more complicated
KS> > AS> >    (like chinese or arabic)
KS> > AS> >
KS> > AS> > if someone is going to reimlement (a part of) the font selection in vdr,
KS> > AS> > maybe at least the first block of languages could be covered.
KS> > AS>
KS> > AS> generating the fonts it's pretty easy,
KS> >
KS> > yes.
KS> >
KS> > AS> the problem could be using it;  I'm not an expert of internalization
KS> > AS> and character codes but I could create a cirillic font for you (it's
KS> > AS> easy) and you can try it out to see what happens... mh?
KS> >
KS> > creating such a font isn't the problem (there are different character code
KS> > tables for the cyrillic alphabet, though). vdr should be able to select a
KS> > different font file depending on the selected language first.
KS> >
KS> > if you're going to implement such a functionality, I could test it and
KS> > write the Russian i18n.c entries.
KS> >
KS> > I think, the font selection should be done on a per-string basis. just
KS> > imagine some new constants in i18n.c which don't have a translation - they
KS> > would have to be displayed in english then (with a standard font)
KS>
KS> Oh my gosh!

Don't take it to heart ;-)

KS> Can you imagine the amount of font fiddling with this??
KS>
KS> If a language needs a different font, that can be set when the language is
KS> switched, but after that the font remains set. Changing fonts for every string
KS> would IMHO cause an unnecessary overhead. After all, if a translation _is_
KS> missing, it should be added anyway.

e.g. the  EPG info  is  not  translated by  i18n.c  and contains
umlauts, accents, etc.

Even if  I  select e.g. Russian or Greek,  I want to name german
channels  with  latin  letters  (e.g. "SAT 1" and not "CAT 1" or
\Sigma\Alpha\Tau 1")

KS> I haven't dome much with fonts and character sets yet, so maybe my understanding
KS> of this is incomplete. Isn't it so that with all these ISO8859-* sets the lower
KS> 128 characters are always standard ASCII,

I've no idea, I don't use it that much.

KS> and the upper 128 characters are language specific? So an English text
KS> would always be displayed correctly. Or is there more to it?

If  it's that simple, so it's ok. but  there  could be e.g. some
Umlauts in the EPG info, which would be displayed incorrectly.

BTW: _I_ don't need any other translation than German (and would
even  be  happy  with  English,  if   no  other  languages  were
available). What I was going to say was:

  _IF_ someone is going to (re)implement some parts of the  font
  handling,  especially "on-the-fly-switching"  of fonts  (AFAIK
  Alessio already did some changes  with the  font handling), we
  should think on such thing as i18n of languages with "special"
  fonts. And _IF_ someone actually _will_ do it, I could do some
  tests and provide the Russian translation for the i18n.c file.

Back to the point with the per-string basis:

KS> > I think, the font selection should be done on a per-string basis. just
KS> > imagine some new constants in i18n.c which don't have a translation - they
KS> > would have to be displayed in english then (with a standard font)

Maybe we don't need that. Just display everything with the standard font
and all the tr() strings with the language specific font.


c ya
        Sergei
--
--------------------------------------------------------------------
         eMail:       Sergei.Haller@math.uni-giessen.de
--------------------------------------------------------------------
Be careful of reading health books, you might die of a misprint.
                -- Mark Twain