android
  #1  
Old 03-15-2009, 09:17 AM
greenman greenman is offline
Junior Member
 
Join Date: Apr 2008
Posts: 59
Default Multifont patch inquiry

I'd really like to get multiple fonts working on my compile.
However, when I try to patch with the multifont patch:
http://www.rockbox.org/tracker/4733
I get errors.

I didn't see anything in the major changes about multiple font use,
so I'm wondering if this will not be supported any longer.

It's not immediately apparent from flyspray where this patch is headed.

I'd be grateful for any insights as to how I can get more than one font on my theme.
Reply With Quote

Advertisement [Remove Advertisement]

  #2  
Old 03-15-2009, 03:49 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,608
Default

Multifont was not committed. You can tell if a patch is committed because the FS task will be closed and the closing reason will say something like "committed in rxxxxx".

If the patch doesn't apply, its probably broken. Thats not really surprising. Looking at that link, it touches a lot of rockbox components, yet hasn't been resynced in 6 months. Its probably quite out of date by now.
Reply With Quote

  #3  
Old 03-15-2009, 08:15 PM
greenman greenman is offline
Junior Member
 
Join Date: Apr 2008
Posts: 59
Default

saratoga,

Thanks again for your reply.

I really like anti-alias fonts and multifont concept, but I don't know where to start to try and bring the multifont back into sync, and I'd hate to see anti-alias get dropped. Coming from a design standpoint, the aa fonts are usually smaller in kb than standard .fnt files and are obviously more legible. Having different sizes of fonts better allocates space in a confined area at almost no extra cost to the build. The capability to allocate multiple fonts is already available in viewports, but fails nicely to system theme default when the patch hasn't been applied. That obviously took some consideration on the part of the people crafting 'viewports'. Considering the vast difference viewports has made in layout and design, and how small a step these two patches are from sheer excellence, I'm curious why multifont and anti-aliased bitmap font support seem to have just dropped off the earth's edge. There is probably a good reason, but I'm hard pressed to see it. Why haven't they been committed to core?

Looking at the state of the custom builds for Sansa, it looks like suddenly about six months ago, all the custom builders just stopped maintaining their builds. I know rockbox core has gotten really good, but why would so many excellent crafters just drop everything and beat feet? What happened?
Reply With Quote

  #4  
Old 03-15-2009, 09:16 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,608
Default

Quote:
Originally Posted by greenman View Post
There is probably a good reason, but I'm hard pressed to see it. Why haven't they been committed to core?
Check the FS link. It looks like theres a pretty good explanation in there.

Quote:
Originally Posted by greenman View Post
Looking at the state of the custom builds for Sansa, it looks like suddenly about six months ago, all the custom builders just stopped maintaining their builds. I know rockbox core has gotten really good, but why would so many excellent crafters just drop everything and beat feet? What happened?
I think the only person who actually maintained a custom build 6 months ago was kugel, and he started doing actual development.

Anyway maintaining a custom build is a pretty big waste of time for most people I think. You might as well just spend the time to get the features you want into the main build, rather then endlessly resyncing patches. Its less work in the long run.
Reply With Quote

  #5  
Old 03-15-2009, 10:09 PM
Llorean Llorean is offline
Rockbox Developer
 
Join Date: Dec 2006
Posts: 397
Default

Do you have any hard numbers for the AA fonts being smaller than the non-AA .fnt file for the same size font?

My understanding is the AA system increases them from 1bpp to 4bpp which necessitates larger files (not smaller).


As for why -
Multifonts requires a significant reworking of the font cache. Right now, the multifont patch uses a significant amount more RAM than just having a single font. It should be possible to reduce this drastically, but nobody who actually uses multifonts is particularly interested in this. They just want their shinys, and don't care that it's not suitable for inclusion since it works "well enough" for their purposes.


AA fonts, I couldn't say. I'm sure it needs some cleanup too, but much like multifont, nobody's actually willing to put in the work. It works well enough, so they'd rather just patch their own builds and use it. It also necessitates more RAM use since fonts are no longer 1bpp images, so this may need some optimizing if that extra RAM cost is passed on to users who don't use AA fonts in the first place (I don't know, haven't looked at the patch).
Reply With Quote

  #6  
Old 03-16-2009, 08:41 AM
greenman greenman is offline
Junior Member
 
Join Date: Apr 2008
Posts: 59
Default

Quote:
Originally Posted by Llorean View Post
Do you have any hard numbers for the AA fonts being smaller than the non-AA .fnt file for the same size font?

