Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category User Interface → Font/charset
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by chrisjs169 - 2008-05-04
Last edited by kugel. - 2011-03-05

FS#8961 - Anti-Aliased Fonts

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).

Closed by  kugel.
2011-03-05 20:12
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Finally after almost 3 years (r29523) \o/

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.

This is a quick and dirty fix for the mpegplayer font problem, it just use sysfont instead of UI font for drawing the WVS.

Whick commented on 2008-08-06 07:28

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
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:

  1. c N Character separation in pixel.Insert space between characters
  2. 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)

Taktak, your converter somehow ignore white space character. Making textbooks almost unreadable, as you can see in this screendump.

Whick commented on 2008-08-09 12:49

It’s commic sans serif isn’t it?

I altered the method of deciding the width of the character for some
use “face→glyph→bitmap.pitch” instead of “face→glyph→metrics.horiAdvance » 6” for some free fonts.)

But I apologize its influencing some font
the “method of deciding the width” AS SAME AS FORMER.

But I ‘ll pick out other method sometime soon for Both fonts.

Whick commented on 2008-08-09 13:21

I forgot to attach this. The method of deciding the width is ALMOST same as former uploaded by chrisjs169.

Whick commented on 2008-08-10 18:45

I altered the way of deciding the width again.

   convttf.c (31.3 KiB)

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?

Whick commented on 2008-08-11 14:19

10x bigger? Is “10x” in file-size?(or glyph bitmap size?) I’m sorry for
want to try it recently. What font are you converting? Please tell me one of them.

You don’t need any special way.

Filesize. I tried to convert Bitstream Vera and FreeSans, both didn’t work.

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.

Whick commented on 2008-08-11 16:16

Because of the difference of font-file-size is bug in first
downloaded it form
try to use otf2bdf if you could. Arialuni has 38911
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.

I don’t understand.

Whick commented on 2008-08-11 16:42

Sorry, I ‘ll explain that with some debug-log tomorrow.

So, why does it not work for me/the fonts I used? They are ttf’s and I just did

“make -f
“./convttf Vera.ttf”

The resulting file is ~20KB big with the first version of the converter, the filesize using your versions is above 200KB.

Whick commented on 2008-08-12 09:35

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
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
prove it. (off course, you need to rename those file into convttf.c to build them yourself) These program output log files like following


Filename:arialuni_15_[4bpp].log (add “.log” to fnt base name) contents:

code=0	 size = 120
code=1	 size = 240
code=2	 size = 360

————————————————

Whick commented on 2008-08-12 09:36

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


Code means character code)

Whick commented on 2008-08-12 09:37

I was wrong , file name in example, Filename:arialuni_15_[4bpp].txt (not log.txt)

Whick commented on 2008-08-12 09:37

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.

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.

Whick commented on 2008-08-12 10:03

I’m sorry
of fonts don’t work don’t they?  Could you try it on your device?

   mona.zip (454.6 KiB)
Whick commented on 2008-08-12 10:09

Sorry, Could you try this font on your device? ( not “it” )

Whick commented on 2008-08-12 10:19

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”

Thanks, with the Makefile it seems to work. I think the 10th August version works better than the 9th one.

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)

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.

Whick commented on 2008-08-13 03:30
i.e. the selection bar is bigger

I think really so. But you’d better stop modifying the
read attached text-files encoded in UTF8 and find following line.by your editor and each
fogot to set “default codepage” or “encoding setting” of your editor to “UTF8”.

Code=0×162(354)



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
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
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
“min bottom line” and “min bottom” line isn’t correctly expression. But I expect you of understanding it.

Whick commented on 2008-08-13 03:55

Sorry, Stll, I found the need to modify deciding
try to delete noticeable and extra space in this Text-file.

Whick commented on 2008-08-13 04:46

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
you modify usage more naturally
this modification is quite not enough, you know.

   convttf.c (30.2 KiB)
Whick commented on 2008-08-14 11:40
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.
Whick commented on 2008-08-15 06:31

alternated deciding height again.

   convttf.c (35.5 KiB)

I can't compile atm. I cannot confirm until sunday.

Whick commented on 2008-08-21 08:15

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)

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.

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.

Thank you, that did the trick.

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.

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

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.

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.

I used the convttf.c on 21st August, the 14th and 15th August ones have this issue too.

cpu98 commented on 2009-08-13 15:39

It will need resync...

here you go, it was easy.

teru commented on 2009-08-18 09:36

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).

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.

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)

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...

oh sorry I've uploaded the wrong file. This should be correct now.

   convttf.c (30.6 KiB)

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)

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)

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)

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.

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.

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.

* 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.

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.

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.

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.

* 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.

A start at fixing word size issues, the conversion of the font header struct to use uint*_t.

* 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

If someone could post a archive of converted fonts or the convttf binary that would be great.

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.

I just found a great website to convert fonts: www.rbthemes.com/fonts If convttf doesn't work try this.

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)

The exact same thing happens on my Sansa e200, making half the plugins unusable.

> 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.

Still exactly the same issue.

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.

Fixed SYSFONT Re-Synced to SVN Plugins work now that SYSFONT is fixed. There is still a bug that garbles fonts at certain sizes.

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.

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!

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.

Thanks! That fixes the problem. Here is an updated version of the patch.

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.

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)
sadur commented on 2010-08-23 15:43

I've played with it a while and it works very well. Thank you.

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.

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.

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.

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)

So there are good chances that we'll see antialiased fonts in 3.7? Great! :)

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.

Rosso, The simulator build problem is a separate issue and not related to this task. It has been reported in FS#11570.

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

Rosso, does building twice work? I think maybe there was a make order problem...

Yes, you're right! :-)

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.

Can it also create legacy font files?

No. I tried a couple truetype fonts in FontForge and rendered them without AA. They don't look good.

Fixes an accidentally deleted line in v2.

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).

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).

sadur commented on 2010-08-28 17:49

The same happened to me, but the problem isn't convttf because the newly generated fonts work ok with the previous patches.

Make file write out in convttf portable. Hopefully this will fix the issues reported by MItaly.

This last convttf.c is empty... :S

I don't know how that happened. Try again.

   convttf.c (36.8 KiB)

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! :)

I would like to see a before and after if you don't mind.

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.

3.7 was released and this didn't make it in SVN... will we ever have antialiased fonts in "normal" builds? :(

Lastest version of convttf.c.

   convttf.c (37.6 KiB)

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.

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).

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.

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.

Tested on r-27522 PMP Firmware's Rockbox Alpha 3. A very nice patch:) Now the font display is more comfortable and clearly!

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.

Ubuntu font on my phone (together with a patch for increased line spacing).

Does this patch work with 3.7.1 iPod Video?

I don't know, but I think it will. It's a pretty good patch.

Can't apply patch on r29057

whoops wrong cmd parameters, sorry

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing