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