My understanding is the AA system increases them from 1bpp to 4bpp which necessitates larger files (not smaller).
Code:
debian:~/rockbox/sim_e200/simdisk/.rockbox/fonts# ls -lh *FreeSans*
-rw-rw-r--  1 user user 68K  2009-03-16 00:21 08-FreeSansBold.aa.fnt
-rw-rw-r--  1 user user 235K 2009-03-16 14:22 08-FreeSansBold.fnt
-rw-rw-r--  1 user user 249K 2009-03-16 14:22 08-FreeSans.fnt
-rw-rw-r--  1 user user 153K 2009-03-16 00:09 09-FreeSans.aa.fnt
-rw-rw-r--  1 user user 89K  2009-03-16 00:21 09-FreeSansBold.aa.fnt
-rw-rw-r--  1 user user 241K 2009-03-16 14:10 09-FreeSansBold.fnt
-rw-rw-r--  1 user user 256K 2009-03-16 14:08 09-FreeSans.fnt
-rw-rw-r--  1 user user 170K 2009-03-16 00:11 10-FreeSans.aa.fnt
-rw-rw-r--  1 user user 100K 2009-03-16 00:22 10-FreeSansBold.aa.fnt
-rw-rw-r--  1 user user 402K 2009-03-16 14:10 10-FreeSansBold.fnt
-rw-rw-r--  1 user user 426K 2009-03-16 14:08 10-FreeSans.fnt
-rw-rw-r--  1 user user 214K 2009-03-16 00:12 11-FreeSans.aa.fnt
-rw-rw-r--  1 user user 125K 2009-03-16 00:23 11-FreeSansBold.aa.fnt
-rw-rw-r--  1 user user 409K 2009-03-16 14:10 11-FreeSansBold.fnt
-rw-rw-r--  1 user user 437K 2009-03-16 14:08 11-FreeSans.fnt
-rw-rw-r--  1 user user 233K 2009-03-16 00:12 12-FreeSans.aa.fnt
-rw-rw-r--  1 user user 137K 2009-03-16 00:23 12-FreeSansBold.aa.fnt
-rw-rw-r--  1 user user 418K 2009-03-16 14:11 12-FreeSansBold.fnt
-rw-rw-r--  1 user user 449K 2009-03-16 14:09 12-FreeSans.fnt


FreeSans File Size Comparison
style .aa.fnt  .fnt    %
 8b     68     235   29%
  9    153     256   60%
 9b     89     241   37%
 10    170     426   40%
10b    100     402   25%
 11    214     437   49%
11b    125     409   31%
 12    233     449   52%
12b    137     418   33%
The same seems to be true for DeJaVu and other fonts that are proprietary. On average, .aa.fnt files are 39% smaller than normal .fnt files. Am I missing something here?

Quote:
Originally Posted by Llorean View Post
As for why -
Multifonts requires a significant reworking of the font cache. Right now, the multifont patch uses a significant amount more RAM than just having a single font. It should be possible to reduce this drastically, but nobody who actually uses multifonts is particularly interested in this. They just want their shinys, and don't care that it's not suitable for inclusion since it works "well enough" for their purposes.
I guess we all have different definitions of 'shiny'. For instance, to me, games aren't very useful, but others can't live without them. To me, the interface is key - hence my interest in better looking fonts and better usage of font size in layout. Even if it were limited to just three extra font sizes, it would be an improvement. I hear you say 'nobody' is interested. I suspect a theme-making user-base would be interested. Is it rather that this part has a steeper learning curve, or is it too tedious to make this worth someone's while without pay?

Quote:
Originally Posted by Llorean View Post
AA fonts, I couldn't say. I'm sure it needs some cleanup too, but much like multifont, nobody's actually willing to put in the work. It works well enough, so they'd rather just patch their own builds and use it. It also necessitates more RAM use since fonts are no longer 1bpp images, so this may need some optimizing if that extra RAM cost is passed on to users who don't use AA fonts in the first place (I don't know, haven't looked at the patch).
I can see how more fonts means more RAM, but I'm not sure I understand what you mean about 1bpp images. They're both bitmap fonts - one is just anti-aliased, right? If the font file is smaller, won't they likewise take up less space in RAM? And with file sizes 40% smaller, why not have two or three fonts, since we're already used to allocating about that much RAM to fonts anyway?

Again - is this more about a higher learning curve, or is it too tedious to do without pay?

