This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#8961 - Anti-Aliased Fonts
Attached to Project:
Rockbox
Opened by Jack Suter (chrisjs169) - Sunday, 04 May 2008, 23:09 GMT+2
Last edited by Thomas Martitz (kugel.) - Saturday, 05 March 2011, 21:12 GMT+2
Opened by Jack Suter (chrisjs169) - Sunday, 04 May 2008, 23:09 GMT+2
Last edited by Thomas Martitz (kugel.) - Saturday, 05 March 2011, 21:12 GMT+2
|
DetailsScorche 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)
tools/convbdf.c | 1 firmware/export/font.h | 3 firmware/font.c | 14 +- firmware/drivers/lcd-16bit.c | 282 ++++++++++++++++++++++++++++++++++++++++++- 4 files changed, 291 insertions(+), 9 deletions(-)
convttf.c
(15.6 KiB)
Makefile_confttf
(0.7 KiB)
|
This task depends upon
Closed by Thomas Martitz (kugel.)
Saturday, 05 March 2011, 21:12 GMT+2
Reason for closing: Accepted
Additional comments about closing: Finally after almost 3 years (r29523) \o/
Saturday, 05 March 2011, 21:12 GMT+2
Reason for closing: Accepted
Additional comments about closing: Finally after almost 3 years (r29523) \o/
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.
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?
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.
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?
I want to try it recently. What font are you converting? Please tell me one of them.
You don't need any special way.
(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.
"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.
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
------------------------------------------------
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)
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.
The problem is, that the fonts I get with your converter don't work.
All of fonts don't work don't they? Could you try it on your device?
from "-O -ansi -Wall -g"
to "-O -Wall -g"
I don't change "anti-alias_fonts.patch"
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.
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.
I'll try to delete noticeable and extra space in this Text-file.
"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.
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.
> I can't compile atm. I cannot confirm until sunday.
no matter when if you will do.
Attached is a screenshot of the text input plugin, the problem is really obvious here.
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.
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
* 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).
Edit: fixed core AA fonts patch.
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.
* -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
* 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?
"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.
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.
* 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.
"* 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.
* 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.
* 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.
* Fix left/top clipping when drawing alpha bitmaps with byte reads.
EDIT: remove a DEBUGF
www.rbthemes.com/fonts
If convttf doesn't work try this.
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.
Re-Synced to SVN
Plugins work now that SYSFONT is fixed.
There is still a bug that garbles fonts at certain sizes.
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.
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.
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.
-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
I'm wondering why isn't it merged in the SVN.
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.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.
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.
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.
The simulator build problem is a separate issue and not related to this task. It has been reported in
FS#11570.The error message refers to the missing sysfont.h
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.
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).
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.
A very nice patch:) Now the font display is more comfortable and clearly!
It's a pretty good patch.