Using Canon's Built-in Proportional Font

[Pelican]

Hi guys,

 

What do you think about using Canon's own font in ML menu?

I like it much better than the fixed width fonts.

 

I've just found the character bitmaps and the parameters in the 7D 1.1.0 dump.

 

The character codes (UTF-8) have listed in 32 bit format.

ROM:FF617540: 48 43 61 6e 6f 6e 47 6f 74 68 69 63 00 2f 2f 2f  HCanonGothic.///

ROM:FF617550: 20 00 00 00 21 00 00 00 22 00 00 00 23 00 00 00   ...!..."...#...

...

The character data starts right after the character codes at 0xFF61C4A8 .

ROM:FF61C4A0: c6 bb 06 00 98 bc 06 00|01 00 01 00 0c 00 00 00  ................

...

 

The structure of the font data:  lW, hW, lH, hH, lCW, hCW, lXO, hXO, lYO, hYO, DT[], PD[]

lW,hW: width of the bitmap (low, high)

lH,hH: height of the bitmap

lCW,hCW: the actual character width

lXO,hXO: X offset of the character bitmap data

lYO,hYO: Y offset of the character bitmap data

DT[]: data bytes of the character bitmap, size: H*round up(W / 8)

PD[]: padding bytes: 0-4(?) zero byte;

 

We can find the existing routines in the Canon firmware or we can write our own.

 

How do you like it?

 

550D 108: 0xFF661A94, 0xFF666464

50D 107: 0xFF05E1C8 , 0xFF063000

 

Just grabbed the first hundreds of chars from the dump:

 

There is another font:

 

ROM:FF688228: 43 61 6e 6f 6e 4d 6f 6e 6f 73 70 61 63 65 00 00  CanonMonospace..

ROM:FF688238: 20 00 00 00 21 00 00 00 22 00 00 00 23 00 00 00   ...!..."...#...

...

 

We can play with this too...

[Pelican]

The full font image (800x4249) is here: http://pel.hu/down/HCanonGothic.png

[Alex]

かっこいい　:)

Can you share the source code for decoding font data?

On Tue, Mar 15, 2011 at 9:32 AM, Pelican <p...@pel.hu> wrote:
> The full font image (800x4249) is here: http://pel.hu/down/HCanonGothic.png
>
>

> --
> http://magiclantern.wikia.com/
>
> To post to this group, send email to ml-d...@googlegroups.com
> To unsubscribe from this group, send email to ml-devel+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/ml-devel?hl=en

[Antony Newman]

Great find Pel!

AJ

[Trammell Hudson]

On Tue, Mar 15, 2011 at 03:56:58AM -0400, Pelican wrote:
> What do you think about using Canon's own font in ML menu?
>
> I like it much better than the fixed width fonts.

Wow! What a great find! We should dump the bigtext generated fonts
and switch over to the much nicer builtin ones. It will both save
on RAM usage and make ML look better integrated.

> [...]

> ROM:FF617540: 48 43 61 6e 6f 6e 47 6f 74 68 69 63 00 2f 2f 2f
> HCanonGothic.///

Those looks like it should be easy to locate in other dumps.
It is nice of them to have such clear labels.

--
Trammell

[Piers]