Quote:
Originally Posted by saratoga View Post
Anyway maintaining a custom build is a pretty big waste of time for most people I think. You might as well just spend the time to get the features you want into the main build, rather then endlessly resyncing patches. Its less work in the long run.
It makes sense that people are concentrating on the core. However, these particular patches seem pretty useful in terms of interface. Larger fonts are great for more important data - what's playing now. When I'm running, I don't have to squint to see what's on or what's next. Other data can be smaller so that if I want to take the time, I can look closer. Date could be small, but time could be larger. Top that off with the fact that anti-alias fonts are clearly more legible at any size. These patches really should not be closed. They should be in the core too.

Last edited by greenman; 03-16-2009 at 09:06 AM. Reason: added response to saratoga.
Reply With Quote

  #7  
Old 03-16-2009, 09:28 AM
kugel's Avatar
kugel kugel is offline
Rockbox Developer
 
Join Date: Dec 2006
Location: Berlin, Germany
Posts: 1,153
Default

I think nobody is really against anti-aliased fonts (at least not against it enough to keep it out in the long run). But there's some cleanup to do, and the mpegplayer problem needs to be fixed too.

The other problem (which is probably worse), is that there's no maintainer. If it was in SVN, nobody could really take care about the code in the case it gets broken.
But I think this problem applies to the current font system too, and we're just lucky that it's working reliably for years.

