Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#8961 - Anti-Aliased Fonts

Attached to Project: Rockbox
Opened by Jack Suter (chrisjs169) - Sunday, 04 May 2008, 23:09 GMT+2
Task Type Patches
Category Font/charset
Status Unconfirmed
Assigned To No-one
Player Type All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Private No

Details

Scorche had confirmed in http://forums.rockbox.org/index.php?topic=16612.0 that it was OK to post this patch.

The primary bug that I have noticed is that the line selector's height appears to be bigger than it should be. Thomas Martitz (kugel.) and I had spent a day testing convfnt (where the problem is) and could find a completely working solution.

Another bug is some fonts (such as http://rbthemes.com/fonts/saved/Matttsro_15.aa.fnt) have issues with some characters, such as G and J in Matttsro.

In case there's any confusion, anti-alias_fonts.patch is added to the build to allow AA fonts to be used, while convttf is the program to convert the fonts (with Makefile_convttf being used to compile convttf).
   anti-alias_fonts.patch (14.3 KiB)
 firmware/drivers/lcd-16bit.c |  282 ++++++++++++++++++++++++++++++++++++++++++-
 firmware/export/font.h       |    3 
 firmware/font.c              |   14 +-
 tools/convbdf.c              |    1 
 4 files changed, 291 insertions(+), 9 deletions(-)

   convttf.c (15.6 KiB)
   Makefile_confttf (0.7 KiB)
This task depends upon

Comment by Thomas Martitz (kugel.) - Monday, 05 May 2008, 19:51 GMT+2
Great! I waited for the confirmatio like half of a year now.

There're indeed some glitches. For example, FreeSans has some issues with the slash.

Some times glitches disappear with changing the font size.

But, the important thing: I couldn't find any backdraw regarding non-anti-aliased fonts. I couldn't notice any slow downs or something. Also, the rendering of AAF feels like being equally fast.

PS: I remember jott told, that he optimized the the font rendering of the classic fonts a bit too with this patch.
Comment by Tri Nguyen (tri170391) - Sunday, 18 May 2008, 07:49 GMT+2
This is a quick and dirty fix for the mpegplayer font problem, it just use sysfont instead of UI font for drawing the WVS.
   mpegplayerfix.patch (1 KiB)
 mpegplayer.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Comment by Taktak (Whick) - Wednesday, 06 August 2008, 09:28 GMT+2
What a nice invention it is!
But it does't work well for most Japanese fonts.

I fixed the problems for converting 2byte fonts and so on.
It has been able to deal with most fonts.

I add a usage for ttc(true type collection) then.(A TTC file is a collection of TTFs)

Additional part of Usage:
-c N Character separation in pixel.Insert space between characters
-r N Row separation in pixel.Insert space between lines.

following option is for TTC fonts.
-tt Display the True Type Collection tables available in the font
-t N Index of internal font index of true type collection.
It must be start from 0.(default N=0).
-ta Convert all fonts in ttc
"-o output-file" specified is ignored when "-ta" is specified.

Could anybody polish out the source and usage?
   convttf.c (31.3 KiB)
Comment by Tri Nguyen (tri170391) - Saturday, 09 August 2008, 11:12 GMT+2
Taktak, your converter somehow ignore white space character. Making textbooks almost unreadable, as you can see in this screendump.
Comment by Taktak (Whick) - Saturday, 09 August 2008, 14:49 GMT+2
It's commic sans serif isn't it?


I altered the method of deciding the width of the character for some fonts.
(I use "face->glyph->bitmap.pitch" instead of "face->glyph->metrics.horiAdvance >> 6" for some free fonts.)

But I apologize its influencing some font and
altered the "method of deciding the width" AS SAME AS FORMER.

But I 'll pick out other method sometime soon for Both fonts.
Comment by Taktak (Whick) - Saturday, 09 August 2008, 15:21 GMT+2
I forgot to attach this. The method of deciding the width is ALMOST same as former uploaded by chrisjs169.
Comment by Taktak (Whick) - Sunday, 10 August 2008, 20:45 GMT+2
I altered the way of deciding the width again.
   convttf.c (31.3 KiB)
Comment by Thomas Martitz (kugel.) - Monday, 11 August 2008, 15:21 GMT+2
The converter is not working for me. I tried both, the ones you attached on the 9th and 10th of August. I'm using the patch version from the first post.

I compiled it using Makefile attached in the first post. The resulting fonts are 10x bigger than the ones which I get with the very first converter. Also, they show nothing (no glyphs) on my target and pixel garbage on the sim.

Do I need to compile it in some special way?
Comment by Taktak (Whick) - Monday, 11 August 2008, 16:19 GMT+2
10x bigger? Is "10x" in file-size?(or glyph bitmap size?) I'm sorry for that.
I want to try it recently. What font are you converting? Please tell me one of them.

You don't need any special way.
Comment by Thomas Martitz (kugel.) - Monday, 11 August 2008, 16:25 GMT+2
Filesize. I tried to convert Bitstream Vera and FreeSans, both didn't work.
Comment by Tri Nguyen (tri170391) - Monday, 11 August 2008, 16:30 GMT+2
It works with Arial, Arial Unicode MS (which fail with the original converter), and Comic Sans in my case. I'm using the 9th August converter.
Comment by Taktak (Whick) - Monday, 11 August 2008, 18:16 GMT+2
Because of the difference of font-file-size is bug in first version.
(I downloaded it form ftp://ftp.mplayerhq.hu/MPlayer/contrib/fonts/arialuni.ttf.bz2)
Please try to use otf2bdf if you could. Arialuni has 38911 glyphs.
Third version I upload output 38906.(Because that throw away some fonts which has zero-width)

First version seems output 51031 gyphs but output many many empty glyph and can't output all-glyphs.

I sent you mail desription of them.
Comment by Thomas Martitz (kugel.) - Monday, 11 August 2008, 18:30 GMT+2
I don't understand.
Comment by Taktak (Whick) - Monday, 11 August 2008, 18:42 GMT+2
Sorry, I 'll explain that with some debug-log tomorrow.
Comment by Thomas Martitz (kugel.) - Monday, 11 August 2008, 18:47 GMT+2
So, why does it not work for me/the fonts I used? They are ttf's and I just did

"make -f Makefile_convttf"
then
"./convttf Vera.ttf"

The resulting file is ~20KB big with the first version of the converter, the filesize using your versions is above 200KB.
Comment by Taktak (Whick) - Tuesday, 12 August 2008, 11:35 GMT+2
I'm sorry for that My bad English must prevent your understanding.

on my platform,
1st version version output those file
comic_15_[4bpp].fnt 55.71KB
arialuni_15_[4bpp].fnt 8.74MB
arial_15_[4bpp].fnt 179.05KB

and 3rd version output those file
comic_15_[4bpp].fnt 248.39KB
arialuni_15_[4bpp].fnt 6.58MB
arial_15_[4bpp].fnt 442.18KB
(I don't have Vera.ttf font and File Size according to each platform maybe)

Because of the difference in each file size between 1st and 3rd version
is that 1st version losses some glyph always. I will prove that.
You can see the fact through following action.

I just added SAME outputting-log-code to both versions.(1st and 3rd)
to prove it.
(off course, you need to rename those file into convttf.c to build them yourself)

These program output log files like following that.
example.
------------------------------------------------
Filename:arialuni_15_[4bpp].log (add ".log" to fnt base name)
contents:
code=0 size = 120
code=1 size = 240
code=2 size = 360
------------------------------------------------
Comment by Taktak (Whick) - Tuesday, 12 August 2008, 11:36 GMT+2
The Log2CheckFile.exe I attached can turn these log-file into textFile
for confirming if whether the font is created correctly.
example.:
------------------------------------------------
Filename:arialuni_15_[4bpp].log.txt (add ".log" to input file)
contents:(it'll be encoded in UTF8)
Code=0x20(32) Character=" " FontBitSize=48
Code=0x21(33) Character="!" FontBitSize=96
Code=0x22(34) Character=""" FontBitSize=156
------------------------------------------------
(of. Code means character code)
Comment by Taktak (Whick) - Tuesday, 12 August 2008, 11:37 GMT+2
I was wrong , file name in example, Filename:arialuni_15_[4bpp].txt (not log.txt)
Comment by Taktak (Whick) - Tuesday, 12 August 2008, 11:37 GMT+2
Please change your editor font to each font to confirm
and read "*.log.txt" Log2CheckFile created .

You can see how 1st version lost glyph.

While you test that, need to change your "default code page" to "UTF-8".

By the way you can describe "-s" and "-l" options
if you want to font size more decrease.

If you only use English character and don't need any Greek and special symbol and foreign character,
I recommend that you use 3rd version and describe "-s 32 -l 255" options at first
You may decrease font size.

I can effort to explain the further cause if you need and will fix any bug found.
Comment by Thomas Martitz (kugel.) - Tuesday, 12 August 2008, 11:42 GMT+2
Well, I personally don't care much about font size. If it losses glyphs, you may be right.

The problem is, that the fonts I get with your converter don't work.
Comment by Taktak (Whick) - Tuesday, 12 August 2008, 12:03 GMT+2
I'm sorry ,Kugel.
All of fonts don't work don't they?  Could you try it on your device?
   mona.zip (454.6 KiB)
Comment by Taktak (Whick) - Tuesday, 12 August 2008, 12:09 GMT+2
Sorry, Could you try this font on your device? ( not "it" )
Comment by Taktak (Whick) - Tuesday, 12 August 2008, 12:19 GMT+2
I'm sorry that I altered Makefile_confttf!
from "-O -ansi -Wall -g"
to "-O -Wall -g"

I don't change "anti-alias_fonts.patch"
Comment by Thomas Martitz (kugel.) - Tuesday, 12 August 2008, 15:24 GMT+2
Thanks, with the Makefile it seems to work. I think the 10th August version works better than the 9th one.
Comment by Thomas Martitz (kugel.) - Wednesday, 13 August 2008, 01:24 GMT+2
Hey. This version just removes the depth stuff from the converter. It's been removed from the anti-aliased_fonts patch a long time ago (i.e. fixed to 4 bit fonts).

It's based on the 10th August version, which yields best results imo.

Whick, it would be very nice, if you could also look into the height deciding too. The fonts vary very much in the line height. The glyphs seem to be equally high, but the line height varies (i.e. the selection bar is bigger). This means, with e.g. FreeSans (13px) I get 10 lines on a certain theme, while Nimbus Sans L (13px) only gives 8. There's a noticeable space between the lines using Nimbus Sans L, while the space between the lines is almost non-existing using FreeSans.
   convttf.c (30.3 KiB)
Comment by Thomas Martitz (kugel.) - Wednesday, 13 August 2008, 02:10 GMT+2
1 issue I've noticed: The w, v and y in Bitstream Vera are too wide. There's a noticeable space between those and the character to its right. I didn't notice that on any other font though (or any other character in Vera), so I'm not sure how to fix it.
Comment by Taktak (Whick) - Wednesday, 13 August 2008, 05:30 GMT+2
> i.e. the selection bar is bigger

I think really so. But you'd better stop modifying the height.
Please read attached text-files encoded in UTF8 and find following line.by your editor and each font.
Don't fogot to set "default codepage" or "encoding setting" of your editor to "UTF8".

Code=0x162(354) Character="Ţ"
Code=0x164(356) Character="Ť"
Code=0x174(372) Character="Ŵ"
Code=0x160(352) Character="Š"
Code=0x192(402) Character="ƒ"

Umlaut letters and some simbolic characters need enough height.

By the way,did you make your Vera.fnt from Vera.ttf as same as
being able to be downloaded from following site?
http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/
It doesn't seems too high for me but comic.fnt seems too high!

A way to modify the height is
finding max top line and min bottom line of selected fonts dynamically
(only if "-s" or "-l" options are described?)

Other way is describe "-r" option and set munus value though I didn't try to set munus value.
Ah, "min bottom line" and "min bottom" line isn't correctly expression. But I expect you of understanding it.
Comment by Taktak (Whick) - Wednesday, 13 August 2008, 05:55 GMT+2
Sorry, Stll, I found the need to modify deciding height.
I'll try to delete noticeable and extra space in this Text-file.
Comment by Taktak (Whick) - Wednesday, 13 August 2008, 06:46 GMT+2
Though this is only temporary way. Look into the following code.
"export_font.header.height = (face->size->metrics.ascender - face->size->metrics.descender + (2 << 6)) >> 6;"

I think this coce " + (2 << 6)" to create space is not necessary still now.
That's why users can describe "-r" option for now if the space increasing between lines IS necessary.

I delete above code to create space and modify usage-string (for default output filename).
Could you modify usage more naturally please.
But this modification is quite not enough, you know.
   convttf.c (30.2 KiB)
Comment by Taktak (Whick) - Thursday, 14 August 2008, 13:40 GMT+2
> Whick, it would be very nice, if you could also look into the height deciding too.

Kugel, I think I 've done. Do you mind if I ask to confirm it?

I altered the way of diciding height of each characters selected by -s, -l option.
and fixed bug about line height.

You can see it if you compare outputs from these command line.

(A) ./convttf -s 32 -l 128 -o comic_alnum_15.fnt comic.ttf
gotten with this version.( options to create alphabet , number ,and some symbolic characters)

(B) ./convttf -o comic_15.fnt comic.ttf
gotten with this version

(C) ./convttf -o comic_old_15.fnt comic.ttf
gotten with old version

(D) ./convttf -r -4 -o comic_minus_15.fnt comic.ttf
gotten with this version


"-r 4" option adds 2 extra space(pixelline) at the bottom
and adds 2 extra space(pixelline) at the top

"-r -4" option CUTS 2 pixelline from fonts area from the top
and cuts 2 pixelline from fonts area from the bottom.
Comment by Taktak (Whick) - Friday, 15 August 2008, 08:31 GMT+2
alternated deciding height again.
   convttf.c (35.5 KiB)
Comment by Thomas Martitz (kugel.) - Friday, 15 August 2008, 12:28 GMT+2
I can't compile atm. I cannot confirm until sunday.
Comment by Taktak (Whick) - Thursday, 21 August 2008, 10:15 GMT+2
I had written some irrelevant test code ,and deleted it now.

> I can't compile atm. I cannot confirm until sunday.
no matter when if you will do.
   convttf.c (35.4 KiB)
Comment by Johan Swetzén (jswetzen) - Tuesday, 16 September 2008, 23:06 GMT+2
I have fond one problem with this patch: the built-in default font becomes absolutely unreadable! I'm just wondering if anyone else has had similar problems, or am I the only one? I'm using an 30GB iPod 5G.
Attached is a screenshot of the text input plugin, the problem is really obvious here.
Comment by Tri Nguyen (tri170391) - Wednesday, 17 September 2008, 17:49 GMT+2
jswetzen: I have this issue once. It's because the compiled-in sysfont didn't recompile with the modified bdf2fnt, and you see the result. Try 'make veryclean', and 'make' again. That problem will be gone.
Comment by Johan Swetzén (jswetzen) - Thursday, 18 September 2008, 15:36 GMT+2
Thank you, that did the trick.
Comment by Thomas Martitz (kugel.) - Monday, 29 September 2008, 05:01 GMT+2
The I found the cause of the mpeg player. Firstly, this issue only exists on LCD_PORTRAIT targets.

mpegplayer flips the display for portrait targets. Thus, font rendering is also flipped. The issue is, that mpegplayer re-implements the font drawing so it's flipped (it's not using the internal function). Of course it only reimplemented mono-font rendering.

This means: alpha font rendering needs to be re-implemented for the mpegplayer too.
Comment by Tri Nguyen (tri170391) - Monday, 24 November 2008, 11:30 GMT+2
convttf build failed on Archlinux current. Here's the output:

cc -O -ansi -Wall -g convttf.c -o convttf `freetype-config --libs` `freetype-config --cflags`
/tmp/cctYDAcX.o: In function `convttf':
/home/###/Projects/rockbox/tools/convttf/convttf.c:605: undefined reference to `floor'
collect2: ld returned 1 exit status
make: *** [convttf] Error 1
Comment by Tri Nguyen (tri170391) - Tuesday, 02 December 2008, 15:55 GMT+2
It turns out that the Makefile on the #1 Post is missing the -lm flags, and convttf builds now. But I have another problem. If I build convttf in Ubuntu Hardy, it produce good FNT file. But if I build using the same source and Makefile on Archlinux then it produce 'bad' FNT file. As you can see in those screendumps. IMO it may be caused by newer gcc or libfreetype in Archlinux.
Comment by Thomas Martitz (kugel.) - Tuesday, 02 December 2008, 17:42 GMT+2
Don't use the convttf.c from the first post, it's flawed (too much space between glyphs). I think the ones from 14th or 15th August are good.
Comment by Tri Nguyen (tri170391) - Wednesday, 03 December 2008, 06:42 GMT+2
I used the convttf.c on 21st August, the 14th and 15th August ones have this issue too.

Loading...