This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#4733 - Multifont
Attached to Project:
Rockbox
Opened by Ben Keroack (bk) - Sunday, 26 February 2006, 02:46 GMT+1
Last edited by Paul Louden (Llorean) - Thursday, 02 October 2008, 23:02 GMT+1
Opened by Ben Keroack (bk) - Sunday, 26 February 2006, 02:46 GMT+1
Last edited by Paul Louden (Llorean) - Thursday, 02 October 2008, 23:02 GMT+1
|
DetailsThis is a preliminary test version of multifont support (v01) as a diff against current CVS HEAD. This allows for multiple fonts to be loaded and used non-simultaneously with 3-5 defined contexts depending upon target.
Fonts are specified in the theme .cfg with the following tags: browserfont, wpsfont, menufont, tunerfont, recordfont. The old "font" tag is ignored. A font selected through General Settings->Display->Browse Fonts override all current theme settings, emulating the old behavior. Plugins use sysfont. NOTE: Recording screen drawing is currently somewhat broken. Actual recording should be unaffected. 
multifont-v01.patch
(58.4 KiB)
apps/screen_access.c | 4 apps/screens.c | 6 apps/recorder/radio.c | 5 apps/recorder/keyboard.c | 4 apps/recorder/recording.c | 8 apps/recorder/peakmeter.c | 2 apps/tree.c | 4 apps/settings.c | 157 ++++++++++++-- apps/plugins/mp3_encoder.c | 2 apps/plugins/chessbox/chessbox.c | 2 apps/plugins/rockblox.c | 2 apps/plugins/bejeweled.c | 4 apps/plugins/databox/databox.c | 4 apps/plugins/bounce.c | 2 apps/plugins/jpeg.c | 2 apps/plugins/brickmania.c | 2 apps/plugins/viewer.c | 2 apps/plugins/stopwatch.c | 2 apps/plugins/credits.c | 2 apps/gui/buttonbar.c | 2 apps/gui/gwps-common.c | 3 apps/gui/statusbar.c | 8 apps/gui/list.c | 16 + apps/gui/quickscreen.c | 1 apps/gui/list.h | 7 apps/gui/gwps.c | 11 + apps/menu.c | 6 apps/settings.h | 10 apps/filetree.c | 22 +- apps/sound_menu.c | 2 apps/eq_menu.c | 1 firmware/export/font.h | 38 ++- firmware/font.c | 406 ++++++++++++++++++++++--------------- firmware/font_cache.c | 11 - firmware/lru.c | 4 firmware/include/font_cache.h | 21 + firmware/include/lru.h | 2 firmware/include/errno.h | 2 firmware/powermgmt.c | 8 firmware/drivers/lcd-2bit-horz.c | 4 firmware/drivers/lcd-h100-remote.c | 4 firmware/drivers/lcd-h100.c | 4 firmware/drivers/lcd-16bit.c | 4 43 files changed, 570 insertions(+), 243 deletions(-) |
This task depends upon
Closed by Paul Louden (Llorean)
Thursday, 02 October 2008, 23:02 GMT+1
Reason for closing: Later
Additional comments about closing: This task is no longer attempting to address getting Multifont in a state for inclusion. The idea of displaying multiple fonts is good, but this implementation is not progressing. If someone wishes to fix this patch to work, or start a new one, come to IRC or the -dev mailing list and it can be reopened for you, and the hurdles remaining discussed.
Thursday, 02 October 2008, 23:02 GMT+1
Reason for closing: Later
Additional comments about closing: This task is no longer attempting to address getting Multifont in a state for inclusion. The idea of displaying multiple fonts is good, but this implementation is not progressing. If someone wishes to fix this patch to work, or start a new one, come to IRC or the -dev mailing list and it can be reopened for you, and the hurdles remaining discussed.
Attached is an updated patch that should apply cleanly against today's CVS. It includes 45k font buffers, bumped config version and a small convbdf fix.
Here's a rough TODO list for multifont-2.0 which may or may not be ready for 3.1:
* Font cache overhaul
- Unified font cache buffer
- LRU/cache code allows variable-length entry data payloads (for use w/ mixed fonts)
- Make sure not to break unicode or non-Western codepages
* UI
- GUI font choosers for each font type
- Stop ignoring the old "font:" cfg tag, make it work as before
- Fix the FONT_PLUGIN stuff so that plugins consistently use the plugin font
* Other
- Implement an optional remotefont, figure out if a GUI chooser is workable for this
You are to fast for me
I changed the settings storage format of all fonts.
Instead of always allocating MAX_FILENAME and wasting space
the fonts are stored in the following format
%02d:%s e.g. 07:helvR14 which is <length>:<font>
This saves in this example 10 bytes for a font
I also added reseting all fonts if a theme is loaded
This requires the mutlifont patch
now maximum allowed length of 17 chars
custom display width (#5898),
multifont (#4733),
multiple user fonts (#5901),
custom list menu (#5899)
custom line (#5900)
Text is fine in the menu of the plugin.
tried to keep it backward compatible with old themes
by supporting single font themes and multifont themes
with the build date it for
--- rockbox_svn.orig/apps/filetree.c
+++ rockbox_svn/apps/filetree.c
@@ -528,7 +528,7 @@ int ft_enter(struct tree_context* c)
font_load(buf, FONT_RECORD);
set_file(buf, (char *)global_settings.recordfont, MAX_FILENAME);
#endif
-
+ /* dont set userfonts because of the buffer problem */
break;
case TREE_ATTR_KBD:
looks for FONT_RECORD but that shouldn't exist yet?
perhaps I am applying the patch incorectly.
Maybe a good coder could try to upadte this patch ?
And you need the userfonts patch only if you want to use the customline patch
firmware/drivers/lcd-remote-2bit-vi.c
apps/plugins/chessbox/chessbox.c
Why is it that the userfonts patch never has to be synced? Is it just that it's dependent on the multifont patch?
Maybe we should merge the two patches
patching file rockbox_svn/firmware/drivers/lcd-remote-2bit-vi.c
Reversed (or previously applied) patch detected! Assume -R? [n]
any ideas?
patching file apps/gui/gwps-common.c
Reversed (or previously applied) patch detected! Assume -R? [n]
Here are the patches i applied in order with their flyspray numbers (just to check that i applied the right ones)
6796(ymargin) --> 2954(scroll_margin) --> 3045(album art) --> 5697(bmp resize) --> multifont
Thank you so much for your help so far, it is very appreciated :)
patching file firmware/export/lcd.h.orig
Hunk #2 FAILED at 395.
1 out of 2 hunks FAILED -- saving rejects to file firmware/export/lcd.h.orig.rej
Just to check that its not an error at my end, where can I get Max's scroll-margins from?
Thanks again, Nick
My concern was that it is failing on a .orig file which to my knowledge should be unaffected by patches, when looking at the code it seems "int y_margin". As in my opinion it would be best if either Max's or the trackers patch could be used and by the looks of it, it shouldn't be too hard to fix. If I'm completly wrong here please let me know so I can stop pestering people....
Thanks for the quick fix Travis
> This fixes the bug where the font changes upon changing anything in the quickscreen or simply exiting back into the WPS.
thanks! :-)
others that are not in the tracker. I started my own scroll_margins patch long time ago
because the original version hat so many problems and failed to sync it with the version in the tracker
patching file apps/plugins/rockpaint.c
Hunk #6 FAILED at 933.
1 out of 11 hunks FAILED -- saving rejects to file apps/plugins/rockpaint.c.rej
Sync Please :)
Did you monologize? You seemed to talk to someone, but here are only posts from you :O
AnywayCan the bug I addressed be fixed?
Note: I can only speak for e200, it might be, that this is only present on the e200.
Basically, when you have set a different menufont and wpsfont this problem occurs: When you go from wps to the wps' context menu, the font changes properly (i.e. snap to nimbus), but when you go back from that context menu(or ay submenu) to the wps by pressing play, the font does not change. It remains the menufont, messing the wps up. Only way to get around is to visit the main menu shortly.
Just a note: I use custom line as well, however I have this bug. Maybe the problem is caused by custom line?
Anyway, thanks for your effort. I'm gonna test the patch as soon as I get home.
Sorry, this is the real sync.
Note: I had to run in twice (normal, -R, normal again) to apply it as a single patch. No problems with album art, bmpresize, ymargin, scroll-margins and custom line applied before.
I begin to hate 1 line SVN changes...
Ok, this time it's deeply tested. It's applying and compiling.
However, I can't test it in a full custom build with some other patches(including custom line), as ymargin doesn't work atm.
Good job anyway, thanks.
After loading simulator StatusBar is empty and then simulator fall. I found that problem with strings "gui_list->display->set_foreground(global_settings.fg_color);" in list.c. Simulator works without them.
Last I tested h3xx simulator with patches: album_art_20071001.patch, scroll-margins_20071006-2.patch, bmpresize-20070430.patch, multifont-20071002c.patch.
After loading simulator StatusBar is empty and then simulator fall. I found that problem with strings "gui_list->display->set_foreground(global_settings.fg_color);" in list.c. Simulator works without them.
Last I tested h3xx simulator with patches: album_art_20071001.patch, scroll-margins_20071006-2.patch, bmpresize-20070430.patch, multifont-20071002c.patch.
They gives some error when compiling, there is something about alarm clock , I dont understend it at all.
%V|265|9|41|15|2|B5B5B5|000000|
%cl:%cM%cp
%V|135|52|175|15|4|F58105|000000|
%al%s%?ia<%ia|%?d2<%d2|>>
%V|135|71|175|15|2|B5B5B5|000000|
%al%s%?id<%id|%?d1<%d1|>>%?iy< (%iy)|>
%V|150|98|160|15|3|F58105|000000|
%al%s%?it<%it|%fn>
%V|135|117|175|15|2|B5B5B5|000000|
%alTrack %pp of %pe - %pc [%pt]
%V|135|135|175|15|2|B5B5B5|000000|
%s%al%?It<Next: %It|%?Fn<Next: %Fn|>>
%V|238|215|62|15|5|333333|000000|
%acVolume: %pv
and everything seemed to work, also I switched to cabbie_unifont to make sure regular themes worked and that worked as well so I think this is ready for you guys to test out.
- if (sscanf(buf, "COPYRIGHT \"%[^\"]", copyright) != 1) {
+ if (sscanf(buf, "COPYRIGHT \"%s\"", copyright) != 1) {
Can you tell what this is for?
Also, sad that you didn't use my cleaned up version. You have so many trailing spaces and stuff.
Couldn't test yet.
Note: I want to make this committable. The font-caching needs to be changed.
Replace the screen-specific fonts with a list of fonts, and references to fonts in that list. i.e. the global settings (.cfg file) would contain a "font:" entry "font: fontname1,fontname2,fontname3" (to ensure that there are no missing fonts in the array, and to maintain compatibility with existing .cfg files), and then separate cfg entries specifying which fonts are used for each screen, such as "menufont: 1", "remote_menufont: 2" etc. (0 is reserved as the font number for the system font, so the user-defined fonts start at 1).
This would (I think) simplify the implementation - the core font code (in firmware/) wouldn't care what the fonts are being used for, it would just deal with a variable-sized array of fonts, and if the same font is used multiple times, it would only be loaded once. I think this would also make using a single font cache simpler.
All calls to, for example, display->set_font(FONT_BROWSER) would then be replaced with something like display->set_font(global_settings.font_browser), and the impact of adding a further place where a custom font can be used would just be an integer in the global settings, rather than a font filename.
Although when the apps/ code is fully adapted to use viewports, the code probably won't need to call set_font any more - it can just specify the font directly in the viewport struct, and we would have separate viewport structs for each screen.
CC mpegplayer.c
mpegplayer.c: In function 'draw_putsxy_oriented':
mpegplayer.c:461: error: too few arguments to function 'rb->font_get_width'
mpegplayer.c:468: error: too few arguments to function 'rb->font_get_bits'
This was with clean SVN as well as bmp-resize patch and Viewports patch (latest version reflecting yesterday's commits).
Yesterday on IRC, Kugel opined that there's a hunk missing that's causing these errors.
width = rb->font_get_width(pf, ch, current_vp->font);
and on 468 make it:
bits = rb->font_get_bits(pf, ch, current_vp->font);
Sorry about that, here's a good patch:
CC mpegplayer.c
mpegplayer.c: In function 'draw_putsxy_oriented':
mpegplayer.c:461: error: 'current_vp' undeclared (first use in this function)
mpegplayer.c:461: error: (Each undeclared identifier is reported only once
mpegplayer.c:461: error: for each function it appears in.)
I'm compiling for Sansa e200.
I'm compiling for Sansa e200.
http://pastebin.com/m35b25191
can't find file to patch at input line 325
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -u -r apps/gui/viewport.c apps/gui/viewport.c
|--- apps/gui/viewport.c 2008-02-07 05:12:48.000000000 -0600
|+++ apps/gui/viewport.c 2008-02-07 05:09:32.000000000 -0600
--------------------------
File to patch:
It's your SVN messed up I think.
Try to download a fresh copy or at least revert it and patch again.
viewport.c is nonexistant.
and that file is not created by viewports-wps1 patch, so where should it come from?
in list.c the patch tries to find a line where the font is defied for the parent-viewports of the remote and the lcd-display.
those lines do not exist in the list.c on my fresh installation (with the
FS#8385=viewports-wps-v1.diff andFS#8457=listvp.3.diff applied).the definition line of the file you want to patch looks like:
.y = 8,
.width = LCD_WIDTH,
.height = (LCD_HEIGHT-8),
.font = FONT_UI,
.drawmode = DRMODE_SOLID,
.xmargin = 0,
.ymargin = 0,
but original coresponding line (i think) looks only like:
.x = 0,
.y = 0,
.width = LCD_WIDTH,
.height = LCD_HEIGHT
and for the remote, you expect:
.y = 8,
.width = LCD_REMOTE_WIDTH,
.height = (LCD_REMOTE_HEIGHT-8),
.font = FONT_UI,
.drawmode = DRMODE_SOLID,
.xmargin = 0,
.ymargin = 0,
but no line with LCD_REMOTE_WIDTH or LCD_REMOTE_HEIGHT exist in list.c
instead, mf should set FONT_UI=FONT_MENU whenever FONT_MENU is set and just leave modules only using FONT_UI alone.
correct me if i dont understand the code right:
you use maxfonts*fontsize as buffer, and put all fonts in the memory.
(userfont1-7, font-wps, font-menu, font-tuner, ...).
and then the font-wps variables are used to index the fontcache, correct?
from my experience as rb user normally you have multiple identical fonts defined in the config. for example font-tuner, font-menu, userfont-1 as nimbus-12.
now as far as i understood the code, you buffer every font in advance, but dont check whether it is already buffered.
wouldnt it be a good idea to check each font whether it is already buffered, and then just use the index to the already buffered font as index for the new font type?
an example would be:
userfont1=nimbus-12
userfont2=nimbus-14
userfont3=nimbus-12
menu-font=nimbus-12
cache would look like:
1: nimbus-12
2: nimbus-14
indexes would look like:
userfont1=1
userfont2=2
userfont3=1
menu-font=1
the only thing i vote for is that we get a decission on which fonts to use for what, because we need vp-list, vp, multifont etc to be consistent in their font usage. if we decide to use font_ui that would be a good idea because we dont have to care about compatiblility. but that cant be decided for mf alone, but the other dependent patches must also know about it.
but somehow it compiled well but the simulator just crashes.
so obviously someone else with much more programming knowledge needs to do this.
what i dont understand: why dont i get an error message from the simulator? it just ends without any error message.... :-(
propbably we should minimize the patch to only the minimum functionality (loading and saving of the fontsettings, giving other functions procedures to identify fonts and help parsing etc, define variable and set them).
so with almost no visual impact except that the functions are inside rockbox to handle multiple fonts.
giving the rest of rockbox a "framework" to use for working with multiple fonts.
font_ui should be maintained as primary font instead of font_menu.
after that "minimized" version is committed, we can do patches for each open part of the work:
one for the wps-multifonting, one for list-multifonting, one for plugin-multifonting, ...
but this is just a proposal, as im not a programmer and thus cant do this anyways :-)
i managed to patch the original patch to:
1) compile with the svn after the vp-list commit
2) need only the wps1-patch
and most important:
3) not use menufont! only use fontui (font tag in configfile).
note that the newer syncs will need at least the wps-vp patch "viewports-wps-v2.diff" to work.
im not checking the syncs against the old version of the wps vp patch.
i cant resync it, so unless someone else kicks in this will stay broken for the moment.
In your proposal (making FONT_UI font 0), what would FONT_SYSFIXED be?
sysfixed would be font[0] then (or whatever). all other fonts would be font[1],....
but as to be seen on irc log of yesterday / this morning we first need to think about a good font caching algorythm :-)
@me: In some ways like with the glyphcache we kinda are doing that...sort of. I think we'd have a riot on our hands if we took font names out of the picture completely though, could be wrong, who knows. If we're headed in the direction I think we're headed in we do need a good font caching system though.
@Thomas Martitz: Why don't you go ahead and up what you have, I have a strong suspicion at this point that your work probably is making more sense than mine..;-)
the main thing is: how can we find an efficient algorythm for caching fonts without wasting memory.
i now also agree that using font=font1,font2,font3 and then use font indexes (1,2,3 for font1,font2,font3) would propably be the most flexible way to implement things.
Well, this will break up themes even more, but that's actually ok. It seems that only userfonts will kept anyway (using a fonts:font1|font2|...|fontn) construct. I'm fine with it.
Though, I'd still like to have costumizable fonts for record screen or radio, so we should reimplement that. Of course in a different way, so that those screens would use userfonts as well.
so
font=nimbus-12.fnt,nimbus-14.fnt
tunerfont=1
menufont=2
listfont=0
would assign the tunerfont to nimbus-12 and menufont to nimbus-14. listfont would by the internal font.
this would also allow easy removal of a font from the list (except for wps and other simultanious-multifonted screens).
the wps-problem could only be addressed by also using
wps-font1=1
wps-font2=2
... in the config.
wpsfont=1,2 :-)
which makes sense and can be consitent for all uses of font "re"-directives.
example:
font=nimbus-12,nimbus-14,nimbus-16
fontwps=2,3
fontmenu=1
fonttuner=1,2
would in this case use the following font for the viewports
wps:
%V...|1|...=nimbus-14, %V...|2|...=nimbus-16
menu:
%V...|1|...=nimbus-12
tuner:
%V...|1|...=nimbus-12, %V...|2|...=nimbus-14
which could be a consistent easy to parse behaviour for all viewport uses.
sorry for the double post.
if you set
font=nimbus-12,nimbus-13,nimbus-14
and in the wps you use:
%V...|2|...
%V...|3|...
then imagine you want to remove nimbus-12 completely from the config.
if you change the font line to
font=nimbus-13,nimbus-14
your wps will be broken unless you also modify all viewport entries.
with separate redirection of the wps-fontindexes line i explained, the change would just be:
font=nimbus-12,nimbus-13,nimbus-14
fontwps=2,3
to
font=nimbus-13,nimbus-14
fontwps=1,2
and no need to change the wps-files at all.
now imagine maybe we will also have wps-like configfiles for menus, tuner, .....
if you then change the fontline, you would need to go through all files to check for viewport references.
I had this idea today for this patch. We should do it this way:
Define userfonts like normal (1-8). Alternatevly allready define them in a list like mentioned before (fonts: font1,font2,...), but this is a bit over my head for now.
0 is FONT_SYSFIXED.
Then we should have this:
Menufont: 1
Browserfont: 2
Radiofont: 1
Recorderfont: 3
(maybe) Pluginfont: 0
This means, that we threw "font" away, and only keep the userfonts at all. However, to not break default themes, every theme.cfg that contains "font" should default to userfont1: font and all those *font: 1 (you know what I mean).
By the way, I brought Browserfont and Menufont seperated in this idea again. After a short talk in irc, it seemed that some devs are in favor of having the possibilty to seperate between this two contexts.
I really like the concept of only having userfonts.
and we should definitely not care about backward compatibility as we will pay for it with unflexibility and unclear design.
also if we are too backwards compatible, people will use the old methods forever. a clear break is better here imho.
so i think we could all agree on defining userfonts with a font=x.fnt,y.fnt,z.fnt directive.
if we use viewports for the browser and for the menu (well, in fact for all possible contexts), then we in fact wont need seperate font directives for them (except if we use my idea above to use a seperate font mapping for each context-viewport).
we would define a "browser viewport" which could use any font we define from the userfonts.
same for menu, radio, .........
we could even allow plugins to either use a default plugin viewport or alternatively have a own viewport definition file!
(so doom could use another font than pacman).
in fact the more we talk about it, the more i think having a completely viewportified rockbox would be the best approach for customizability.
@kugel:
in fact your idea resembles mine, just that we propably should add the flexibility to allow multiple fonts for each context. with viewportified contexts there may be the need to have this in the future.
and if the viewport only needs one, well we dont have to define multiple "remaps".
so in the above example, the config file would look like:
font=font1.fnt,font2.fnt,font3.fnt
menufont=1
browserfont=2
radiofont=1
recorderfont=3
pluginfont=0
wpsfont=1,2,3
which would translate to:
we load font1.fnt, font2.fnt and font3.fnt as fonts for our theme.
then we use:
menu: font1 as %V..1.. definition in the menu viewport (or as font if no viewport is present)
... for all the other *font definitions...
wps: font1 as %V..1.., font2 as %V..2.., font3 as %V..3.. (or font1 if no viewport definitions are present)
in all viewports the sysfixed can be referenced as %V..0.. and is default if no other font is specified.
And sure, the user must be aware, that changing the user fonts hits all contexts, so the user must edit the .wps file too in some cases. But that's still better to define wps fonts again.
BTW: I hope we can get it this way:
We defined the user fonts, and after that we define the viewports for the specific contexts (except for the wps of course). Or we create other context specific files like .wps (i.e. .rps (radio-wps) or something).
radioviewport: x|y|height|width|font|foreground|background.
Of course this includes "viewportifing" all contexts. But that's the wish of everyone I think. That's what viewports were made for.
if we directly use userfont-indexing in the wps-like context files, a user wanting to remove a font manually needs to edit several files to do that.
lets say we have the wps, radiowps, browser, menu and statusline files.
then removing one font would make the user edit all viewport definitions in those files.
(they all could hold several viewport definitions).
if we use reindexing, he could change all that in just 5 lines in the central config file of rockbox.
example:
font=font1,,font3
%V..0..=sysfixed
%V..1..=font1
%V..2..=sysfixed
%V..3..=font3
that way a user can remove a font without having to edit other files.
we will be compatible with all themes not using the multifont patch.
if we use
font: font1.fnt,font2.fnt,font3.fnt
this would be compatible with the normal
font: font1.fnt
method of setting a font.
(do we need to set the full patch there?)
this brings me to another point:
if a viewport uses a font not set, what should we do?
i think we should revert to sysfixed only if NO font is said. if any font is set, we should use font1.
this would also maintain compatiblility with non-mf themes.
its a pitty nobody has come up with a efficient caching method yet.
this topic definitely needs a bit more attention.
the problem why this wont get commited in its current state is the inefficient font glyph caching.
at the moment every font gets its own glyphcache with a fixed length. thus some fonts may have more cache-memory than then need and others will run out of cachespace soon.
so this method is considered ineffective by the devs.
the first thing to get this nearer to commitability would be to find a good and efficient caching algorythm for multiple fonts without wasting cpu, memory and binsize.
The second patch is meant to be applied with my customlist patch at
FS#8799.I recently updated my rockbox build and multifont after a long time.
Unfortunately, I don't quite get what has changed syntax wise in the meantime.
There are so many proposals here,
I don't understand which method is currently used.
The old font declarations don't work anymore, perhaps someone can help me to make it
work again.
Thanks in advance.
At the moment, my font declaration looks like:
menufont: /.rockbox/fonts/nimbus-12.fnt
browserfont: /.rockbox/fonts/nimbus-12.fnt
recordont: /.rockbox/fonts/nimbus-12.fnt
tunerfont: /.rockbox/fonts/nimbus-12.fnt
wpsfont: /.rockbox/fonts/nedore-9.fnt
so why bother with usage guidelines when we know that it will never be implemented in the way it is implemented now?
we need to keep in mind that this is a highly unsupported patch and that a new implementation needs to work in a completely different way.
thus this patch definitely is a dead-end.
maybe to get a clean cut this could get closed and a new task should be opened which explicitly handles a NEW multifont implementation. every effort in this old patch should imho better be put into finding a new glyphcache algorithm.
Activity seems to be slowed down here...
Sorry, that I ask this again,
but could you please post a short example of how to use
multiple fonts with the current patch?
Is it still possible to declare fonts in whileplayingscreens which
don't use viewports?
I want to use two different fonts, one font for the menu and one font
for the wps.
thanks, Hendrik
At first, multifont doesn't support this:
menufont: /.rockbox/fonts/nimbus-12.fnt
browserfont: /.rockbox/fonts/nimbus-12.fnt
recordont: /.rockbox/fonts/nimbus-12.fnt
tunerfont: /.rockbox/fonts/nimbus-12.fnt
wpsfont: /.rockbox/fonts/nedore-9.fnt
anymore (themes using this will be broken).
Multiple fonts are set up like this:
userfontn: /path/to/font/font.fnt (with n being 1 upto 8, and /path/to/rockbox = /.rockbox/fonts in most cases)
example:
userfont1: /.rockbox/fonts/nedore-9.fnt
...
userfont8: /.rockbox/fonts/nedore-9.fnt
As of now, you can only use them in the wps, since it is the only screen which supports configurable viewports (except with my custom list patch(
FS#8799) applied, then the menues/filetree can use a userfont as well).And yes, this means the wps needs viewport. But, that's not a drawback. Viewports is in SVN, and defining a fullscreen which uses a userfont is easy, e.g.
%V|0|0|176|220|2|FFFFFF|000000| # this example is for e200 and uses userfont1.
As you could see, 2 is userfont1. So, userfont2 is 3, and so on. That's because the default font is 1.
I have looked for changes in the theme .cfg file but I can't see anything different from what kugal has outlined a few posts above. As I can tell, the wps and cfg files are okay. Anoyone else getting problems?
Try this
The patch works now. I have tested it very briefly but it does seem to work. Thanks again
CC filetree.c
filetree.c: In function ‘ft_enter’:
filetree.c:510: error: too few arguments to function ‘font_load’
make[1]: *** [/home/jvoegele/src/rockbox/build/apps/filetree.o] Error 1
make: *** [build] Error 2
Thanks.
Also I'm not sure how to deal with the WPSEDITOR.