[vdr] Re: ANNOUNCE: patches for graphlcd-0.1.2-pre5 freetype2 runtime rendering + complete romanian i18n

[Lucian Muresan]

Lucian Muresan wrote:
...
> P.S. @Andreas, I'll post another more technical one.

Hi Andreas, some more about the patches & further fine-tuning:

- I added some $(DESTDIR) all over in the Makefiles of graphlcd-base, 
they're required for letting Gentoo's portage system build the library 
and do not hurt otherwise (normal, manual build & install works same as 
before);
- Some new methods:
   - cConfig::GetConfigIdx(...) for easily getting a configuration by 
it's name, I needed this in another project;
   - cFont::LoadFT(...) -> new for freetype rendering into the native 
structure, with a specified character encoding in form of "iso8859-1" 
and such. There also is a bool parameter to enforce fixed width in all 
characters (usefull for LCDproc), and another one to actually completely 
ignore encoding (for rendering webdings.ttf, wingdings.ttf, the 
so-called "dingbats", also needed for LCDproc, and normally they're bot 
not used and default initialized on false;
   - cFont::SetCharacter(char ch, cBitmap * pBitmap) (opposite of 
GetCharacter, comes very handy in LoadFT and also in LCDproc)
   - cFont::Save(...) - saves (I hope so) in the native format, you 
might give it a try together with SetCharacter in the genfont utility or 
such...
   - cFont::Init() does the initialization needed in the constructor and 
is also needed in Unload();
   - cFont::Unload() does a cleanup of the internal bitmap array, it 
then calls Init(). They are both protected as they're just for internal 
use and already called in the constructor, destructor and Load(FT)(...) 
right at their beginning, this way we can think of runtime reloading of 
fonts.

- My modifications to the plugin code are minimal, and only tested on my 
display size.
- What do you think of the possibility to dynamically reload a new font 
size after altering the value in the configuration menu? Where could 
this be triggered and how? Calling LoadFT(..) on the 3 font objects 
should be enough, but in that time the display should be prevented from 
updating itself. I think if we could have this as a next step, then 
finding the best solutions for the layout in different display sizes 
might be easier, as one can immediately see the results of size 
modifications and then think about corrections in the 
cGraphLCDDisplay::Display... methods.
- I agree with you, that rendering small sizes doesn't look good. But it 
also depends on the font files, and I also think we could be even more 
flexible and mix the font types used in the plugin, for example to use 
the raster font for the small font, too.
- I noticed a problem which I can't track down, the space character is 
way too narrow when rendered directly from freetype. I tried to 
compensate for this in cFont::LoadFT(...) but it doesn't seem to help, 
either I have a bug there, or I don't know, there are more things I did 
not fully understand in the plugin code, in display.c
- Do you already have an idea when you'll be ready to release the 
library in a more "official" manner? BTW, the graphlcd-base package I 
downloaded right after your last announce, contained itself one more 
time in the root directory, an also genfont object and binary (maybe due 
to HAVE_FREETYPE2 setting the 'make clean' invoked by 'make dist' 
ignored it, maybe you ran "make dist" twice, now the file is more than 
double sized as it should.

So what do you think of all this? I'll wait for your feedback before 
messing around more with the plugin code, and rather finish the LCDproc 
driver based on the graphlcd-base library. I hope you're not going to 
change it much ;-)

Best regards,
Lucian