Well done Pel! (I'll stop making builds using vera sans)

A lot of the menu code does currently rely on a fixed-width font, so there's a bit of work there (like, we have to insert (and handle) a TAB or something).

Plus now we can start on the much needed Arabic, Cyrillic, C/J/K and Thai localisations!

PG

[Piers]

I forgot Greek, sorry (and I'm taking non-English western for granted, of course)

PG

[arm.indy]

Good catch Pel !

* in 550d 1.0.9 :

FF661A94 "HCanonGothic",0
//character codes
ROM:FF661AA4 DCD
0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27 ; 0x5f * 4
...
ROM:FF661AA4 DCD 0x78,0x79,0x7A,0x7B,0x7C,0x7D,0x7E
// ??
ROM:FF661C20 DCD
0xA1C2,0xA2C2,0xA3C2,0xA4C2,0xA5C2,0xA6C2,0xA7C2,0xA8C2 ;0x76b*4
ROM:FF661C20 DCD
0xA9C2,0xAAC2,0xABC2,0xACC2,0xADC2,0xAEC2,0xAFC2,0xB0C2
ROM:FF661C20 DCD
0xB1C2,0xB2C2,0xB3C2,0xB4C2,0xB5C2,0xB6C2,0xB7C2,0xB8C2
...
ROM:FF661C20 DCD
0x86D9,0x87D9,0x88D9,0x89D9,0x8AD9,0x8BD9,0x8CD9,0x8DD9
ROM:FF661C20 DCD
0x8ED9,0x8FD9,0x90D9,0x91D9,0xB3D9,0xB4D9
// ??
ROM:FF6621D8 DCD
0x81B8E0,0x82B8E0,0x83B8E0,0x84B8E0,0x85B8E0,0x86B8E0,0x87B8E0,0x88B8E0
ROM:FF6621D8 DCD
0x89B8E0,0x8AB8E0,0x8BB8E0,0x8CB8E0,0x8DB8E0,0x8EB8E0,0x8FB8E0,0x90B8E0
...
ROM:FF6621D8 DCD 0xBCBBEF,0x81BCEF,0x88BCEF,0x89BCEF,
0x8BBCEF,0x8CBCEF,0x8DBCEF,0x8FBCEF
ROM:FF6621D8 DCD 0x9ABCEF,0x9FBCEF,0x9EBDEF
// bitmap positions
ROM:FF663F84 DCD 0, 0xE,0x38,0x52,0xBC,
0x132,0x1B4,0x21A
ROM:FF663F84 DCD 0x22C,0x27E,0x2D0,0x2FA,0x34C,0x35E,
0x374,0x386
ROM:FF663F84 DCD 0x3CC,0x432,0x45C,0x4A2,0x4E8,0x54E,
0x594,0x5FA
...
ROM:FF663F84 DCD 0x60DA8,0x60E02,0x60E78,0x60E8E,
0x60EA4,0x60F3E,0x60F64,0x60FFE
//character data
// offset 0
ROM:FF666464 DCW 1, 1, 0xC, 0, 0
ROM:FF66646E DCB 0
ROM:FF66646F DCB 0
ROM:FF666470 DCB 0
ROM:FF666471 DCB 0
// offset 0xE
ROM:FF666472 DCW 4,0x1E, 0xB, 3, 4
ROM:FF66647C DCB 0xF0 ; ­
...
// offset 0x38
ROM:FF66649C DCW 0xA, 8,0x13, 4, 3
ROM:FF6664A6 DCB 0xF3 ; ¾
...
// offset 0x60FFE
ROM:FF6C7462 DCW 0x1C,0xB,0x24, 4,0x10
ROM:FF6C746C DCB 7
...
ROM:FF6C74AC DCB "CanonMonospace",0


Indy

[Pelican]

Thank you!
Maybe the 550D dump I used was also 1.0.9 not 1.0.8 because I've found
these addresses.
Or the two version is so similar?
I've made a topic at CHDK forum:
http://chdk.setepontos.com/index.php?topic=6204.0
I haven't found any code using these data...

Good catch Pel !

* in 550d 1.0.9 :

Indy

--

[Alex]

The addresses in 1.0.8 and 1.0.9 are the same (the fonts were not included in the update).

[Pelican]

OK, thanks. I've found the 7D also has the same addresses in all version.

[Alex]

First "hello world" message.

It seems Canon doesn't use this font for UI, because their fonts have smooth edges and this one has not. Probably it's an emergency font (used before the SVG graphics engine is fully initialized).

If you want to play with the code at this stage, just ask.

High-level code:

    bfnt_puts("Hello, world!", 10, 20, COLOR_BLACK, COLOR_WHITE);
    int msg[] = {0x9381e3, 0x9382e3, 0xab81e3, 0xa181e3, 0xaf81e3, 0};
    bfnt_puts_utf8(msg, 250, 20, COLOR_BLACK, COLOR_WHITE);

[Trammell Hudson]

On Tue, Mar 15, 2011 at 11:42:41PM +0100, Alex wrote:
> First "hello world" message.

That looks great. I'm excited about modifying bmp_printf() to use
the new fonts this weekend.

> It seems Canon doesn't use this font for UI, because their fonts have smooth
> edges and this one has not. Probably it's an emergency font (used before the
> SVG graphics engine is fully initialized).

I'm thinking that we will probably still want to include our smallest bitmap
font so that when starting on a new platform (T3i, anyone?) it is possible to
have something to write to the screen before a full ROM dump is created.

--
Trammell

[Antony Newman]

Alex,

Looks can be deceptive.  

You will need to replace your single pass bfnt_puts() with a two pass routine.

Pass 1:  Scale the font to a new size -> pixels should end up in the corners of the chessboard.
              if you want 2 x 2 image, you distribute (or sample) the pixels to a 3 x 3 grid.

Pass 2:  On each chess square -> count the corners with pixels.
              This represents a colour 0 (black) -> 4 (white)

I'll willing to bet your ハット that's what Cannon have done!

AJ

[Pelican]

I don't think so. Maybe the software antialiasing on the fly...

 

From: ml-d...@googlegroups.com [mailto:ml-d...@googlegroups.com] On Behalf Of Alex
Sent: Tuesday, March 15, 2011 6:43 PM
To: ml-d...@googlegroups.com
Subject: Re: [ML] Re: Using Canon's Built-in Proportional Font

 

First "hello world" message.

--

[Piers]

Looking at the edges of M'w and W's I'm only seeing two extra shades of grey, so my guess is 2-bit. Could it be that Pel found the MSB? (presumably the LSB would be nearby in that case)

It still blows my mind that the camera GUI could use SVG ... SVG font spec seems to imply there'd be ASCII "<glyph" and similar strings we could search for. Though, ahem, I'm not certain I've actually kept a ROM dump anywhere ...

PG

[Alex]

Trammell,

Yes, we should keep the small font. Not sure about the medium one
(we'll decide after we see the results from AJ's resizing trick).

AJ,

It may work. But Canon also uses larger smooth fonts, so I'm sure they
don't use this method.

Piers,

Yes, the camera uses SVG, or a subset / modified version of it (see
libcsvg directory). It may be possible that SVG could be already
parsed and stored in the ROM in a binary representation (or maybe it's
just zipped somewhere).

FF4E0F54: 'glyph-name'
FF4E0F60: 'glyph-orientation-horizontal'
FF4E0F80: 'glyph-orientation-vertical'
FF4E0F9C: 'glyphRef'

FF4E10CC: 'http://www.w3.org/1999/xlink:title'
and a ton of other similar strings...

[Alex]

My test code is here, if anyone wants to experiment with it:

https://bitbucket.org/hudson/magic-lantern/changeset/cfba492ea84d

[Antony Newman]

Lucky I bet Alex's hat and not my own!

Using the algorithm I suggested may get the font looking less blocky, but is would not give the additional resolution that the Canon overlay fonts have.   There is no 'blurred' edge where the canon edges are Vertical/Horizontal -> so they are SVG.

When canon do the final plotting they do not take into account the pixel colour of the area they are plotting to, but use darker shades of the current colour (which is a bit easier than finding shades between two overlay colours).

AJ

[arm.indy]

I think the fixed fonts are used within 'author copyright' screen,
and others are used within menus.

Some functions dealing with fonts (550d 108):
-FF2C8008 AcquireFont
-FF2C7FC0 get_font_maybe

there is also a compression library with looks like zlib
FF05B234 lzc_11f_112a
and there are mentions to "compressed bitmap"
See sub_FF2D823C which contains "Codec\\BitmapCodec.c"
and calls
ROM:FF2D8384 BL lzc_112

Indy

[Piers]

Yes, I spent some time (probably far too much) looking at the "ISO" symbol in the font (i.e. Pel's PNG) and onscreen (Alex' Hello world) and the smooth one is not only smooth, it's also larger and proportioned differently.

Re the not-blurred HV edges: yes, they've got a good hinting algo. Curves are always nice and symmetrical too.

PG

[Alex]

Here's the font displayed at half size, with a variation of AJ's
algorithm. A pixel is displayed if in the checkerboard box there fall
2 or more pixels from the big bitmap.

[Pelican]

It's ugly... :-)

-----Original Message-----
From: ml-d...@googlegroups.com [mailto:ml-d...@googlegroups.com] On Behalf
Of Alex

[Carlos]

Please allow me to make a silly question: what's the purpose of using this font? Does it shrink ML code?

Just curiosity

[Pelican]

http://librsvg.sourceforge.net/

-----Original Message-----
From: ml-d...@googlegroups.com [mailto:ml-d...@googlegroups.com] On Behalf
Of Alex
Sent: Thursday, March 17, 2011 10:32 AM
To: ml-d...@googlegroups.com
Subject: Re: RE: [ML] Re: Using Canon's Built-in Proportional Font

[Alex]

> Does it shrink ML code?

Yes. The large font in ML takes a bit more than 10k.

[Piers]

On Friday, March 18, 2011 2:57:34 AM UTC+11, Alex wrote:

> Does it shrink ML code?

Yes. The large font in ML takes a bit more than 10k

... and proportional fonts look better and are easier to read (for the vast majority of the population)

Alex - you could pixel bin that one-bit font down (into a quarter-res 2-bit one) and it would look nicer, e.g.:

original bitmap:

a b

c d

new pixel a_new = (a+b+c+d)>>2.

LOADS more math to do and to draw, but it would look nicer

PG

[Alex]

Piers,

> new pixel a_new = (a+b+c+d)>>2.

See attachment. Previous version was the same, but with >> 1.

[Piers]

Ah, well, what's the output buffer. As the out pixel's 2-bit's deep you have to store it either planar or in a whole byte (or packed in ungainlyly), and to render, map it to one of the Canon colours.

Or shrink-as-you-render.

Sorry, I haven't looked at your code, I'm trying to do something with a PIC at the moment and it's killing me .. even building the gnu tools to work on the PIC is killing me

PG

[Piers]

yes, should be >>1 for a 2-bit buffer, you're right ...

[Alex]

But Nyquist theory prevent us from getting good results with those
pixel binning algorithms... although a bit better than pixel skipping
:)

