Lucian Muresan wrote: > 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. No problems with that. I've already added this functions to my code base, some with modifications, especially in LoadFT (see below). I don't know if it is really necessary to have a fixed width parameter, because the rendering methods in cBitmap already support this. What do you think? > - 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. The fonts (and their sizes in case of ft2) will be specified in a file fonts.conf (or similar) that is located in the graphlcd directory structure. Their sizes will be changeable through setup menu in case of ft2 loaded fonts as this would make finding the right sizes for your lcd much easier. > - 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. Yes, it is no problem to mix them. > - 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 I've changed the font loading to the way it's done in genfont. The main difference is that I use advance.x as the width of the character, so font spacing is already covered by that. The bitmap that freetype2 generates is only as width as the active pixels of the character, so bitmap.width is zero for the space character. > - 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. In the next prerelease of the package the libraries will be in a relatively stable state. This will also be the latest prerelease of the 0.1.2 version if there are no big problems. Andreas
