LCDproc development and user support list

Text archives Help

[Lcdproc] Re: new LCDproc-0.5 "meta"-driver soon

Chronological Thread 
  • From: lucianm AT (Lucian Muresan)
  • Subject: [Lcdproc] Re: new LCDproc-0.5 "meta"-driver soon
  • Date: Tue Jan 25 13:06:02 2005

Hi Joris,

thank you for your answer!

> Interesting. I'm also still looking for an easy fontsystem (which should
> include a _very_ small font) for SED1330. FreeType is good for you ? (don't
> know how it's used)

I just started to mess with FT2 few days ago, after finding how another
two VDR plugins ( graphtft and text2skin for those interested) are
rendering bitmap fonts usable by them and VDR itself out of the FT2
library at runtime, once at initialization. After figuring out how to
use the FT2 library (actualy the tutorial which I fully read just this
morning is a very good and fairly short introduction) I think it's not
too dificult to use. But I still have to see how reliable my code can
get in order to let the user of graphlcd-base / LCDproc the freedom to
choose some TTF font to load at startup without having strange looking
fonts on the display (that's the status at present, I've seen the first
garbled fonts rendered from freetype this morning before heading to
work, but I know for sure I have massive pixel misalignements in that
code, as I haven't fully read the tutorial until after this, today, so
I'ts very clear to me it's doable).
I will also write a little utility to render bitmap fonts with freetype,
and even provide the custom LCDproc icons and save them in the original
graphlcd non-freetype Format, this way the font files are very small,
and if I provide such fonts with my driver, one doesn't have to
necessarily compile graphlcd-base and the glcdlib wrapper with FreeType
If your question was if it's possible to render a font size small enough
in a bitmap format from a FreeType source, I haven't checked that yet,
but will try it for sure, as I'm interested too, will keep you informed.
Anyway, I decided on using FreeType2 either as a way to create readily
available fonts, or even more flexible, to load TTF and render them at
runtime because I wanted to be able to use different character encodings
and the fonts provided so far by graphlcd-base just implement western
encoding, and I'm interested in ISO8859-2, and one can then use any
encoding available in Fonts supported by FreeType2. I think that with
this font loading mechanism even stuff like BigNums and icons in LCDproc
can be simplified (for bignums, simply render numbers from bigger font,
and for the icons I could either draw them with the primitives provided
in libglcdgraphics every time at runtime, depending on the font size, or
alternatively, store them in the bitmap font format for the variant
whithout FreeType at runtime.

> I guess the 2 or 3 exta packages should be compiled separately, not by
> LCDproc.
> Because they probably also have their own configuring system.

Ok, then that way it will be.

> That's a long time ago that I've done that. I've read some things onm the
> net
> about the autoconf/make system and after a couple of tries I got it
> working. I
> would say just try to act as if you're only creating a driver. If you don't
> have too many source files, all can stay within the driver directory.
> That's at
> least the simplest solution.

I will then try to write the detection scripting just for my wrapper
library used by the glcdlib driver which is just two files like most
native LCDproc drivers and let the library itself take care of it's own
dependencies as you agreed on.

>>it's size if using FreeType2. Concerning this, are there any
>>"standard" LCDproc display sizes (in fixed width characters) I should
>>enforce in my
> 16x1
> 16x2
> 16x4
> 20x2
> 20x4
> 40x2
> 40x4
> But any size works for the daemon, the problem is usually that most clients
> can't generate nice screens for all screen sizes.

Yes, I noticed that when I first wrote a native LCDproc driver for my
128x64 pixels Noritake800 which yielded in a character display size of
21x8 (I wrote it months ago, but the code is far too messy to be
submitted) and I had to patch the client which I wanted to use at that
time (Freevo lcdproc plugin). This is an issue I have to give further


Archive powered by MHonArc 2.6.18.

Top of page