On Thu, Mar 17, 2011 at 11:45 PM, Piers <pie...@gmail.com> wrote:
> yes, should be >>1 for a 2-bit buffer, you're right ...
>

[K.]

I like current fonts so if it aint broke ,theres no need to fix this,unless were running out of memory all the time ?

2011/3/17 Alex <broscu...@gmail.com>

[Trammell Hudson]

On Wed, Mar 16, 2011 at 02:01:40PM -0700, arm.indy wrote:
> Some functions dealing with fonts (550d 108):
> -FF2C8008 AcquireFont
> -FF2C7FC0 get_font_maybe

Those sound reasonable places to start looking for Canon's drawing
routines. Until then, I've modified bmp_puts() to use the Canon fonts
and also updated the mkfont tool to output font-small.c in Canon
format:

https://bitbucket.org/hudson/magic-lantern/changeset/decc5ed54c93

The attached 5Dm2 2.0.8 firmware will demo the Canon fonts for the menu,
although there are some size issues that need to be worked out.

The font structures all start with "FNT\0", which makes them easy
to find in the ROM dumps. It looks like the only two are HCanonGothic
and CanonMonoSpace, but there are a few versions of each. The font
structure is defined as:

struct font
{
uint32_t magic; // 0x464e5400 == "FNT\0"
uint16_t off_0x4; // 0xffe2 in most of them?
uint16_t font_width; // off_0x6;
uint32_t charmap_offset; // off_0x8, typicaly 0x24
uint32_t charmap_size; // off_0xc
uint32_t bitmap_size; // off_0x10
const char name[16];
};

