Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 :-) -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING. Worse things happen in C. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 :-) -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Output *more* particulate pollutants. BUFFER AGAINST GLOBAL WARMING. D BREAK - CONT repeats, 0:1 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
Klaus Schmidinger wrote: > On 06/16/07 18:28, Anssi Hannula wrote: >> ... >>> 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). Fine then :) -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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.html
> 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
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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) > -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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.html 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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.html >>> 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 -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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.html
>> 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
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
Just upgraded from 1.3.xx Where is the documentation for the new format of runvdr please? TIA Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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.html
>
> 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 ;)
--
Anssi Hannula
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES. Your mode of life will be changed to ASCII. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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.html 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
On 06/12/07 07:12, VDR User wrote: > On 6/10/07, Rolf Ahrenberg <[EMAIL PROTECTED]> 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
On 6/10/07, Rolf Ahrenberg <[EMAIL PROTECTED]> 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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.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 >> 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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.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 > > 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 -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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.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 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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.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
>
>> - 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
--- PLUGINS/src/skincurses/Makefile 2006/09/09 12:38:35 1.7
+++ PLUGINS/src/skincurses/Makefile 2007/06/10 16:19:08
@@ -66,7 +66,7 @@
all: libvdr-$(PLUGIN).so
libvdr-$(PLUGIN).so: $(OBJS)
- $(CXX) $(CXXFLAGS) -shared $(OBJS) -lncurses -o $@
+ $(CXX) $(CXXFLAGS) -shared $(OBJS) -lncursesw -o $@
@cp --remove-destination $@ $(LIBDIR)/[EMAIL PROTECTED](APIVERSION)
dist: clean
--- PLUGINS/src/skincurses/skincurses.c 2006/09/10 14:23:55 1.11
+++ PLUGINS/src/skincurses/skincurses.c 2007/06/10 16:18:17
@@ -6,6 +6,8 @@
* $Id: skincurses.c 1.11 2006/09/10 14:23:55 kls Exp kls $
*/
+//XXX TODO strlen()!
+
#include
#include
#include
@@ -19,12 +21,10 @@
class cCursesFont : public cFont {
public:
- cCursesFont(void): cFont(NULL) {}
- virtual int Width(unsigned char c) const { return 1; }
+ virtual int Width(uint c) const { return 1; }
virtual int Width(const char *s) const { return s ? strlen(s) : 0; }
- virtual int Height(unsigned char c) const { return 1; }
- virtual int Height(const char *s) const { return 1; }
virtual int Height(void) const { return 1; }
+ virtual void DrawText(cBitmap *Bitmap, int x, int y, const char *s, tColor ColorFg, tColor ColorBg, int Width) const {}
};
static const cCursesFont Font;
@@ -135,6 +135,8 @@
void cCursesOsd::DrawText(int x, int y, const char *s, tColor ColorFg, tColor ColorBg, const cFont *Font, int Width, int Height, int Alignment)
{
+ if (!s)
+ return;
int w = Font->Width(s);
int h = Font->Height();
if (Width || Height) {
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 - ). > 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.html > > I'd like to keep it simple. There's a directory with font file names and these > will be offered in Setup/OSD. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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 - ). 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.html I'd like to keep it simple. There's a directory with font file names and these will be offered in Setup/OSD. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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.html -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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.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 > >> - 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
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.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 > - 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.5.3
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
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
