https://www.fontsquirrel.com/tools/webfont-generator
The resulting notosans-regular-webfont.ttf only has 222 glyphs.

Then I converted the font using the EVE Asset Builder.
ASTC block footprints: Auto
Compression Speed: thorough
Addr of Font Data: FLASH

I did this for font-sizes of 12, 14, 16, 18 and 20.

At first I converted all fonts to FLASH address 4096.
Then I put together a flash file, putting .glyph and .xfont files in pairs in it:

notosans-regular-webfont_12_4096.glyph               : 4096   : 119936
notosans-regular-webfont_12_4906.xfont               : 124032 : 5056
notosans-regular-webfont_14_129088.glyph             : 129088 : 120064
notosans-regular-webfont_14_129088.xfont             : 249152 : 5056
notosans-regular-webfont_16_254208.glyph             : 254208 : 269760
notosans-regular-webfont_16_254208.xfont             : 523968 : 5056
notosans-regular-webfont_18_529024.glyph             : 529024 : 270016
notosans-regular-webfont_18_529024.xfont             : 799040 : 5120
notosans-regular-webfont_20_4096.glyph               : 804160 : 180032
notosans-regular-webfont_20_804160.xfont             : 984192 : 5120
chipsie_40x56_40x56_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 989312 : 576

Then I redid the .xfont files by re-compressing the fonts in "veryfast" for the addresses.

I wrote a litte test code, put in the numbers and got five lines of cmd_text() output.
Ah yes, I copied all the .xfont data to graphics memory and I used bitmap-handles 10...14.

Now, the problem was, only the first and the last line were okay, the other three had broken chars.

So I re-compressed the 14/16/18 fonts again in "thorough" for these addresses and replaced all files.

Now the third and the fourth line still have broken chars. And in different places.

So I started to hack this into a spreadsheet.
All the addresses are 64 byte aligned.

Then I tried to read notosans-regular-webfont_16_254208.xfont with a hex-editor.
0x0100aaff - signature
0x00001395 - size of 5013, gen-flash rounds that up to 5056 which is a multiple of 64
0x000093b5 - format
0x0000024a - swizzle
0x00000030 - width
0x00000006 - height
0x00000018 - pixel width
0x0000001e - pixel height
0x00801f08 - start -> 0x1f08 = 254208
0x00010000 - num of glyphs -> 65536 - this is wrong and the one other font (184 glyphs) I checked also had this number
gptr/wptr/widh data - not sure how to really interpret these

Now, what else could I try to put a bunch of fonts into the FLASH?

And on a side-note, the amount of bitmap-handles really is a tad bit low, having annother 32 at least would be nice.

You could either scale down the .jpg in order to fit two into GRAM and scale them up to 800x480.
Or, with the BT815, it should be possible to use ASTC instead.

I have not tried if this works but chapter 6 in the programming guide states:
"With enough ASTC images in flash memory or RAM_G, it is
possible for user to construct an image-rich GUI application."

COMPRESSED_RGBA_ASTC_4x4_KHR has 8 bits per Pixel, the other formats use less bits per pixel.

At least with the EVE Asset Builder it takes quite some time to convert images to ASTC though.

At least https://29a.ch/photo-forensics/ shows a difference then between the original file and the one I saved with IrfanView.

Original structure:
    SOI
    APP0
    DQT
    SOF0 (Baseline DCT)
    DHT
    DRI
    SOS
    EOI

New structure:
    SOI
    APP0
    DQT
    DQT
    SOF0 (Baseline DCT)
    DHT
    DHT
    DHT
    DHT
    SOS
    EOI

So the new file does not only have two DQT entries but also four DHT entries.
Oh yes, and no DRI entry, whatever a "Define Restart Interval" is good for.

I have a board that is populated with a BT816 and a Winbond 25Q128JVSI.
There also is a FT232H on the board I can connect to from the EVE Asset Builder as "MPSSE".

I generated an "output.bin" with only this "unified.blob" and a single small image in ASTC 8x8 format.
But I can not write it to the FLASH, not even after I resorted to use progflash.exe directly.

D:\FLASH>progflash
Welcome to BT81X Flash Programming Utility V0.0.5
Copyright(c) Bridgetek Pte Ltd All Rights Reserved

Usage: ProgFlash [command] [argument]

