Rockbox

Tasklist

FS#8961 - Anti-Aliased Fonts

Attached to Project: Rockbox
Opened by Jack Suter (chrisjs169) - Sunday, 04 May 2008, 21:09 GMT
Last edited by Thomas Martitz (kugel.) - Saturday, 05 March 2011, 20:12 GMT
Task Type Patches
Category Font/charset
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 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).
This task depends upon

Closed by  Thomas Martitz (kugel.)
Saturday, 05 March 2011, 20:12 GMT
Reason for closing:  Accepted
Additional comments about closing:  Finally after almost 3 years (r29523) \o/
Comment by Thomas Martitz (kugel.) - Monday, 05 May 2008, 17:51 GMT
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, 05:49 GMT
This is a quick and dirty fix for the mpegplayer font problem, it just use sysfont instead of UI font for drawing the WVS.
Comment by Taktak (Whick) - Wednesday, 06 August 2008, 07:28 GMT
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, 09:12 GMT
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, 12:49 GMT
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, 13:21 GMT
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, 18:45 GMT
I altered the way of deciding the width again.
   convttf.c (31.3 KiB)
Comment by Thomas Martitz (kugel.) - Monday, 11 August 2008, 13:21 GMT
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, 14:19 GMT
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, 14:25 GMT
Filesize. I tried to convert Bitstream Vera and FreeSans, both didn't work.
Comment by Tri Nguyen (tri170391) - Monday, 11 August 2008, 14:30 GMT
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, 16:16 GMT
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, 16:30 GMT
I don't understand.
Comment by Taktak (Whick) - Monday, 11 August 2008, 16:42 GMT
Sorry, I 'll explain that with some debug-log tomorrow.
Comment by Thomas Martitz (kugel.) - Monday, 11 August 2008, 16:47 GMT
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, 09:35 GMT
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, 09:36 GMT
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, 09:37 GMT
I was wrong , file name in example, Filename:arialuni_15_[4bpp].txt (not log.txt)
Comment by Taktak (Whick) - Tuesday, 12 August 2008, 09:37 GMT
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, 09:42 GMT
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, 10:03 GMT
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, 10:09 GMT
Sorry, Could you try this font on your device? ( not "it" )
Comment by Taktak (Whick) - Tuesday, 12 August 2008, 10:19 GMT
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, 13:24 GMT
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.) - Tuesday, 12 August 2008, 23:24 GMT
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, 00:10 GMT
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, 03:30 GMT
> 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, 03:55 GMT
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, 04:46 GMT
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, 11:40 GMT
> 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, 06:31 GMT
alternated deciding height again.
   convttf.c (35.5 KiB)
Comment by Thomas Martitz (kugel.) - Friday, 15 August 2008, 10:28 GMT
I can't compile atm. I cannot confirm until sunday.
Comment by Taktak (Whick) - Thursday, 21 August 2008, 08:15 GMT
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, 21:06 GMT
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, 15:49 GMT
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, 13:36 GMT
Thank you, that did the trick.
Comment by Thomas Martitz (kugel.) - Monday, 29 September 2008, 03:01 GMT
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, 10:30 GMT
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, 14:55 GMT
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, 16:42 GMT
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, 05:42 GMT
I used the convttf.c on 21st August, the 14th and 15th August ones have this issue too.
Comment by Seheon Ryu (cpu98) - Thursday, 13 August 2009, 15:39 GMT
It will need resync...
Comment by Thomas Martitz (kugel.) - Thursday, 13 August 2009, 16:01 GMT
here you go, it was easy.
Comment by Teruaki Kawashima (teru) - Tuesday, 18 August 2009, 09:36 GMT
Update patch.
* Try to support all drawmode by imitating lcd_mono_bitmap_part.
* Remove commented out code.
* Add draw function to mpegplyer and rockpaint (anti-alias_fonts_for_plugins.090818.patch).
Comment by Andrew Mahone (Unhelpful) - Friday, 21 August 2009, 10:18 GMT
Remove trailing whitespace from both patches, and a small change to the core patch, avoiding multiply when updating the LUT and also not zeroing the last entry, since it's actually the next-to-last level before full transparency.

Edit: fixed core AA fonts patch.
Comment by Thomas Martitz (kugel.) - Friday, 21 August 2009, 11:09 GMT
Unhelpfu, I've read the logs.