The one that is able to fix the mpegplayer problem will be able to maintain the code in the core too (at least from what I've noticed). So, I think once that's fixed, AA fonts do have a good chance to get into SVN (I'm all for it).
__________________
;;
Reply With Quote

  #8  
Old 03-16-2009, 12:40 PM
Llorean Llorean is offline
Rockbox Developer
 
Join Date: Dec 2006
Posts: 397
Default

Quote:
Originally Posted by greenman View Post
Code:
debian:~/rockbox/sim_e200/simdisk/.rockbox/fonts# ls -lh *FreeSans*
-rw-rw-r--  1 user user 68K  2009-03-16 00:21 08-FreeSansBold.aa.fnt
-rw-rw-r--  1 user user 235K 2009-03-16 14:22 08-FreeSansBold.fnt
-rw-rw-r--  1 user user 249K 2009-03-16 14:22 08-FreeSans.fnt
-rw-rw-r--  1 user user 153K 2009-03-16 00:09 09-FreeSans.aa.fnt
-rw-rw-r--  1 user user 89K  2009-03-16 00:21 09-FreeSansBold.aa.fnt
-rw-rw-r--  1 user user 241K 2009-03-16 14:10 09-FreeSansBold.fnt
-rw-rw-r--  1 user user 256K 2009-03-16 14:08 09-FreeSans.fnt
-rw-rw-r--  1 user user 170K 2009-03-16 00:11 10-FreeSans.aa.fnt
-rw-rw-r--  1 user user 100K 2009-03-16 00:22 10-FreeSansBold.aa.fnt
-rw-rw-r--  1 user user 402K 2009-03-16 14:10 10-FreeSansBold.fnt
-rw-rw-r--  1 user user 426K 2009-03-16 14:08 10-FreeSans.fnt
-rw-rw-r--  1 user user 214K 2009-03-16 00:12 11-FreeSans.aa.fnt
-rw-rw-r--  1 user user 125K 2009-03-16 00:23 11-FreeSansBold.aa.fnt
-rw-rw-r--  1 user user 409K 2009-03-16 14:10 11-FreeSansBold.fnt
-rw-rw-r--  1 user user 437K 2009-03-16 14:08 11-FreeSans.fnt
-rw-rw-r--  1 user user 233K 2009-03-16 00:12 12-FreeSans.aa.fnt
-rw-rw-r--  1 user user 137K 2009-03-16 00:23 12-FreeSansBold.aa.fnt
-rw-rw-r--  1 user user 418K 2009-03-16 14:11 12-FreeSansBold.fnt
-rw-rw-r--  1 user user 449K 2009-03-16 14:09 12-FreeSans.fnt


FreeSans File Size Comparison
style .aa.fnt  .fnt    %
 8b     68     235   29%
  9    153     256   60%
 9b     89     241   37%
 10    170     426   40%
10b    100     402   25%
 11    214     437   49%
11b    125     409   31%
 12    233     449   52%
12b    137     418   33%
The same seems to be true for DeJaVu and other fonts that are proprietary. On average, .aa.fnt files are 39% smaller than normal .fnt files. Am I missing something here?
Do these versions of the fonts contain the full character set, or is the converter only antialiasing a selection of the characters?
Quote:
Originally Posted by greenman View Post

I guess we all have different definitions of 'shiny'. For instance, to me, games aren't very useful, but others can't live without them. To me, the interface is key - hence my interest in better looking fonts and better usage of font size in layout. Even if it were limited to just three extra font sizes, it would be an improvement. I hear you say 'nobody' is interested. I suspect a theme-making user-base would be interested. Is it rather that this part has a steeper learning curve, or is it too tedious to make this worth someone's while without pay?
Rockbox is a hobby. "Being fun" or "Being interesting" is what makes it worth someone's while, rather than usually "how many non-developers are interested." When I suggested 'nobody' was interested I meant "nobody who wants the feature apparently wants it enough to do the work." For example, you're not doing the work either. The usual "Well, I don't know C" may apply, but all the skills necessary to do it can be learned.

Meanwhile - games don't take up any additional RAM. Games come virtually without cost. Disk space is the only one, and users can remove them. Comparing them with Multifont is a very poor comparison as it doesn't really compare two things with the same impact or significance to the overall user experience. If you don't want a game, it's just not there. If you don't want multifont, the code to deal with all the extra fonts is still in RAM, and any memory reserved for their use is still allocated so that reboots aren't necessary. So the code and memory use need to be very efficient.

Quote:
Originally Posted by greenman View Post
I can see how more fonts means more RAM, but I'm not sure I understand what you mean about 1bpp images. They're both bitmap fonts - one is just anti-aliased, right? If the font file is smaller, won't they likewise take up less space in RAM? And with file sizes 40% smaller, why not have two or three fonts, since we're already used to allocating about that much RAM to fonts anyway?
"Bitmap" doesn't define the bit depth on its own. It's like the difference between a 256 color bitmap, and a 32-bit color bitmap. Our fonts are 1bpp. You can't describe antialiasing at 1bpp data density in a bitmap font without compression, which would slow it significantly if they were to be decompressed realtime from memory. Even if they're smaller on disk due to compression, you'd uncompress them at load so that they're stored more or less ready to draw. Because you have "Black, Dark, Light, White" instead of just "Black, White" as possible values (or possibly "Black, Very Dark, Somewhat Dark, Medium, Light, Lighter, Lightest, White") you need twice, or four times, as much RAM per pixel to be able to hold the values. Looking at the disk size of the fonts isn't useful if they're compressed.

Quote:
Originally Posted by greenman View Post
It makes sense that people are concentrating on the core. However, these particular patches seem pretty useful in terms of interface. Larger fonts are great for more important data - what's playing now. When I'm running, I don't have to squint to see what's on or what's next. Other data can be smaller so that if I want to take the time, I can look closer. Date could be small, but time could be larger. Top that off with the fact that anti-alias fonts are clearly more legible at any size. These patches really should not be closed. They should be in the core too.
"They should be in the core because they work from a user perspective" is not the philosophy we develop by.

Two things need to be true:
1) They need to do, from the user perspective, what they set out to do.
2) They need to do it, from a developer perspective, in a way that has a minimal negative impact on everything else.


Neither of these patches meet, or come close to meeting, #2 effectively yet. Saying "I think they should be included" doesn't change this. Work on them, or please stop complaining about it, since until somebody like you who wants them gets off his rear end and gets dedicated to it, their situation won't change.

I don't mean offense, but it's just tiring to see people regularly say "I refuse to learn the necessary skills and work on it, but why isn't someone else doing it simply because I think it's more important than what they're personally interested in?" This is very much what it sounds like when people continually say "I think this is more valuable, and one of you guys should be working on it."

Last edited by Llorean; 03-16-2009 at 01:38 PM.
Reply With Quote

  #9  
Old 03-16-2009, 04:10 PM
greenman greenman is offline
Junior Member
 
Join Date: Apr 2008
Posts: 59
Default

Quote:
Originally Posted by Llorean View Post
Do these versions of the fonts contain the full character set, or is the converter only antialiasing a selection of the characters?
I used the makefont tool for the regular fonts and the rbthemes tool for the aa fonts. I don't actually know how to view them outside of either the sim or my rockbox, and I haven't asked rbthemes whether they trunkated the font build. I'm betting you know better than I. Can you tell me?