module       Select Program Module [ FT4222 (default) | MPSSE ]
erase        Erase all of flash
newblob      Install blob <file_name> in flash
write        Write <file_name> to flash (assumes flash is already erased)
update       Write <file_name> to flash, erasing if necessary
read         Read all of flash into <filename>

D:\FLASH>progflash module MPSSE erase
 Information on channel number 0:
 Flags=0x2
 Type=0x8
 ID=0x1b3d0200
 LocId=0x433
 SerialNumber=0k2LWMY6
 Description=USB 2 SPI
 ftHandle=0x0

handle=0x6d4330 status=0x0
VC1 register ID after wake up 7c

 reg_touch_rz =0x7fff
 reg_touch_rzthresh =0xffff
 reg_touch_tag_xy=0x80008000
 reg_touch_tag=0x0

Progress ERASE 1
Erasing Flash...
Progress ERASE 90
Progress ERASE 100
Erase Flash successfully

DONE!

I was about to additionally ask why erasing takes this long but then I just found that the datasheet for this chip
specifies 40...200 seconds for a chip erase.

Now when I try to write this is what happens:

D:\FLASH>progflash module MPSSE write output.bin
[exactly the same lines repeated as above]
Progress BLOB 1
Writing Blob file ".\unified.blob" to BT81X Flash Storage
Progress PROG 0
Write Blob file ".\unified.blob" to BT81X Flash Storage successfully
Progress WRITE 1
Writing Flash file "output.bin" to BT81X Flash Storage (assumes flash is already erased)
Progress PROG 0
Progress PROG 83
Verify Flash failed!
Write Flash file "output.bin" to BT81X Flash Storage unsuccessfully
Exsiting ...

The first thing that is strange is that progflash.exe insists of writing "unified.blob", it is even required to have a file of that name in the same directory as progflash.exe.
However, genflash.exe always adds this mysterious blob to the first 4096 bytes - and I see no way around this, neither from the Eve Asset builder or from using genflash.exe directly.
So it really looks like progflash.exe is shooting itself in the foot there.

Okay, annother erase then, followed by an update command:

D:\FLASH>progflash module MPSSE update output.bin
...
Progress BLOB 1
Writing Blob file ".\unified.blob" to BT81X Flash Storage
Progress PROG 0
Write Blob file ".\unified.blob" to BT81X Flash Storage successfully
Progress UPDATE 1
Writing Flash file "output.bin" to BT81X Flash Storage, erasing if necessary
Progress PROG 0
Verify Flash failed!
Write Flash file "output.bin" to BT81X Flash Storage unsuccessfully
Exsiting ...

Still does not look like it is working.

A "progflash module MPSSE read empty.bin" after an erase results in a 16MB sized file filled with 0xff.
That is fine, although it would be somewhat nicer if it would not save all the empty pages from the end of the data to the end of the flash and even would not save a file at all for an empty flash.
Why? Well, because that would allow copying the content of a flash from one board to annother even when the second board has a smaller flash than the first one, given of course that the first flash is not full but one would be able tell by the size of the file if it will fit or not.
Also writing only the necessary data should be faster.

Okay, "progflash module MPSSE write output.bin" again and it fails again, or at least it says so.
Followed by "progflash module MPSSE read notempty.bin".

Now I compared this "notempty.bin" to "unified.blod" and "output.bin" and it turned out that I wasted a couple of hours to look into a problem that is not even there.
The "notempty.bin" and "output.bin" are exactly the same for the length of "output.bin".

Please update the EVE Asset Builder, it is still on the first release and out for over six months now, thank you.
And please add a "verify" option to progflash.exe in case you do not already have.

Well, I just tried to went for the solution that would be the easiest to implement and has the least impact.

And yes, bit-shifting of 15 bit values into 32 bit is expensive.
Especially on 8 bit controllers which kind are the designated target for EVE.
But it is also more expensive on 32 bit controllers than just copying the values to where they belong.

The goal is to avoid the shifting of bits entirely.

We now have this:

01xxxxxx xxxxxxxx xyyyyyyy yyyyyyyy

This means that the x-coordinate has to be shifted.

Changing the format to this would turn that shifting into a copy operation:

01xxxxxx xxxxxxxx 00yyyyyy yyyyyyyy


This is of couse a non-issue with any static coordinates since the pre-processor should turn that into 32 bit constants already.
This is a bottleneck however when you try to animate things and more than a handfull or coordinates need to be calculated on the fly from variables.