Re depth of the fonts: They're supposed to be 4bit. I was chatting with the creator back when he was active, and I've been testing his patch very early. We found that 2bits is too ugly (not enough of an improvement over mono fonts), but 8bit doesn't look any better than 4bits. Maybe the #define is a bug?
However, we possibly might want to keep the 2bit support if we want greyscales to support AAF (2bit for grey, 4bit for color)?

Re convttf: Attached is an improved version that I fixed to not exceed the chosen font height. It's a bit problematic, depending on the charset some glyphs might get cut off, but that's already a problem with our current mono fonts too. This convttf version sets the height, then checks if the resulting font is too high. If it is too high, it decrements the target height upto 3 times before finishing the font (then it crops if it's still too high). The results are comparable to what the mono font generation gives.
   convbdf.c (47.4 KiB)
Comment by Andrew Mahone (Unhelpful) - Saturday, 22 August 2009, 00:16 GMT
That's convbdf.c... anyway, I'm working on a different solution, which would work by doing the height test with an unreasonably large size (1024px right now), and then setting a fractional size calculated based on the desired target size. The only problem I'm having is that somehow all the glyphs are being offset downward, and most of the time this leads to them being empty. There is probably a value from the height test which is used later that I am missing...
Comment by Thomas Martitz (kugel.) - Saturday, 22 August 2009, 00:30 GMT
oh sorry I've uploaded the wrong file. This should be correct now.
   convttf.c (30.6 KiB)
Comment by Andrew Mahone (Unhelpful) - Saturday, 22 August 2009, 06:07 GMT
convttf changes:
* -p is always the total pixel size of the output font
* -c adds N/2 empty columns on either side of the character
* -r adds N/2 empty rows above and below characters, with extra "odd" row on the bottom, and defaults to 1
* any empty rows removed by -r are subtracted from -p to calculate the glyph height
* the height-calculating run is done at 4x the desired size (to give a couple of extra bits of precision to the calculated size) and the resulting height is used to calculate the correct height to request
   convttf.c (35.7 KiB)
Comment by Andrew Mahone (Unhelpful) - Monday, 24 August 2009, 03:37 GMT
Move width calculation into a function, used during both size calculation and conversion. Better solution will be to allocate memory *during* conversion as needed, saving a pass through the whole charset.
   convttf.c (35.3 KiB)
Comment by Andrew Mahone (Unhelpful) - Thursday, 27 August 2009, 10:33 GMT
Rewrite of memory allocation and glyph conversion.
* a codepoint is allocated for the default character, either the first missing character between firstchar and lastchar, or by moving firstchar down by one
* memory is allocated as needed for glyphs during rendering and conversion
* exactly one blank glyph is stored for each width that appears as a blank glyph, with later identical glyphs reusing the offset and width
* offsets are stored as longs, and converted to shorts if possible before writing

Valgrind runs this without complaints, and the smaller fonts work well on my Gigabeat. A mixed font made by combining adding some symbols and CJK characters to an otherwise Latin-1 font gives good results, although there is still disk spinup whenever scrolling long lists, even without any unusual characters on-screen. Using all of Arial Unicode MS still produces those weird problems with scrolling, causing bits of other text to appear elsewhere on the screen when titles scroll - perhaps this very large font file (~5.5MB) is overflowing a buffer somewhere?
   convttf.c (33.3 KiB)
Comment by skylarg717 (skylarg717) - Thursday, 27 August 2009, 15:25 GMT
I can't seem to apply the patch. I get these errors:
"can't find file to patch at line 5"
"can't find file to patch at line 225"
"can't find file to patch at line 244"
"can't find file to patch at line 265"
"can't find file to patch at line 319"

I've tried to apply the patch 3 times. The first time it wouldn't load the fonts properly.
Also, how do you compile the convttf tool?

I'm new to this, so please help.
Comment by Andrew Mahone (Unhelpful) - Friday, 28 August 2009, 01:12 GMT
Binsize reduction for alpha blending, should come without a large speed hit. Use mulitply and multiply-accumulate instructions for all blends, and rework loop logic a bit.

RE: the font issues, enlarging the font buffer by quite a bit seems to fix both the cache misses and the random text draws, although I'm not sure yet how exactly the latter problem happens.
Comment by Andrew Mahone (Unhelpful) - Friday, 28 August 2009, 03:28 GMT
Use unsigned for paramaters and return in blend functions, this prevents unwanted zero-extension instructions. Inline all blends, this makes things not quite as large as before changing the blend functions, and makes blends about the same speed on my Gigabeat S, and faster on my E200 compared to the LUT-based blends.
Comment by Andrew Mahone (Unhelpful) - Friday, 28 August 2009, 07:46 GMT
* fix glyph size calculation in firmware/font.c
* fix max width calculation in convttf.c
* rework scaling calculation in convttf.c, select a new scale instead of a new pixel size
* treat font header "depth" field as a flag - 0 means 1-bit fonts, non-zero means 4-bit

I am no longer seeing disk spinups whenever there is much text on screen, nor can i reproduce the random corrupted text, it looks like the combination of these two fixes has solved those problems.
Comment by Thomas Martitz (kugel.) - Friday, 28 August 2009, 09:49 GMT
Wow nice! :O

"* treat font header "depth" field as a flag - 0 means 1-bit fonts, non-zero means 4-bit"

Before focusing on 4bit fonts: Did we ever consider 2-bit fonts for greyscale yet? I think it should be doable, although I have no idea how it looks.

"especially when it's doc'd in the header as 0=1-bit 1=4-bit" That comment is wrong, it's always been log2(actual_depth), IIRC.
Comment by Andrew Mahone (Unhelpful) - Friday, 28 August 2009, 10:12 GMT
from firmware/export/font.h:
* USHORT depth 2 depth of the font, 0=1-bit and 1=4-bit

As far as 2-bit fonts go, I don't have a greyscale device, so I can't say how they'd look. I'm not worrying too much about supporting other depths, because I don't want to 1) bloat the code further by handling 2- or 4-bit fonts on color targets 2) target-specific fonts.
Comment by Thomas Martitz (kugel.) - Friday, 28 August 2009, 11:42 GMT
I've modified convttf very little to integrate into the build system and font filename naming scheme. no functional change, but it doesn't work (white display). I tried to convert monofur.
Comment by Andrew Mahone (Unhelpful) - Saturday, 29 August 2009, 08:12 GMT
* ColdFire reads bitmap data a word at a time. This makes the code a bit larger, and has not proven to be beneficial on ARM.
* Make mpegplayer and rockpaint's alpha blending code a bit more similar to that in the LCD driver, making them a bit easier to keep up to date.
* Merge convttf.c, and split off tools and build system changes into a separate patch.
* Fix convttf, which missed some bits when changing depth to a flag, and also works very wrongly when built with -std=c99.
* Minor fixes for console output of convttf.
* Numerous line length and whitespace fixes.
Comment by Andrew Mahone (Unhelpful) - Saturday, 29 August 2009, 12:12 GMT
A start at fixing word size issues, the conversion of the font header struct to use uint*_t.
Comment by Andrew Mahone (Unhelpful) - Monday, 31 August 2009, 02:33 GMT
* Use c99 instead of gnu89 when building convttf, as it produces fewer warnings and works fine since the font header struct fixes.
* Fix left/top clipping when drawing alpha bitmaps with byte reads.

EDIT: remove a DEBUGF
Comment by Will Hauck (moonscapex) - Sunday, 04 October 2009, 18:54 GMT
If someone could post a archive of converted fonts or the convttf binary that would be great.
Comment by Andrew Mahone (Unhelpful) - Monday, 05 October 2009, 02:45 GMT
The newest patches build convttf along with other rockbox tools. As far as fonts go, there are a few decent outline fonts with licensing liberal enough to allow redistribution, but not quite so many with good unicode coverage.
Comment by Will Hauck (moonscapex) - Monday, 05 October 2009, 14:12 GMT
I just found a great website to convert fonts:
www.rbthemes.com/fonts
If convttf doesn't work try this.
Comment by Michael Marley (mamarley) - Saturday, 28 November 2009, 13:21 GMT
I think the patch needs to be updated for the new Diacritic support that is now in SVN. I updated it myself in what seemed like the most logical manner, but it caused certain characters (capital Vs and Ws, possibly among others) to be displayed in a garbled way. It also causes for some text (the statusbar clock and the text editor) to be displayed completely garbled. (This is on an iPod Nano 2g, if it matters)
Comment by Will Hauck (moonscapex) - Saturday, 28 November 2009, 16:10 GMT
The exact same thing happens on my Sansa e200, making half the plugins unusable.
Comment by Tomer Shalev (tomers) - Saturday, 28 November 2009, 16:34 GMT
> I think the patch needs to be updated for the new Diacritic support that is now in SVN. I updated it myself in what seemed like the most logical manner, but it caused certain characters (capital Vs and Ws, possibly among others) to be displayed in a garbled way. It also causes for some text (the statusbar clock and the text editor) to be displayed completely garbled. (This is on an iPod Nano 2g, if it matters)

Please pay attention to remark in lcd-bitmap-common.c, LCDFN(putsxyofs)(), which describes how diacritic character drawing should be done. Since this way of drawing might be soon implemented it might affect this patch. I don't know if it will be bad or good for this issues, but it's something that has to be considered.
Comment by Michael Marley (mamarley) - Saturday, 28 November 2009, 19:17 GMT
Still exactly the same issue.
Comment by Maurus Cuelenaere (mcuelenaere) - Thursday, 17 December 2009, 15:01 GMT
Synced to SVN.
Comment by Michael Marley (mamarley) - Thursday, 17 December 2009, 16:09 GMT
This new patch seems to fix most of the regular font corruption issues, but I have noticed some Vs are still garbled, most of the games are still unplayable due to garbled fonts, and the statusbar clock is garbled.
Comment by Fred Bauer (freddyb) - Saturday, 31 July 2010, 00:39 GMT
Fixed SYSFONT
Re-Synced to SVN
Plugins work now that SYSFONT is fixed.
There is still a bug that garbles fonts at certain sizes.
Comment by Fred Bauer (freddyb) - Saturday, 31 July 2010, 18:04 GMT
Switched to a previous version of convttf.c from Kugel from 12-Aug-2008 which seems to work more reliably. (http://www.rockbox.org/tracker/task/8961?getfile=17197)
Incorporated mpeg_player and rockpaint fixes.
Note: if you have performance problems you might have to adjust the MAX_FONT_SIZE in firmware/font.c or SKIN_FONT_SIZE in apps/gui/skin_engine/skin_fonts.h to avoid excessive glyph cache misses.
Comment by Michael Marley (mamarley) - Sunday, 01 August 2010, 23:34 GMT
The new patch is working great for me. The fonts look very good. However, it causes a bug in PictureFlow where if it is necessary to scroll the album title (because it is too long for the screen), the characters that should be scrolled off the screen on the left side instead become "stuck" there. Great work, though!
Comment by Fred Bauer (freddyb) - Monday, 02 August 2010, 04:00 GMT
I checked on what you described. This applies to non-AA fonts, too.
This line in lcd_bitmap_common.c is called to copy the glyph to the screen:
LCDFN(mono_bitmap_part)(bits, ofs, 0, width, MAX(x + base_ofs, 0), y, width - ofs, pf->height);
The MAX() function should not be in there. It prevents printing a partial glyph on the left margin.
Comment by Michael Marley (mamarley) - Monday, 02 August 2010, 10:24 GMT
Thanks! That fixes the problem. Here is an updated version of the patch.
Comment by Fred Bauer (freddyb) - Thursday, 19 August 2010, 00:26 GMT
Just a note on using convttf:

If you're not satisfied with the vertical spacing of the font, you can adjust it using Font Forge. If you want a font with no gap between lines go to Menu > Element > Font Info... > OS/2 > Metrics. HHead Ascent and HHead Descent seem to be the numbers that affect convttf. Turn off "is offset's" and set HHead Ascent to the height of the tallest glyph and HHead Descent to the bottom of the lowest glyph.
Comment by Fred Bauer (freddyb) - Monday, 23 August 2010, 00:03 GMT
Options added to convttf:
-A N : Trim vertical ascent by N%
-D N : Trim vertical descent by N%
-x : Trim the sides of the glyphs based on empty space which can improve spacing on A's and V's.
-d : Dump ascii art glyph images out stdout
   convttf.c (33.8 KiB)
Comment by Sadurní (sadur) - Monday, 23 August 2010, 15:43 GMT
I've played with it a while and it works very well. Thank you.
Comment by Matteo Italia (MItaly) - Monday, 23 August 2010, 19:04 GMT
Really a great patch; at least on my Fuze, I didn't notice any slowdown, crash or unusual IO activity, and it's a pleasure for the eyes to have almost-antialiased fonts on RockBox.
I'm wondering why isn't it merged in the SVN.
Comment by Fred Bauer (freddyb) - Monday, 23 August 2010, 22:47 GMT
I think there's some concern about memory usage. I'm going to try to address some of that with  FS#11567 . Convttf.c still needs some clean up and I need to write the code to dump the 'C' files required to build an anti-aliased SYSFONT. It would be nice to find some redistributable fonts to work with, too.
Comment by Thomas Martitz (kugel.) - Monday, 23 August 2010, 23:53 GMT
I don't think we need a anti-aliased sysfont.

For a long time only the mpegplayer was holding this patch back (I sort of tried to push it in but I had to admit the mpegplayer bug is not accaptable). Now that this is fixed we need to get a convttf that's working properly, as of now it seems the various versions posted here sometimes work and sometimes don't.

I'd be very much willing to commit this eventually, I've always been a fan of it.

EDIT: Would it be possible to have the -A/-D options you added to convttf in pixel (not percentage units)? Maybe as an additional option so that the percentage ones can be kept.
Comment by Fred Bauer (freddyb) - Tuesday, 24 August 2010, 04:55 GMT
I wanted the percentage option because it's handy when converting to a range of font sizes.

Here's the new convttf.c with trimming options as follows:
-TA N Trim vertical ascent (N percent)
-TD N Trim vertical descent (N percent)
-Ta N Trim vertical ascent (N pixels)
-Td N Trim vertical descent (N pixels)
Using a negative value will pad instead of trim.

This seems to be working pretty reliably now.
   convttf.c (35.8 KiB)
Comment by Matteo Italia (MItaly) - Tuesday, 24 August 2010, 10:08 GMT
So there are good chances that we'll see antialiased fonts in 3.7? Great! :)
Comment by Rosso Maltese (asettico) - Thursday, 26 August 2010, 07:57 GMT
Building the sim, I'm getting this error:

In file included from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/plugin.h:57,
from /home/asettico-9.10/Sviluppo/rockbox/rockbox/apps/plugins/plugin_crt0.c:23:
/home/asettico-9.10/Sviluppo/rockbox/rockbox/firmware/export/font.h:34:21: error: sysfont.h: No such file or directory

Building the FW there is no problem.
Comment by Michael Chicoine (mc2739) - Thursday, 26 August 2010, 11:27 GMT
Rosso,

The simulator build problem is a separate issue and not related to this task. It has been reported in  FS#11570 .
Comment by Rosso Maltese (asettico) - Thursday, 26 August 2010, 14:32 GMT
But I don't build the w32 cross-compiled simulator, I'm building a Linux simulator...
The error message refers to the missing sysfont.h
Comment by Fred Bauer (freddyb) - Thursday, 26 August 2010, 14:36 GMT
Rosso, does building twice work? I think maybe there was a make order problem...
Comment by Rosso Maltese (asettico) - Thursday, 26 August 2010, 14:57 GMT
Yes, you're right! :-)
Comment by Fred Bauer (freddyb) - Friday, 27 August 2010, 19:48 GMT
Resync aa-fonts patch.
Created function glyph_bytes to reuse some code.
Added horizontal stretch option for convttf.c. I think convttf can now do anything reasonably expected of a font converter.
Comment by Thomas Martitz (kugel.) - Friday, 27 August 2010, 20:16 GMT
Can it also create legacy font files?
Comment by Fred Bauer (freddyb) - Friday, 27 August 2010, 20:37 GMT
No. I tried a couple truetype fonts in FontForge and rendered them without AA. They don't look good.
Comment by Fred Bauer (freddyb) - Saturday, 28 August 2010, 13:27 GMT
Fixes an accidentally deleted line in v2.
Comment by Matteo Italia (MItaly) - Saturday, 28 August 2010, 16:13 GMT
The patch misses convttf.c; I'd include it in the patch, since it's required for the thing to work correctly (make complains because it's missing - and it does so in a quite unclear way).
Comment by Matteo Italia (MItaly) - Saturday, 28 August 2010, 17:07 GMT
Tried it on the Fuze sim, but it doesn't seem to work; I tried with Liberation Sans and DejaVu Sans and they both result in garbled images on the screen instead of the glyphs.
The .fnt were created with che convttf.c provided in yesterday's comment from the .ttfs provided with Ubuntu.
Attached are some screenshots.
I don't know if it may be related, but now I'm building everything on a 64 bit machine (and the sim should be a 64 bit app).
Comment by Sadurní (sadur) - Saturday, 28 August 2010, 17:49 GMT
The same happened to me, but the problem isn't convttf because the newly generated fonts work ok with the previous patches.
Comment by Fred Bauer (freddyb) - Sunday, 29 August 2010, 03:32 GMT
Make file write out in convttf portable. Hopefully this will fix the issues reported by MItaly.
Comment by Matteo Italia (MItaly) - Sunday, 29 August 2010, 10:08 GMT
This last convttf.c is empty... :S
Comment by Fred Bauer (freddyb) - Sunday, 29 August 2010, 15:26 GMT
I don't know how that happened. Try again.
   convttf.c (36.8 KiB)
Comment by Matteo Italia (MItaly) - Sunday, 29 August 2010, 20:00 GMT
It works like a charm; I don't know if there's some relevant modification, but it seems to produce slightly better results than the previous one I used. Great work! :)
Comment by Fred Bauer (freddyb) - Sunday, 29 August 2010, 20:23 GMT
I would like to see a before and after if you don't mind.
Comment by Matteo Italia (MItaly) - Sunday, 29 August 2010, 20:43 GMT
It's difficult to make a precise comparison, because the output sizes have changed I can't find an exact correspondence between the old and the new ones.
Comment by Matteo Italia (MItaly) - Sunday, 31 October 2010, 20:03 GMT
3.7 was released and this didn't make it in SVN... will we ever have antialiased fonts in "normal" builds? :(
Comment by Fred Bauer (freddyb) - Wednesday, 10 November 2010, 22:59 GMT
Lastest version of convttf.c.
   convttf.c (37.6 KiB)
Comment by Fred Bauer (freddyb) - Thursday, 16 December 2010, 18:19 GMT
Just for the record, the rendering performance of anti-aliased fonts seems to be about 50-70% of the non AA-fonts. I tested this on Fuze(v1) and iPod video. The iPod rendered a short string 370 times per second using non-AA 14-Nimbus.fnt and 251/s using Andale-Mono AA at 14 px. Note that these comparisons are not completely fair because the glyph widths are not quite the same. In practice I can't tell any difference in the performance with AA-fonts, however.
Comment by Thomas Martitz (kugel.) - Friday, 17 December 2010, 07:21 GMT
I was always in favor of this patch, considering there's no change for the classic fonts. is the latest convttf you uploaded working properly (there have been various various versions of it, and the more recent ones generally didn't work).
Comment by Fred Bauer (freddyb) - Friday, 17 December 2010, 15:58 GMT
Kugel, convttf works. My latest was based on one of the earlier ones that worked. I fixed up some problems with output on a non 32bit LE system. I added the ability to trim ascent and descent by percentage which is nice if you want to produce a range of font sizes. There have been some complaints about kerning which I tried to address with the -x option which attempts to trim columns consisting only of blending fuzz. I should clean out some of the messy debug output and write some documentation. I'd also like to provide an AA font theme with a redistributable font.
Comment by Fred Bauer (freddyb) - Friday, 17 December 2010, 19:31 GMT
Hopefully these images will explain the -x option. These two images are of the a010013l Type1 font from gsfonts (Ghostscript fonts).
1st image: "convttf -TD30 -p 20 a010013l.pfb".
2nd image: "convttf -TD30 -p20 -x -c 1 a010013l.pfb" - trims the horizontal fuzz (-x) but adds 1 pixel back in (-c1). This makes the spacing more consistent.
Comment by PurlingNayuki (yzflcyq) - Saturday, 25 December 2010, 00:54 GMT
Tested on r-27522 PMP Firmware's Rockbox Alpha 3.
A very nice patch:) Now the font display is more comfortable and clearly!

Comment by Thomas Martitz (kugel.) - Sunday, 26 December 2010, 16:12 GMT
It looks really awesome for chinese character sets. For ASCII chars is mostly an eye candy, but it looks like that for chinese chars it really adds usablity.
Comment by Thomas Martitz (kugel.) - Sunday, 26 December 2010, 16:32 GMT
Ubuntu font on my phone (together with a patch for increased line spacing).
Comment by Andrew Bailey (fallenturtle) - Monday, 03 January 2011, 04:42 GMT
Does this patch work with 3.7.1 iPod Video?
Comment by PurlingNayuki (yzflcyq) - Monday, 03 January 2011, 10:55 GMT
I don't know, but I think it will.
It's a pretty good patch.
Comment by Postolati Maxim (tails_) - Saturday, 15 January 2011, 22:54 GMT
Can't apply patch on r29057
Comment by Postolati Maxim (tails_) - Saturday, 15 January 2011, 22:56 GMT
whoops wrong cmd parameters, sorry

Loading...