ANNOUNCE: patches for graphlcd-0.1.2-pre5 freetype2 runtime rendering + complete romanian i18n
Hi,
I finished reworking my FT2 patches against the latest pre-release of graphlcd. Of course, you must have a freetype-2.1.x library installed, and some TTF fonts if you want to try this.
Those who want to try this, please:
1. Download the library patch from http://www.muresan.de/graphlcd/vdr/graphlcd-base-0.1.2-pre5_FT2.diff.bz2 and patch graphlcd-base after running a dos2unix over ./graphlcd-base-0.1.2-pre5/glcddrivers/serdisp.c ./graphlcd-base-0.1.2-pre5/glcddrivers/serdisp.h first.
2. After patching, HAVE_FREETYPE2=1 is already defined in Make.config so there is no need to enable it by yourself. Follow the normal instructions provided in the package to build & install.
3. Download the plugin patch from http://www.muresan.de/graphlcd/vdr/vdr-graphlcd-0.1.2-pre5_FT2.diff.bz2 and patch the original plugin vdr-graphlcd-0.1.2-pre5.tgz
4. Before proceeding with building and installing as you normally would, mkdir ./graphlcd-0.1.2-pre5/graphlcd/fonts/ttf and then make 3 symlinks in that newly created directory (in the source tree of the plugin, then they will be copied upon installing) pointing to actual TTF files on your machine (it could even be the same file if you wish, you will play with the size and the actual symlinks to different fonts later), with these names: ./graphlcd-0.1.2-pre5/graphlcd/fonts/ttf/fLarge.ttf -> /usr/share/fonts/corefonts/trebucbd.ttf ./graphlcd-0.1.2-pre5/graphlcd/fonts/ttf/fNormal.ttf -> /usr/share/fonts/corefonts/trebuc.ttf ./graphlcd-0.1.2-pre5/graphlcd/fonts/ttf/fSmall.ttf -> /usr/share/fonts/corefonts/trebuc.ttf
5. Install & build like you normally would
Notes about usage =================
- Start VDR with the graphlcd plugin (you should still see the native fonts on your display at this time if you didn't mess with VDR's setup.conf already), go to it's configuration menu and enable true type fonts, then you have to close and start again (I hope this won't be necessary in future versions, I already took first steps in preparing the cFont class in the library for this). After restarting you will hopefully already see the TTF you've symlinked to on your display. You now may go again to the graphlcd configuration menu and adjust the sizes of the three fonts (theese options appear only when the plugin is started with graphlcd.UseFreeType2Fonts = 1 which is reated after your first run), unfortunately you have to restart every time to see the results of the size modification. You may also manually alter the entries in VDR's setup.conf while VDR is not running, that might be quicker, here are my settings I use with the symlinked fonts above on a 128x64 display (almost perfect results) graphlcd.UseFreeType2Fonts = 1 graphlcd.FreeType2SizeLarge = 11 graphlcd.FreeType2SizeNormal = 10 graphlcd.FreeType2SizeSmall = 9 If you want to revert to the native bitmap fonts, just set UseFreeType2Fonts = 0 in the file or in the configuration menu.
- the character encoding is automatically selected according to VDR's OSD language, there is no separate option right now.
- I only tested the FT2 stuff on my 128x64 display and it's not perfect even there, so expect strange layouts, but please try it and report.
Have phun!
Lucian Muresan
P.S. @Andreas, I'll post another more technical one.
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
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
Andreas Regel wrote: ...
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?
You mean the bool prop(ortional) in cBitmap::DrawText, right? I guess you're right, I did a quick test today in my LCDproc driver and it works that way, 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
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.
Ok, I'm looking forward to see it, as I currently have very few time for trying this myself. I'll wait for your next prerelease ;-).
- 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.
Great!
Lucian
-
Andreas Regel -
Lucian Muresan