Quote:
Originally Posted by Llorean View Post
Rockbox is a hobby. "Being fun" or "Being interesting" is what makes it worth someone's while, rather than usually "how many non-developers are interested." When I suggested 'nobody' was interested I meant "nobody who wants the feature apparently wants it enough to do the work." For example, you're not doing the work either. The usual "Well, I don't know C" may apply, but all the skills necessary to do it can be learned.
True - I haven't used C in over 20 years, and I could probably relearn it. So you're telling me that if I want the challenge, it's mine - or someone elses. I get it. Thanks - that clears that up.

Quote:
Originally Posted by Llorean View Post
Meanwhile - games don't take up any additional RAM. Games come virtually without cost. Disk space is the only one, and users can remove them. Comparing them with Multifont is a very poor comparison as it doesn't really compare two things with the same impact or significance to the overall user experience. If you don't want a game, it's just not there. If you don't want multifont, the code to deal with all the extra fonts is still in RAM, and any memory reserved for their use is still allocated so that reboots aren't necessary. So the code and memory use need to be very efficient.

"Bitmap" doesn't define the bit depth on its own. It's like the difference between a 256 color bitmap, and a 32-bit color bitmap. Our fonts are 1bpp. You can't describe antialiasing at 1bpp data density in a bitmap font without compression, which would slow it significantly if they were to be decompressed realtime from memory. Even if they're smaller on disk due to compression, you'd uncompress them at load so that they're stored more or less ready to draw. Because you have "Black, Dark, Light, White" instead of just "Black, White" as possible values (or possibly "Black, Very Dark, Somewhat Dark, Medium, Light, Lighter, Lightest, White") you need twice, or four times, as much RAM per pixel to be able to hold the values. Looking at the disk size of the fonts isn't useful if they're compressed.
Okay - thanks that clears up a lot of misunderstanding. I got my answer. Fatter maps means more space RAM, regardless of file compression.

Quote:
Originally Posted by Llorean View Post
"They should be in the core because they work from a user perspective" is not the philosophy we develop by.

Two things need to be true:
1) They need to do, from the user perspective, what they set out to do.
2) They need to do it, from a developer perspective, in a way that has a minimal negative impact on everything else.

Neither of these patches meet, or come close to meeting, #2 effectively yet. Saying "I think they should be included" doesn't change this. Work on them, or please stop complaining about it, since until somebody like you who wants them gets off his rear end and gets dedicated to it, their situation won't change.
I get where you're coming from. "Participate or don't."

Quote:
Originally Posted by Llorean View Post
I don't mean offense, but it's just tiring to see people regularly say "I refuse to learn the necessary skills and work on it, but why isn't someone else doing it simply because I think it's more important than what they're personally interested in?" This is very much what it sounds like when people continually say "I think this is more valuable, and one of you guys should be working on it."
No offense taken. Obviously, for someone it was fun at first, but as they realized the effort was no longer fun, they just stopped working on these.

I'm interested enough to learn what I have. I'm not sure if I'm interested enough to go further. So I'll check back in another year to see what direction Rockbox has gone. By then I'm not sure there will be that many e200's left to make it worth the while to keep compiling for it, or if I'll still even have mine. I don't think they're making it any longer. There are cheaper, more versatile models out there now. But it's been fun while it lasted. I look forward to seeing where rockbox goes next.

I appreciate your taking the time out of your day to explain. Your extra effort does not go unnoticed. Thanks.
Reply With Quote

  #10  
Old 03-16-2009, 04:24 PM
greenman greenman is offline
Junior Member
 
Join Date: Apr 2008
Posts: 59
Default

Quote:
Originally Posted by kugel View Post
...The one that is able to fix the mpegplayer problem will be able to maintain the code in the core too (at least from what I've noticed). So, I think once that's fixed, AA fonts do have a good chance to get into SVN (I'm all for it).
It sounds like we're waiting for 'Neo'. (The one). Hey, I really liked your last build. Sorry you had to give it up, but I wish you all the best in playing around on core. Like you, I hope aa fonts make it into SVN.
Reply With Quote

  #11  
Old 03-16-2009, 04:35 PM
Llorean Llorean is offline
Rockbox Developer
 
Join Date: Dec 2006
Posts: 397
Default

I don't actually know whether the files are compressed, or truncated, or what. The smaller size, to me, seems to indicate that there's something going on beyond what's seen. I asked because I was hoping you knew. If I'd know, I would've said it up front, rather than dancing around asking further questions about it. I'm very much not the sort of person to be indirect, when directness will save time.
Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



All times are GMT -5. The time now is 05:08 PM.