Using Canon's Built-in Proportional Font

263 views
Skip to first unread message

Pelican

unread,
Mar 15, 2011, 3:56:58 AM3/15/11
to ml-d...@googlegroups.com

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:

CanonFont.png

 

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

image001.png

Pelican

unread,
Mar 15, 2011, 4:32:17 AM3/15/11
to ml-d...@googlegroups.com
The full font image (800x4249) is here: http://pel.hu/down/HCanonGothic.png


Alex

unread,
Mar 15, 2011, 4:35:43 AM3/15/11
to ml-d...@googlegroups.com
かっこいい :)

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

unread,
Mar 15, 2011, 5:20:32 AM3/15/11
to ml-d...@googlegroups.com
Great find Pel!

AJ

Trammell Hudson

unread,
Mar 15, 2011, 6:35:21 AM3/15/11
to ml-d...@googlegroups.com
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

unread,
Mar 15, 2011, 7:14:42 AM3/15/11
to ml-d...@googlegroups.com
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

unread,
Mar 15, 2011, 7:20:56 AM3/15/11
to ml-d...@googlegroups.com
I forgot Greek, sorry (and I'm taking non-English western for granted, of course)

PG

arm.indy

unread,
Mar 15, 2011, 4:15:04 PM3/15/11
to Magic Lantern firmware development
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

unread,
Mar 15, 2011, 5:55:35 PM3/15/11
to ml-d...@googlegroups.com
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

unread,
Mar 15, 2011, 5:57:51 PM3/15/11
to ml-d...@googlegroups.com
The addresses in 1.0.8 and 1.0.9 are the same (the fonts were not included in the update).

Pelican

unread,
Mar 15, 2011, 6:20:04 PM3/15/11
to ml-d...@googlegroups.com

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

Alex

unread,
Mar 15, 2011, 6:42:41 PM3/15/11
to ml-d...@googlegroups.com
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);

hello.bmp

Trammell Hudson

unread,
Mar 15, 2011, 9:03:25 PM3/15/11
to ml-d...@googlegroups.com
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

unread,
Mar 15, 2011, 9:03:42 PM3/15/11
to ml-d...@googlegroups.com
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

unread,
Mar 15, 2011, 9:29:15 PM3/15/11
to ml-d...@googlegroups.com

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

unread,
Mar 15, 2011, 9:45:01 PM3/15/11
to ml-d...@googlegroups.com
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

unread,
Mar 16, 2011, 3:46:58 AM3/16/11
to ml-d...@googlegroups.com
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

unread,
Mar 16, 2011, 4:31:19 AM3/16/11
to ml-d...@googlegroups.com
My test code is here, if anyone wants to experiment with it:

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

Antony Newman

unread,
Mar 16, 2011, 9:39:26 AM3/16/11
to ml-d...@googlegroups.com
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

unread,
Mar 16, 2011, 5:01:40 PM3/16/11
to Magic Lantern firmware development
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

unread,
Mar 16, 2011, 6:40:30 PM3/16/11
to ml-d...@googlegroups.com
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

unread,
Mar 17, 2011, 10:32:03 AM3/17/11
to ml-d...@googlegroups.com
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.

hello-half.bmp

Pelican

unread,
Mar 17, 2011, 11:02:09 AM3/17/11
to ml-d...@googlegroups.com
It's ugly... :-)

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

Carlos

unread,
Mar 17, 2011, 11:07:58 AM3/17/11
to ml-d...@googlegroups.com, Pelican
Please allow me to make a silly question: what's the purpose of using this font? Does it shrink ML code?

Just curiosity

Pelican

unread,
Mar 17, 2011, 11:49:52 AM3/17/11
to ml-d...@googlegroups.com
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

unread,
Mar 17, 2011, 11:57:34 AM3/17/11
to ml-d...@googlegroups.com
> Does it shrink ML code?

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

Piers

unread,
Mar 17, 2011, 6:21:26 PM3/17/11
to ml-d...@googlegroups.com


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

unread,
Mar 17, 2011, 6:28:58 PM3/17/11
to ml-d...@googlegroups.com
Piers,

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

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

hello-thin.bmp

Piers

unread,
Mar 17, 2011, 6:44:53 PM3/17/11
to ml-d...@googlegroups.com
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

unread,
Mar 17, 2011, 6:45:55 PM3/17/11
to ml-d...@googlegroups.com
yes, should be >>1 for a 2-bit buffer, you're right ...

Alex

unread,
Mar 17, 2011, 6:47:57 PM3/17/11
to ml-d...@googlegroups.com
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.

unread,
Mar 17, 2011, 6:49:26 PM3/17/11
to ml-d...@googlegroups.com
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

unread,
Mar 19, 2011, 5:53:38 PM3/19/11
to ml-d...@googlegroups.com
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

autoexec.bin

arm.indy

unread,
Mar 20, 2011, 3:32:03 AM3/20/11
to Magic Lantern firmware development
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

unread,
Mar 20, 2011, 6:41:18 PM3/20/11
to ml-d...@googlegroups.com
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
VRAM0.BMP
VRAM1.BMP

Alex

unread,
Mar 21, 2011, 3:52:50 AM3/21/11
to ml-d...@googlegroups.com
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

unread,
Apr 2, 2011, 7:59:20 AM4/2/11
to ml-d...@googlegroups.com
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:


PG
autoexec_TMFontsto550D_PG.bin.zip

Piers

unread,
Apr 2, 2011, 8:02:38 AM4/2/11
to ml-d...@googlegroups.com
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

unread,
Apr 3, 2011, 7:21:26 AM4/3/11
to ml-d...@googlegroups.com
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

VRAM4.BMP

Piers

unread,
Apr 3, 2011, 9:16:15 AM4/3/11
to ml-d...@googlegroups.com
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.



autoexec_PGText2.bin.zip
VRAM5.BMP

Antony Newman

unread,
Apr 3, 2011, 10:33:50 AM4/3/11
to ml-d...@googlegroups.com
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

unread,
Apr 3, 2011, 6:06:04 PM4/3/11
to ml-d...@googlegroups.com
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

unread,
Apr 3, 2011, 6:57:25 PM4/3/11
to ml-d...@googlegroups.com
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

unread,
Apr 3, 2011, 7:55:02 PM4/3/11
to ml-d...@googlegroups.com
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
}
Reply all
Reply to author
Forward
0 new messages