On the 5D there are the following fonts added to the stubs.S file:

0xf005e99c: HCanonGothic 40 px, utf8 (0xFFD8)
0xf00cdf54: HCanonGothic 30 px, ascii only (0xFFE2)
0xf00d1110: HCanonGothic 36 px, ascii only (0xFFE2)
0xf00d585c: CanonMonoSpace 40 px, ascii only (0xFFD8)

--
Trammell

[arm.indy]

Trammel,

about Canon GUI and drawing routines, I mapped months ago your 5dm2
107 functions to 550D 108, here:
http://magiclantern.wikia.com/wiki/DryOS_API

addresses should be the same in 109, 99% of time

Indy

>  autoexec.bin
> 81KAfficherTélécharger

[Piers]

I had occasion this morning to play around with my VFinder loupe and I've come to the conclusion that, in fact, Canon DOES use this font for the great majority of the UI - only the grey non-liveview menu appears to have smoother text (and that mainly for "incony" things or numerals - see the "Full Auto" text in the second grab).

So, I think we can chillax about finding the SVG font. Regarding a smaller font, I'd vote we scale the big canon one down (possibly on the fly, how much writing do we do? Audio meters, yes, maybe cache numerals) - and anti-alias that in a future release (if y'all can wait a month or two I'm happy to do that).

