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
