VDR developer version 1.5.3 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.3.tar.bz2
A 'diff' against the previous developer version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.2-1.5.3.diff
This version finally brings UTF-8 capability to VDR! There are still a few minor details to iron out, but all in all it already works pretty good.
Note that if you run VDR on a UTF-8 system, it will write all its text files using UTF-8. Existing text files written in ISO will not be automatically converted to UTF-8. You will need to do this yourself if necessary. Channel and EPG data will be automatically changed to UTF-8 as new data comes in.
If you run VDR on a system with ISO character set, files will still be stored in ISO just as before.
Several bugfixes etc. that have been posted on the mailing list lately are still in my inbox and I have yet to look into them.
WARNING: ========
This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging.
The changes since version 1.5.2:
- Fixed some spelling errors in 'newplugin' (thanks to Ville Skyttä). - Fixed a busy loop in fast forward if the next video data file is missing (thanks to Reinhard Nissl). - Fixed handling frequencies in NitFilter::Process() (thanks to Anssi Hannula). - Fixed a race condition with signal handlers at program exit (thanks to Udo Richter). - Non-primary devices in Transfer mode are now also used for recording (thanks to Anssi Hannula). - Fixed handling ChannelUp/Down keys if there is currently a replay running (thanks to Marco Schlüßler). - The new SVDRP command REMO can be used to turn VDR's remote control off and on in case other programs need to be controlled (based on patches from Krzysztof Parma and Helmut Auer). - Increased the maximum number of CA system ids to cope with the AlphaCrypt CAM's version 3.11 firmware. - Fixed getting the code setting from the locale (thanks to Matthias Schwarzott). - Implemented support for Freetype fonts (based on a patch from Alexander Riedel). The font names and sizes can be adjusted in the "Setup/OSD" menu. Note that VDR now requires freetype fonts to be installed in /usr/share/fonts/truetype. - If the OSD device in use has at least 8bpp bitmap depth and this is also used by the current skin, Freetype fonts are displayed "anti-aliased". The new setup parameter "OSD/Anti-alias" can be used to turn this off. - The new function cOsd::SetAntiAliasGranularity() can be used to help the OSD in managing the available color palette entries when doing anti-aliasing. Skins that use 8bpp bitmaps can call this function with the maximum number of colors used, and the maximum number of color combinations. The OSD will then evenly split the available palette entries between the various colors combinations, so that fonts can be "anti-aliased". By default a total of 10 colors and 10 combinations is assumed. - The pixel fonts have been completely removed from the VDR source. - VDR is now "UTF-8 aware". It handles strings according to the character encoding used on the user's system. All internationalization strings and incoming SI data are converted to the system encoding. - Plugins that handle strings need to be aware that on systems with UTF-8 encoding a "character symbol" may consist of more than a single byte in memory. The functions and macros named Utf8...() can be used to handle strings without needing to care about the underlying character encoding (see tools.h for details). - Even though the weekdays of repeating timers are presented to the user as UTF-8 characters in the OSD, the timers.conf file and the SVDRP timer commands still use single byte characters ("MTWTFSS") to make sure this information is handled correctly between systems with different character encodings. - Added a missing i18n string for "CAM" in the Turkish OSD texts. - Improved editing strings that are too long to fit into the editable area. - Changes to the OSD settings in the "Setup/OSD" menu now immediately take effect when the "Ok" key is pressed.
Have fun!
Klaus
Hi, On Sun, 2007-06-10 at 15:45 +0200, Klaus Schmidinger wrote:
VDR developer version 1.5.3 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.3.tar.bz2A 'diff' against the previous developer version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.2-1.5.3.diff
- The pixel fonts have been completely removed from the VDR source.
- VDR is now "UTF-8 aware". It handles strings according to the character encoding used on the user's system. All internationalization strings and incoming SI data are converted to the system encoding.
nice to hear this. I'm beginning with 1st plugin, that can't this handle. and it's your plugin :-) make[1]: Entering directory `/tmp/vdr-1.5.3/PLUGINS/src/skincurses' g++ -fPIC -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"skincurses"' -I../../../include skincurses.c ../../../include/vdr/font.h:36: warning: ‘virtual int cFont::Width(uint) const’ was hidden skincurses.c:24: warning: by ‘cCursesFont::Width’ skincurses.c: In constructor ‘cCursesFont::cCursesFont()’: skincurses.c:22: error: no matching function for call to ‘cFont::cFont(NULL)’ ../../../include/vdr/font.h:31: note: candidates are: cFont::cFont() ../../../include/vdr/font.h:31: note: cFont::cFont(const cFont&)skincurses.c: At global scope: skincurses.c:30: error: cannot declare variable ‘Font’ to be of abstract type ‘const cCursesFont’ skincurses.c:20: note: because the following virtual functions are pure within ‘const cCursesFont’: ../../../include/vdr/font.h:36: note: virtual int cFont::Width(uint) const ../../../include/vdr/font.h:44: note: virtual void cFont::DrawText(cBitmap*, int, int, const char*, tColor, tColor, int) const make[1]: *** [skincurses.o] Error 1
Regards Oleg Roitburd
On 06/10/07 16:32, Oleg Roitburd wrote:
Hi, On Sun, 2007-06-10 at 15:45 +0200, Klaus Schmidinger wrote:
VDR developer version 1.5.3 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.3.tar.bz2A 'diff' against the previous developer version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.2-1.5.3.diff
- The pixel fonts have been completely removed from the VDR source.
- VDR is now "UTF-8 aware". It handles strings according to the character encoding used on the user's system. All internationalization strings and incoming SI data are converted to the system encoding.
nice to hear this. I'm beginning with 1st plugin, that can't this handle. and it's your plugin :-) make[1]: Entering directory `/tmp/vdr-1.5.3/PLUGINS/src/skincurses' ...
Well, this is one of the things I referred to by "There are still a few minor details to iron out" ;-). I haven't looked at any of the plugins yet - I wanted to get the core program up and running first.
Maybe you should try the core program by itself first.
Klaus
On 06/10/07 16:32, Oleg Roitburd wrote:
Hi, On Sun, 2007-06-10 at 15:45 +0200, Klaus Schmidinger wrote:
VDR developer version 1.5.3 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.3.tar.bz2A 'diff' against the previous developer version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.2-1.5.3.diff
- The pixel fonts have been completely removed from the VDR source.
- VDR is now "UTF-8 aware". It handles strings according to the character encoding used on the user's system. All internationalization strings and incoming SI data are converted to the system encoding.
nice to hear this. I'm beginning with 1st plugin, that can't this handle. and it's your plugin :-) make[1]: Entering directory `/tmp/vdr-1.5.3/PLUGINS/src/skincurses' ...
The attached patch makes it compile.
I haven't been able to see it display UTF-8 characters, though.
From what I've seen on the web it should work when linked with
-lncursesw, but then again maybe just setting LANG=de_DE.utf8 isn't enough to tell curses to actually use UTF-8 on an otherwise pure ISO system...
Klaus
Klaus Schmidinger wrote:
- Implemented support for Freetype fonts (based on a patch from Alexander Riedel). The font names and sizes can be adjusted in the "Setup/OSD" menu. Note that VDR now requires freetype fonts to be installed in /usr/share/fonts/truetype.
In my system there is no /usr/share/fonts/truetype, but the TTF fonts reside in other subdirectories under /usr/share/fonts.
+ strcpy(FontOsd, "arialbd.ttf"); + strcpy(FontSml, "arial.ttf"); + strcpy(FontFix, "courbd.ttf");
I'd use some free-as-in-freedom font (Vera?) by default, that are more likely installed in systems.
Alternatively, you could use the fontconfig library [1] for managing fonts. This would also allow using using the system default fonts via aliases like 'sans-serif' etc, and using a font list instead of having to manually write the font filename via OSD.
You can get a quick idea from looking at the patch which added fontconfig support for mplayer [2], though of course you should look in fontconfig documentation instead of copying conventions from mplayer :)
[1] http://fontconfig.org/ [2] http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-November/022218.htm...
On 06/10/07 17:53, Anssi Hannula wrote:
Klaus Schmidinger wrote:
- Implemented support for Freetype fonts (based on a patch from Alexander Riedel). The font names and sizes can be adjusted in the "Setup/OSD" menu. Note that VDR now requires freetype fonts to be installed in /usr/share/fonts/truetype.
In my system there is no /usr/share/fonts/truetype, but the TTF fonts reside in other subdirectories under /usr/share/fonts.
Well, it's a real pitty with the various systems putting files at random places.
Can't there be a *standard* for things like this?
- strcpy(FontOsd, "arialbd.ttf");
- strcpy(FontSml, "arial.ttf");
- strcpy(FontFix, "courbd.ttf");
I'd use some free-as-in-freedom font (Vera?) by default, that are more likely installed in systems.
Those were the ones suggested in Alexander Riedel's original patch. Which ones would you suggest?
Alternatively, you could use the fontconfig library [1] for managing fonts. This would also allow using using the system default fonts via aliases like 'sans-serif' etc, and using a font list instead of having to manually write the font filename via OSD.
You don't have to manually write the font name. This is a list of strings that contains all the file names found in /usr/share/fonts/truetype (or wherever your system my have these files - I guess this will have to become a compile-time switch - <sigh>). Just use the Left/Right keys to navigate through it.
You can get a quick idea from looking at the patch which added fontconfig support for mplayer [2], though of course you should look in fontconfig documentation instead of copying conventions from mplayer :)
[1] http://fontconfig.org/ [2] http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-November/022218.htm...
I'd like to keep it simple. There's a directory with font file names and these will be offered in Setup/OSD.
Klaus
Klaus Schmidinger wrote:
On 06/10/07 17:53, Anssi Hannula wrote:
Klaus Schmidinger wrote:
- Implemented support for Freetype fonts (based on a patch from Alexander Riedel). The font names and sizes can be adjusted in the "Setup/OSD" menu. Note that VDR now requires freetype fonts to be installed in /usr/share/fonts/truetype.
In my system there is no /usr/share/fonts/truetype, but the TTF fonts reside in other subdirectories under /usr/share/fonts.
Well, it's a real pitty with the various systems putting files at random places.
Can't there be a *standard* for things like this?
Well, I guess the "standard" is to put fonts into /usr/share/fonts.
- strcpy(FontOsd, "arialbd.ttf");
- strcpy(FontSml, "arial.ttf");
- strcpy(FontFix, "courbd.ttf");
I'd use some free-as-in-freedom font (Vera?) by default, that are more likely installed in systems.
Those were the ones suggested in Alexander Riedel's original patch. Which ones would you suggest?
Hard to say, it seems the default in my system is to use the DejaVu fonts, but I guess Vera and Luxi are common as well.
Alternatively, you could use the fontconfig library [1] for managing fonts. This would also allow using using the system default fonts via aliases like 'sans-serif' etc, and using a font list instead of having to manually write the font filename via OSD.
You don't have to manually write the font name. This is a list of strings that contains all the file names found in /usr/share/fonts/truetype (or wherever your system my have these files - I guess this will have to become a compile-time switch - <sigh>). Just use the Left/Right keys to navigate through it.
Okay, I missed that one when reading the code. Anyway, many of my fonts are in different subdirectories by the family name (dejavu/ etc), so that would need to handled be as well.
You can get a quick idea from looking at the patch which added fontconfig support for mplayer [2], though of course you should look in fontconfig documentation instead of copying conventions from mplayer :)
[1] http://fontconfig.org/ [2] http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-November/022218.htm...
I'd like to keep it simple. There's a directory with font file names and these will be offered in Setup/OSD.
On Sun, 10 Jun 2007, Klaus Schmidinger wrote:
Well, it's a real pitty with the various systems putting files at random places.
How about setting the FONTDIR configurable through Make.config or ever commandline switch? On my first test run of vdr-1.5.3 it kept crashing without hinting that no font files could be found. It would be very convenient to inform users that the required fonts are missing rather than doing segmentation fault :)
BR, -- rofa
On 06/10/07 18:22, Rolf Ahrenberg wrote:
On Sun, 10 Jun 2007, Klaus Schmidinger wrote:
Well, it's a real pitty with the various systems putting files at random places.
How about setting the FONTDIR configurable through Make.config or ever
Will do. Apparently different systems spread their font files all over the place. I was really hoping there would at least once be a common place for this... :-(
commandline switch? On my first test run of vdr-1.5.3 it kept crashing without hinting that no font files could be found. It would be very convenient to inform users that the required fonts are missing rather than doing segmentation fault :)
This was the first step to do UTF-8. I'll add more error handling as things mature.
Klaus
On 6/10/07, Rolf Ahrenberg rahrenbe@cc.hut.fi wrote:
On Sun, 10 Jun 2007, Klaus Schmidinger wrote:
Well, it's a real pitty with the various systems putting files at random places.
How about setting the FONTDIR configurable through Make.config or ever commandline switch?
Yes, I also think this would be the best solution unless theres a sane reason to not handle it like the video dir. A default setting in Make.config and a commandline switch to override.
On 06/12/07 07:12, VDR User wrote:
On 6/10/07, Rolf Ahrenberg rahrenbe@cc.hut.fi wrote:
On Sun, 10 Jun 2007, Klaus Schmidinger wrote:
Well, it's a real pitty with the various systems putting files at random places.
How about setting the FONTDIR configurable through Make.config or ever commandline switch?
Yes, I also think this would be the best solution unless theres a sane reason to not handle it like the video dir. A default setting in Make.config and a commandline switch to override.
I'll first try using fontconfig, as has been suggested earlier. If that works, we probably won't be needing a FONTDIR at all.
Klaus
On Sun, 2007-06-10 at 18:04 +0200, Klaus Schmidinger wrote:
On 06/10/07 17:53, Anssi Hannula wrote:
Klaus Schmidinger wrote:
Can't there be a *standard* for things like this?
- strcpy(FontOsd, "arialbd.ttf");
- strcpy(FontSml, "arial.ttf");
- strcpy(FontFix, "courbd.ttf");
I'd use some free-as-in-freedom font (Vera?) by default, that are more likely installed in systems.
Bitstream Vera isn't good enough...it doesn't provide Cyrillic part of UTF-8 :-( M$ fonts are not free. My suggestion is liberation ttf from RedHat https://www.redhat.com/promo/fonts/
Regards Oleg Roitburd
On 06/10/07 19:45, Oleg Roitburd wrote:
On Sun, 2007-06-10 at 18:04 +0200, Klaus Schmidinger wrote:
On 06/10/07 17:53, Anssi Hannula wrote:
Klaus Schmidinger wrote:
Can't there be a *standard* for things like this?
- strcpy(FontOsd, "arialbd.ttf");
- strcpy(FontSml, "arial.ttf");
- strcpy(FontFix, "courbd.ttf");
I'd use some free-as-in-freedom font (Vera?) by default, that are more likely installed in systems.
Bitstream Vera isn't good enough...it doesn't provide Cyrillic part of UTF-8 :-( M$ fonts are not free. My suggestion is liberation ttf from RedHat https://www.redhat.com/promo/fonts/
I'm considering compiling one font file directly into the program, so that, in case no external fonts can be found, it can at least run properly.
Can somebody suggest a freetype font that looks good, covers all necessary locales, and is really free, so that it can be redistributed with the VDR source?
Klaus
Klaus Schmidinger wrote:
I'm considering compiling one font file directly into the program, so that, in case no external fonts can be found, it can at least run properly.
Can somebody suggest a freetype font that looks good, covers all necessary locales, and is really free, so that it can be redistributed with the VDR source?
What about falling back to the bitmap font vdr currently uses? It would only be able to display ASCII but that would be sufficient to at least start up vdr in english. OTOH you can always puts("install true type fonts"); exit(1) :-)
cu Ludwig
On 06/12/07 17:59, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
I'm considering compiling one font file directly into the program, so that, in case no external fonts can be found, it can at least run properly.
Can somebody suggest a freetype font that looks good, covers all necessary locales, and is really free, so that it can be redistributed with the VDR source?
What about falling back to the bitmap font vdr currently uses? It would only be able to display ASCII but that would be sufficient to at least start up vdr in english.
That was my first thought, too. But it would mean having an additional font mechanism that, in almost all cases, would never be used.
OTOH you can always puts("install true type fonts"); exit(1) :-)
If I can't compile in a freetype font, that's pretty much what it's going to be.
Klaus
Klaus Schmidinger wrote:
On 06/10/07 17:53, Anssi Hannula wrote:
- strcpy(FontOsd, "arialbd.ttf");
- strcpy(FontSml, "arial.ttf");
- strcpy(FontFix, "courbd.ttf");
I'd use some free-as-in-freedom font (Vera?) by default, that are more likely installed in systems.
Those were the ones suggested in Alexander Riedel's original patch. Which ones would you suggest?
If you will decide to go with fontconfig, just for the record, the relevant aliases AFAIK are "sans-serif:bold", "sans-serif", and "monospace:bold", i.e. for the current defaults "Arial Bold", "Arial" and "Courier Bold". There probably is another way to specify bold (or query bold capability) using fontconfig functions as well, but :bold seems to work for me.
On 06/16/07 15:36, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 06/10/07 17:53, Anssi Hannula wrote:
- strcpy(FontOsd, "arialbd.ttf");
- strcpy(FontSml, "arial.ttf");
- strcpy(FontFix, "courbd.ttf");
I'd use some free-as-in-freedom font (Vera?) by default, that are more likely installed in systems.
Those were the ones suggested in Alexander Riedel's original patch. Which ones would you suggest?
If you will decide to go with fontconfig, just for the record, the relevant aliases AFAIK are "sans-serif:bold", "sans-serif", and "monospace:bold", i.e. for the current defaults "Arial Bold", "Arial" and "Courier Bold". There probably is another way to specify bold (or query bold capability) using fontconfig functions as well, but :bold seems to work for me.
Yes, I'm currently going for fontconfig - looks very promising so far.
And your hint is much appreciated - that's exactly what I needed right now :-)
Klaus
Klaus Schmidinger wrote:
On 06/16/07 15:36, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 06/10/07 17:53, Anssi Hannula wrote:
- strcpy(FontOsd, "arialbd.ttf");
- strcpy(FontSml, "arial.ttf");
- strcpy(FontFix, "courbd.ttf");
I'd use some free-as-in-freedom font (Vera?) by default, that are more likely installed in systems.
Those were the ones suggested in Alexander Riedel's original patch. Which ones would you suggest?
If you will decide to go with fontconfig, just for the record, the relevant aliases AFAIK are "sans-serif:bold", "sans-serif", and "monospace:bold", i.e. for the current defaults "Arial Bold", "Arial" and "Courier Bold". There probably is another way to specify bold (or query bold capability) using fontconfig functions as well, but :bold seems to work for me.
Yes, I'm currently going for fontconfig - looks very promising so far.
And your hint is much appreciated - that's exactly what I needed right now :-)
About those bolds.. It seems using the ":bold" suffix isn't reliable, i.e. at least here using "monospace:bold" and calling FcFontSort returns non-monospace fonts ahead of the wanted monospace fonts.
Using this it works correctly, though, and the bold monospace font is returned first: FcPatternAddInteger(fc_pattern, FC_WEIGHT, FC_WEIGHT_BOLD)
Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 06/16/07 15:36, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 06/10/07 17:53, Anssi Hannula wrote:
- strcpy(FontOsd, "arialbd.ttf");
- strcpy(FontSml, "arial.ttf");
- strcpy(FontFix, "courbd.ttf");
I'd use some free-as-in-freedom font (Vera?) by default, that are more likely installed in systems.
Those were the ones suggested in Alexander Riedel's original patch. Which ones would you suggest?
If you will decide to go with fontconfig, just for the record, the relevant aliases AFAIK are "sans-serif:bold", "sans-serif", and "monospace:bold", i.e. for the current defaults "Arial Bold", "Arial" and "Courier Bold". There probably is another way to specify bold (or query bold capability) using fontconfig functions as well, but :bold seems to work for me.
Yes, I'm currently going for fontconfig - looks very promising so far.
And your hint is much appreciated - that's exactly what I needed right now :-)
About those bolds.. It seems using the ":bold" suffix isn't reliable, i.e. at least here using "monospace:bold" and calling FcFontSort returns non-monospace fonts ahead of the wanted monospace fonts.
Actually, you can disregard this, these *do* work correctly when used with FcNameParse().
(I first tested by specifically putting these suffixes into the FC_FAMILY field, which does not work)
Using this it works correctly, though, and the bold monospace font is returned first: FcPatternAddInteger(fc_pattern, FC_WEIGHT, FC_WEIGHT_BOLD)
On 06/10/07 17:53, Anssi Hannula wrote:
... Alternatively, you could use the fontconfig library [1] for managing fonts. This would also allow using using the system default fonts via aliases like 'sans-serif' etc, and using a font list instead of having to manually write the font filename via OSD.
You can get a quick idea from looking at the patch which added fontconfig support for mplayer [2], though of course you should look in fontconfig documentation instead of copying conventions from mplayer :)
[1] http://fontconfig.org/ [2] http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-November/022218.htm...
When I do
const char *font_name = "sans-serif"; FcInit(); FcPattern *fc_pattern = FcNameParse((FcChar8 *)font_name); FcConfigSubstitute(0, fc_pattern, FcMatchPattern); FcDefaultSubstitute(fc_pattern); fc_pattern = FcFontMatch(0, fc_pattern, 0); FcChar8 *s; FcPatternGetString(fc_pattern, FC_FILE, 0, &s); fprintf(stderr, "font '%s'\n", s);//XXX free(fc_pattern); FcFini();
it prints
font '/usr/share/fonts/truetype/arial.ttf'
which looks good. However, when I use "courier" instead of "sans-serif", I get
font '/usr/share/fonts/URW/n022003l.pfb'
which is not a truetype font and therefore can't be used with VDR's font rendering.
Is there a way to make fontconfig only return truetype fonts?
Also: is there a way to get a list of available truetype fonts from fontconfig? That's what would be needed to allow the user to select a desired font in VDR's Setup/OSD menu.
Klaus
I demand that Klaus Schmidinger may or may not have written...
[snip]
When I do const char *font_name = "sans-serif"; FcInit();
[snip fontconfig bits]
fprintf(stderr, "font '%s'\n", s);//XXX free(fc_pattern); FcFini();it prints font '/usr/share/fonts/truetype/arial.ttf' which looks good. However, when I use "courier" instead of "sans-serif", I get font '/usr/share/fonts/URW/n022003l.pfb' which is not a truetype font and therefore can't be used with VDR's font rendering.
Why can't it? I was under the impression that freetype could handle Postscript fonts...
[snip]
Klaus Schmidinger wrote:
On 06/10/07 17:53, Anssi Hannula wrote:
... Alternatively, you could use the fontconfig library [1] for managing fonts. This would also allow using using the system default fonts via aliases like 'sans-serif' etc, and using a font list instead of having to manually write the font filename via OSD.
You can get a quick idea from looking at the patch which added fontconfig support for mplayer [2], though of course you should look in fontconfig documentation instead of copying conventions from mplayer :)
[1] http://fontconfig.org/ [2] http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-November/022218.htm...
When I do
const char *font_name = "sans-serif"; FcInit(); FcPattern *fc_pattern = FcNameParse((FcChar8 *)font_name);
While fontconfig is usually configured to ignore bitmap fonts anyway, I think you should enforce that by putting this call here: FcPatternAddBool(fc_pattern, FC_SCALABLE, FcTrue);
FcConfigSubstitute(0, fc_pattern, FcMatchPattern); FcDefaultSubstitute(fc_pattern); fc_pattern = FcFontMatch(0, fc_pattern, 0); FcChar8 *s; FcPatternGetString(fc_pattern, FC_FILE, 0, &s); fprintf(stderr, "font '%s'\n", s);//XXX free(fc_pattern);
Use FcPatternDestroy(fc_pattern) instead, using free() here causes an error for me.
FcFini();it prints
font '/usr/share/fonts/truetype/arial.ttf'
which looks good. However, when I use "courier" instead of "sans-serif", I get
font '/usr/share/fonts/URW/n022003l.pfb'
which is not a truetype font and therefore can't be used with VDR's font rendering.
Hmm... AFAIK it is scalable and freetype can use it. Or is there some another restriction regarding VDR font rendering?
Is there a way to make fontconfig only return truetype fonts?
Also: is there a way to get a list of available truetype fonts from fontconfig? That's what would be needed to allow the user to select a desired font in VDR's Setup/OSD menu.
Gathering from http://www.xemacs.org/Documentation/packages/html/fontconfig_3.html , it can be done with something like this:
// what info is requested: FcObjectSet *os = FcObjectSetBuild(FC_FAMILY, NULL); // what fonts are requested: FcPattern *pat = FcPatternBuild(NULL, FC_SCALABLE, FcTypeBool, FcTrue, NULL); FcFontSet* fontset = FcFontList(0, pat, os); FcObjectSetDestroy(os); FcPatternDestroy(pat); for (int i = 0; i < fontset->nfont ; i++) { FcChar8 *t; FcPatternGetString(fontset->fonts[i], FC_FAMILY, 0, &t); fprintf(stderr, "font '%s'\n", t); } FcFontSetDestroy(fontset);
Note that I am only googling this info, I don't really know about fontconfig myself ;)
Just upgraded from 1.3.xx
Where is the documentation for the new format of runvdr please?
TIA
Tony
On 06/15/07 18:07, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 06/10/07 17:53, Anssi Hannula wrote:
... Alternatively, you could use the fontconfig library [1] for managing fonts. This would also allow using using the system default fonts via aliases like 'sans-serif' etc, and using a font list instead of having to manually write the font filename via OSD.
You can get a quick idea from looking at the patch which added fontconfig support for mplayer [2], though of course you should look in fontconfig documentation instead of copying conventions from mplayer :)
[1] http://fontconfig.org/ [2] http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-November/022218.htm...
When I do
const char *font_name = "sans-serif"; FcInit(); FcPattern *fc_pattern = FcNameParse((FcChar8 *)font_name);While fontconfig is usually configured to ignore bitmap fonts anyway, I think you should enforce that by putting this call here: FcPatternAddBool(fc_pattern, FC_SCALABLE, FcTrue);
Thanks.
FcConfigSubstitute(0, fc_pattern, FcMatchPattern); FcDefaultSubstitute(fc_pattern); fc_pattern = FcFontMatch(0, fc_pattern, 0); FcChar8 *s; FcPatternGetString(fc_pattern, FC_FILE, 0, &s); fprintf(stderr, "font '%s'\n", s);//XXX free(fc_pattern);Use FcPatternDestroy(fc_pattern) instead, using free() here causes an error for me.
FcFini();it prints
font '/usr/share/fonts/truetype/arial.ttf'
which looks good. However, when I use "courier" instead of "sans-serif", I get
font '/usr/share/fonts/URW/n022003l.pfb'
which is not a truetype font and therefore can't be used with VDR's font rendering.
Hmm... AFAIK it is scalable and freetype can use it. Or is there some another restriction regarding VDR font rendering?
Well, I was wrong here. I assumed that Freetype could only handle *.ttf files, but I've explicitly tried /usr/share/fonts/URW/n022003l.pfb now and it works just fine.
Is there a way to make fontconfig only return truetype fonts?
Also: is there a way to get a list of available truetype fonts from fontconfig? That's what would be needed to allow the user to select a desired font in VDR's Setup/OSD menu.
Gathering from http://www.xemacs.org/Documentation/packages/html/fontconfig_3.html , it can be done with something like this:
// what info is requested: FcObjectSet *os = FcObjectSetBuild(FC_FAMILY, NULL); // what fonts are requested: FcPattern *pat = FcPatternBuild(NULL, FC_SCALABLE, FcTypeBool, FcTrue, NULL); FcFontSet* fontset = FcFontList(0, pat, os); FcObjectSetDestroy(os); FcPatternDestroy(pat); for (int i = 0; i < fontset->nfont ; i++) { FcChar8 *t; FcPatternGetString(fontset->fonts[i], FC_FAMILY, 0, &t); fprintf(stderr, "font '%s'\n", t); } FcFontSetDestroy(fontset);
Thanks, I'll give this a shot.
Klaus
Klaus Schmidinger wrote:
On 06/15/07 18:07, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 06/10/07 17:53, Anssi Hannula wrote:
... Alternatively, you could use the fontconfig library [1] for managing fonts. This would also allow using using the system default fonts via aliases like 'sans-serif' etc, and using a font list instead of having to manually write the font filename via OSD.
You can get a quick idea from looking at the patch which added fontconfig support for mplayer [2], though of course you should look in fontconfig documentation instead of copying conventions from mplayer :)
[1] http://fontconfig.org/ [2] http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-November/022218.htm...
When I do
const char *font_name = "sans-serif"; FcInit(); FcPattern *fc_pattern = FcNameParse((FcChar8 *)font_name);While fontconfig is usually configured to ignore bitmap fonts anyway, I think you should enforce that by putting this call here: FcPatternAddBool(fc_pattern, FC_SCALABLE, FcTrue);
Thanks.
Actually, I was wrong here. This won't guarantee anything, as the preference priorities of parameters is predefined, and the family name and, apparently, various other parameters (which are actually left at their defaults) are given a priority over the font being scalable. I was hit with this when trying to select FC_FAMILY "Utopia", and it kept returning the non-scalable version, even though a scalable version with the same name is available.
Solution is given here: http://lists.freedesktop.org/archives/fontconfig/2006-March/002165.html
So it is doable, but you have to use FcFontSort() ( http://www.xemacs.org/Documentation/packages/html/fontconfig_3.html#SEC20 ), which returns a similar FcFontSet as the FcFontList() which is used for the font listing, but this time the fonts are ordered according to the closeness of match, allowing you to pick the first font with FC_SCALABLE being true.
[...]
I don't know if you have noticed / thought of these already, but few tips: - For the fixed-size font list, you can use a match of FC_SPACING being FC_MONO so that non-monospace fonts are not listed. - Have a "default" (or "system default") font setting in the font list, which causes VDR to use the default aliases instead of user-specified font
On 06/16/07 16:29, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 06/15/07 18:07, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 06/10/07 17:53, Anssi Hannula wrote:
... Alternatively, you could use the fontconfig library [1] for managing fonts. This would also allow using using the system default fonts via aliases like 'sans-serif' etc, and using a font list instead of having to manually write the font filename via OSD.
You can get a quick idea from looking at the patch which added fontconfig support for mplayer [2], though of course you should look in fontconfig documentation instead of copying conventions from mplayer :)
[1] http://fontconfig.org/ [2] http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-November/022218.htm...
When I do
const char *font_name = "sans-serif"; FcInit(); FcPattern *fc_pattern = FcNameParse((FcChar8 *)font_name);While fontconfig is usually configured to ignore bitmap fonts anyway, I think you should enforce that by putting this call here: FcPatternAddBool(fc_pattern, FC_SCALABLE, FcTrue);
Thanks.
Actually, I was wrong here. This won't guarantee anything, as the preference priorities of parameters is predefined, and the family name and, apparently, various other parameters (which are actually left at their defaults) are given a priority over the font being scalable. I was hit with this when trying to select FC_FAMILY "Utopia", and it kept returning the non-scalable version, even though a scalable version with the same name is available.
Solution is given here: http://lists.freedesktop.org/archives/fontconfig/2006-March/002165.html
So it is doable, but you have to use FcFontSort() ( http://www.xemacs.org/Documentation/packages/html/fontconfig_3.html#SEC20 ), which returns a similar FcFontSet as the FcFontList() which is used for the font listing, but this time the fonts are ordered according to the closeness of match, allowing you to pick the first font with FC_SCALABLE being true.
[...]
I don't know if you have noticed / thought of these already, but few tips:
- For the fixed-size font list, you can use a match of FC_SPACING being
FC_MONO so that non-monospace fonts are not listed.
- Have a "default" (or "system default") font setting in the font list,
which causes VDR to use the default aliases instead of user-specified font
Since you're apparently getting more and more familiar with this, maybe you could provide a complete code sequence that does this:
- list all available fonts, as in "Arial", "Verdana", "Times New Roman", ...
- optionally list only monospaced fonts
- make sure there are only scalable fonts (i.e. ones that freetype can use)
- if possible, give information on whether a particular font is available as "bold" and/or "italic
From the setup menu I'd like to be able to call a function that delivers
a list of font names (much like it's currently done with the actual font file names) that looks like
Arial Arial:bold Arial:italic Arial:bold:italic Verdana Verdana:bold Verdana:italic ...
I would prepend that list with
sans-serif:bold sans-serif courier:bold
for the three default fonts.
Finally, such a string should be useable to select an actual font file.
Klaus
Klaus Schmidinger wrote:
On 06/16/07 16:29, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 06/15/07 18:07, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 06/10/07 17:53, Anssi Hannula wrote:
... Alternatively, you could use the fontconfig library [1] for managing fonts. This would also allow using using the system default fonts via aliases like 'sans-serif' etc, and using a font list instead of having to manually write the font filename via OSD.
You can get a quick idea from looking at the patch which added fontconfig support for mplayer [2], though of course you should look in fontconfig documentation instead of copying conventions from mplayer :)
[1] http://fontconfig.org/ [2] http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-November/022218.htm...
When I do
const char *font_name = "sans-serif"; FcInit(); FcPattern *fc_pattern = FcNameParse((FcChar8 *)font_name);While fontconfig is usually configured to ignore bitmap fonts anyway, I think you should enforce that by putting this call here: FcPatternAddBool(fc_pattern, FC_SCALABLE, FcTrue);
Thanks.
Actually, I was wrong here. This won't guarantee anything, as the preference priorities of parameters is predefined, and the family name and, apparently, various other parameters (which are actually left at their defaults) are given a priority over the font being scalable. I was hit with this when trying to select FC_FAMILY "Utopia", and it kept returning the non-scalable version, even though a scalable version with the same name is available.
Solution is given here: http://lists.freedesktop.org/archives/fontconfig/2006-March/002165.html
So it is doable, but you have to use FcFontSort() ( http://www.xemacs.org/Documentation/packages/html/fontconfig_3.html#SEC20 ), which returns a similar FcFontSet as the FcFontList() which is used for the font listing, but this time the fonts are ordered according to the closeness of match, allowing you to pick the first font with FC_SCALABLE being true.
[...]
I don't know if you have noticed / thought of these already, but few tips:
- For the fixed-size font list, you can use a match of FC_SPACING being
FC_MONO so that non-monospace fonts are not listed.
- Have a "default" (or "system default") font setting in the font list,
which causes VDR to use the default aliases instead of user-specified font
Since you're apparently getting more and more familiar with this, maybe you could provide a complete code sequence that does this:
list all available fonts, as in "Arial", "Verdana", "Times New Roman", ...
optionally list only monospaced fonts
make sure there are only scalable fonts (i.e. ones that freetype can use)
if possible, give information on whether a particular font is available as "bold" and/or "italic
This function prints all the fonts in a format which can be fed back to FcNameParse(). AFAICS you only need slant+weight or style, use which one you prefer.
int printfonts(bool only_monospace, bool slant_and_weight_instead_of_style) { FcInit(); FcObjectSet *os; if (slant_and_weight_instead_of_style) os = FcObjectSetBuild(FC_FAMILY, FC_SLANT, FC_WEIGHT, NULL); else os = FcObjectSetBuild(FC_FAMILY, FC_STYLE, NULL); FcPattern *pat = FcPatternCreate(); FcPatternAddBool(pat, FC_SCALABLE, FcTrue); if (only_monospace) FcPatternAddInteger(pat, FC_SPACING, FC_MONO); FcFontSet* fontset = FcFontList(NULL, pat, os); FcObjectSetDestroy(os); FcPatternDestroy(pat); for (int i = 0; i < fontset->nfont ; i++) { printf("%s\n", FcNameUnparse(fontset->fonts[i])); } FcFontSetDestroy(fontset); FcFini(); }
Here's a function that prints the font name when inputted with a string outputted by printfonts(), or NULL if not found:
void getfontfilename(char* identifier, char **filename) { FcPattern *pat = FcNameParse((FcChar8*)identifier); FcPatternAddBool(pat, FC_SCALABLE, FcTrue); FcConfigSubstitute(NULL, pat, FcMatchPattern); FcDefaultSubstitute(pat); FcFontSet* fontset = FcFontSort(NULL, pat, FcFalse, NULL, NULL); FcPatternDestroy(pat); FcBool scalable; *filename = NULL; for (int i = 0; i < fontset->nfont; i++) { FcPatternGetBool(fontset->fonts[i], FC_SCALABLE, 0, &scalable); if (scalable) { FcPatternGetString(fontset->fonts[i], FC_FILE, 0, (FcChar8**)filename); break; } } FcFontSetDestroy(fontset); }
From the setup menu I'd like to be able to call a function that delivers a list of font names (much like it's currently done with the actual font file names) that looks like
Arial Arial:bold Arial:italic Arial:bold:italic Verdana Verdana:bold Verdana:italic ...
I would prepend that list with
sans-serif:bold sans-serif courier:bold
Probably monospace:bold instead of courier:bold.
for the three default fonts.
Finally, such a string should be useable to select an actual font file.
On 06/16/07 18:28, Anssi Hannula wrote:
... This function prints all the fonts in a format which can be fed back to FcNameParse(). AFAICS you only need slant+weight or style, use which one you prefer. ...
Thanks, I'll look into this tomorrow.
...
courier:bold
Probably monospace:bold instead of courier:bold.
I tried both, and courier:bold looks a lot better to me (much more like a "typewriter" font).
Klaus
I demand that Klaus Schmidinger may or may not have written...
On 06/16/07 18:28, Anssi Hannula wrote:
[snip]
courier:bold
Probably monospace:bold instead of courier:bold.
I tried both, and courier:bold looks a lot better to me (much more like a "typewriter" font).
That shouldn't be a problem so long as you use monospace as a fall-back... actually, since that's an alias anyway, you should probably just locally define it as being courier :-)
On 06/16/07 23:26, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
On 06/16/07 18:28, Anssi Hannula wrote:
[snip]
courier:bold
Probably monospace:bold instead of courier:bold.
I tried both, and courier:bold looks a lot better to me (much more like a "typewriter" font).
That shouldn't be a problem so long as you use monospace as a fall-back... actually, since that's an alias anyway, you should probably just locally define it as being courier :-)
When I select "courier:bold" it results in "/usr/share/fonts/URW/n022004l.pfb". If I remove the entire URW directory and select "courier:bold" again, I get "/usr/share/fonts/truetype/andalemo.ttf" - which is exactly the same as I get when I select "monospace:bold".
So I see no problem with VDR using "courier:bold" as default.
Klaus
I demand that Klaus Schmidinger may or may not have written...
On 06/16/07 23:26, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
On 06/16/07 18:28, Anssi Hannula wrote:
[snip]
courier:bold
Probably monospace:bold instead of courier:bold.
I tried both, and courier:bold looks a lot better to me (much more like a "typewriter" font).
That shouldn't be a problem so long as you use monospace as a fall-back... actually, since that's an alias anyway, you should probably just locally define it as being courier :-)
When I select "courier:bold" it results in "/usr/share/fonts/URW/n022004l.pfb". If I remove the entire URW directory and select "courier:bold" again, I get "/usr/share/fonts/truetype/andalemo.ttf" - which is exactly the same as I get when I select "monospace:bold".
I get, respectively: /var/lib/defoma/fontconfig.d/N/NimbusMonL-Bold.pfb /var/lib/defoma/fontconfig.d/B/Bitstream-Vera-Sans-Mono-Bold.ttf
These are symlinks to /usr/share/fonts/type1/gsfonts/n022004l.pfb /usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoBd.ttf which are supplied by gsfonts and ttf-bitstream-vera.
So I see no problem with VDR using "courier:bold" as default.
I, OTOH, see no problem with it using "monospace:bold" as default; allowing it to be set as a compile-time option should be sufficient, though. Otherwise it's patch time :-)
On 06/17/07 15:27, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written... ...
So I see no problem with VDR using "courier:bold" as default.
I, OTOH, see no problem with it using "monospace:bold" as default; allowing it to be set as a compile-time option should be sufficient, though. Otherwise it's patch time :-)
What's so important about this default? After all, it's a user setting, so you can always set it to anything you personally like...
Klaus
Am Sonntag, 10. Juni 2007 15:45 schrieb Klaus Schmidinger:
VDR developer version 1.5.3 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.3.tar.bz2
Now I'm running this version. And I would say: Converting of EPG to UTF-8 don't work My system has DVB-T card and I'm receiving only German "ÖRP" In schedule menuitem I can't see any umlaut or "ß" $LANG is setting to en_US.UTF-8 For my stable version 1.4.x I'm using UTF patch from Alexander Riedel. As I remember he has inserted extra field for channel codepage. And this works.
Regards Oleg Roitburd
On 06/11/2007 10:08 AM, Oleg Roitburd wrote:
Am Sonntag, 10. Juni 2007 15:45 schrieb Klaus Schmidinger:
VDR developer version 1.5.3 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.3.tar.bz2Now I'm running this version. And I would say: Converting of EPG to UTF-8 don't work My system has DVB-T card and I'm receiving only German "ÖRP" In schedule menuitem I can't see any umlaut or "ß" $LANG is setting to en_US.UTF-8
Please check whether the log says that the codeset is "known" (should be right after VDR's startup message).
You may need to set LANG=en_US.utf8 (without the '-'). Maybe the strings in libsi/si.c should contain the extra '-'s, not sure what's best.
All I can say is that this works just fine here.
For my stable version 1.4.x I'm using UTF patch from Alexander Riedel. As I remember he has inserted extra field for channel codepage. And this works.
Using such an extra field is not the way to go, because there is no standard way to fill it in (or is there?).
Klaus
Am Montag, 11. Juni 2007 10:14 schrieb Klaus Schmidinger:
On 06/11/2007 10:08 AM, Oleg Roitburd wrote:
$LANG is setting to en_US.UTF-8
Please check whether the log says that the codeset is "known" (should be right after VDR's startup message).
yes...you are right Jun 11 10:10:53 compaq vdr: [18482] VDR version 1.5.3 started Jun 11 10:10:53 compaq vdr: [18482] codeset is 'UTF-8' - unknown
You may need to set LANG=en_US.utf8 (without the '-'). Maybe the strings in libsi/si.c should contain the extra '-'s, not sure what's best.
All I can say is that this works just fine here.
OK. this works LANG=en_US.utf8 ./vdr -c /etc/vdr -P"softdevice -vo xv:" I would say, vdr need better recognizing of locales (eliminated of "-" and tolower())
For my stable version 1.4.x I'm using UTF patch from Alexander Riedel. As I remember he has inserted extra field for channel codepage. And this works.
Using such an extra field is not the way to go, because there is no standard way to fill it in (or is there?).
Automagicaly it was ever filled with iso8859-15, for all other codepages was handmade job
Regards Oleg Roitburd
Klaus Schmidinger wrote:
On 06/11/2007 10:08 AM, Oleg Roitburd wrote:
Am Sonntag, 10. Juni 2007 15:45 schrieb Klaus Schmidinger:
VDR developer version 1.5.3 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.3.tar.bz2Now I'm running this version. And I would say: Converting of EPG to UTF-8 don't work My system has DVB-T card and I'm receiving only German "ÖRP" In schedule menuitem I can't see any umlaut or "ß" $LANG is setting to en_US.UTF-8
Please check whether the log says that the codeset is "known" (should be right after VDR's startup message).
You may need to set LANG=en_US.utf8 (without the '-'). Maybe the strings in libsi/si.c should contain the extra '-'s, not sure what's best.
$ LC_ALL=en_US.utf8 locale collate-codeset UTF-8
so the canonical spelling is "UTF-8". As already suggested using nl_langinfo() instead of manually parsing enviroment variables is probably the better choice though.
For my stable version 1.4.x I'm using UTF patch from Alexander Riedel. As I remember he has inserted extra field for channel codepage. And this works.
Using such an extra field is not the way to go, because there is no standard way to fill it in (or is there?).
ACK, considering that libsi can automatically determine the encoding for individual strings it seems to be awkward having to specify encodings per channel in channels.conf.
cu Ludwig
On 06/11/2007 11:27 AM, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
On 06/11/2007 10:08 AM, Oleg Roitburd wrote:
Am Sonntag, 10. Juni 2007 15:45 schrieb Klaus Schmidinger:
VDR developer version 1.5.3 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.3.tar.bz2Now I'm running this version. And I would say: Converting of EPG to UTF-8 don't work My system has DVB-T card and I'm receiving only German "ÖRP" In schedule menuitem I can't see any umlaut or "ß" $LANG is setting to en_US.UTF-8
Please check whether the log says that the codeset is "known" (should be right after VDR's startup message).
You may need to set LANG=en_US.utf8 (without the '-'). Maybe the strings in libsi/si.c should contain the extra '-'s, not sure what's best.
$ LC_ALL=en_US.utf8 locale collate-codeset UTF-8
so the canonical spelling is "UTF-8". As already suggested using nl_langinfo() instead of manually parsing enviroment variables is probably the better choice though.
Thanks, I'll change it then.
For my stable version 1.4.x I'm using UTF patch from Alexander Riedel. As I remember he has inserted extra field for channel codepage. And this works.
Using such an extra field is not the way to go, because there is no standard way to fill it in (or is there?).
ACK, considering that libsi can automatically determine the encoding for individual strings it seems to be awkward having to specify encodings per channel in channels.conf.
The latest version of libsi does use the character encodings specified in the SI data for each string. Unfortunately, though, a certain German pay tv broadcaster doesn't adhere to the standard and sends the data in iso8859, but without marking the strings accordingly. So VDR assumes that they are ISO6937 (which is the default if no encoding is specified) and therefore converts the umlauts to garbage. But that's their fault, not VDR's...
Klaus
Klaus Schmidinger wrote:
The latest version of libsi does use the character encodings specified in the SI data for each string. Unfortunately, though, a certain German pay tv broadcaster doesn't adhere to the standard and sends the data in iso8859, but without marking the strings accordingly. So VDR assumes that they are ISO6937 (which is the default if no encoding is specified) and therefore converts the umlauts to garbage. But that's their fault, not VDR's...
How do standalone dvb receivers deal with that? Do they have an extra workaround for that particular broadcaster?
cu Ludwig
On 06/11/2007 11:50 AM, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
The latest version of libsi does use the character encodings specified in the SI data for each string. Unfortunately, though, a certain German pay tv broadcaster doesn't adhere to the standard and sends the data in iso8859, but without marking the strings accordingly. So VDR assumes that they are ISO6937 (which is the default if no encoding is specified) and therefore converts the umlauts to garbage. But that's their fault, not VDR's...
How do standalone dvb receivers deal with that? Do they have an extra workaround for that particular broadcaster?
I guess they do, because they need to be "certified for P*******" ;-)
Klaus
-
Anssi Hannula -
Darren Salt -
Klaus Schmidinger -
Ludwig Nussel -
Oleg Roitburd -
Rolf Ahrenberg -
Tony Grant -
VDR User