(Also note, Alex, as you can see my build (just about the latest I think) is not clearing the screenshot countdown)

(And another aside, with the loupe it seems that the colour on the viewfinder is 4:2:2 (or even 4:2:0) - the green in the full auto box (and the red on zebs) is clearly at half res, even though the overlay BMP is 8-bit indexed colour. This is not apparent on screenshots)

PG

[Alex]

Piers,

You are the one who should clear the screenshot timer (that's why it
doesn't update during last 5 seconds). Press some buttons.

Scaling in real-time doesn't give good results; terminus looks better.

[Piers]

I've ported Tramm's changes onto the 550D branch.

In the 550D ROM (1.0.8) I could find only the 24 pixel Gothic and Mono font, so that's all we have. (i.e. the handy tag "FNT\0" only appears 3 times and one def. isn't a font)

Now we can all see the "spacing issues" referred to: the built in font is a lot taller, so some current menus go offscreen. (so this is a curiosity build at the moment)

But the autoexec.bin is 20K smaller.

I intend to play around and try to make a useable small-font routine with a view to only Canon proportional fonts in ML - but it will require significant menu rearranging!.

I haven't really looked at Trammel's, but Alex's text rendering routines had a fair bit of scope for efficiency improvement.

Here be the changes:

https://bitbucket.org/piersg/magic-lantern-pg-fooling/changeset/8a0b4c624500

PG

[Piers]

Oh, I had to cheat and comment out bmp_puts_w() - what's that about?

... and there may be a cheat or two on top of that, I just wanted to see it work.

PG

[Piers]

Here's using an anti-aliased half mono font for "font_med" - it's not yellow cos I don't think we reliably get a ramp of colours other than for white-grey-black in the palette.

Performance is not too shabby, I feel

PG

[Piers]

Further work in progress:

I've added some colour capability, but the anti-aliasing (i.e. the pixels which are not either fully FG or BG) is still hard-coded to greys (and does look rather odd when the spot meter draws itself in black.

Font_large is now Font-Gothic (I globally changed references to it, possibly should have just made font_large refer to gothic_24, just did it as I went). So the menus are further munged up.

Have dropped font_large and med from the source, this ML is now 122,880 bytes small.

sauce is at https://bitbucket.org/piersg/magic-lantern-pg-fooling/changeset/54dd70ee6cb3

[Antony Newman]

Piers,

Was it possible to change the 'skin' on the 550D palette over to:

http://images.wikia.com/magiclantern/images/b/b4/TEST_RGB.jpg

AJ

[Piers]

That actually was the palette in all the "show palette"s I tried, and I am aware that you've found some palette calls/properties, but I just haven't gone there yet given that the UI is so overwhelmingly white-on-dark. I'll probably get around to it.

Once/if I find a way to make menus work with the new font, I then have the usual large amount of code cleanup to do, then we'll try other colours ...

PG

[Antony Newman]

PG,

I think when Canon anti-alias up the border of their font, they decide which of the horizontal 'Colours' it is and select darker versions of that colour in the transition (ie they don't attempt to choose mid-point colours between two colours from the Palette).

If you are looking for the Algorithm to do this and find the closest overlay colour to your desired one - I've have an algorithm (used in the 'Magic Circles') which I can share.

AJ

[Piers]

I have to say I'm pretty happy with my AA algo (not efficiency-wise, but I like the results).

(Also, Canon do not, generally, AA the text. Alex picked exactly the worst screenshot to inspect. See my post here from March 21. Looks like the SVG stuff is AA rendered, Canon HGothic is not)

I'll probably allow you to pick start/end colours and then it's "manage palette at own risk".

Something like:

if(colours are in lower 32) {

  decide if light on dark or vice versa

  render in greys accordingly

} else {

  render in range of that colour

}