Hi!

To my understanding gint has its own font system and text rendering, completely bypassing OS counterparts, with font data (the majority of which are raw glyphs) ending up in the add-in binary. My problem is cannot afford the binary size taken by glyphs, if I need to support Unicode characters other than ASCII alone, such as CJK, which comprises a huge amount of characters.

My first reaction is to use OS built-in glyphs, especially of 24px and 18px fonts, since they support most "multi-byte" characters, according to wiki. The question now is how?

Some of possible means could be:

- Call syscalls (GetMiniGlyphPtr(), PrintGlyph(), etc) to draw to VRAM. How well will gint get along with those syscalls?
- Call GetMiniGlyphPtr() then do pixel rendering. Still need a syscall. Need to know encodings of multi-byte character (looks like already knonw) and glyphs (should not be difficult if not known yet)

Moreover, if it's not possible or does not worth the effect, we can put the font file to flash. This seems feasible.

Or are there any other ways? If some of you have encountered this problem, what's your solution? Please advise! Also @Lephe, any thoughts?

First note that multi-byte characters do not cover anywhere close to the full Unicode range. You can find the original fx-9860G character set in this document. My belief is Chinese CASIO calculators are entirely separate models. I don't even think my Graph 90+E (fx-CG 50) supports Japanese syllabaries.

Edit: The wiki suggests I'm wrong on this and Chinese is supported, so it might actually be fine.

Apart from that, your understanding is correct. gint's VRAM is separate due to the different size, so you can't draw with the OS syscalls. However, you can indeed call GetMiniGlyphPtr() or other similar font-access syscalls and then do the rendering per-pixel in the straightforward way, and you don't need a world switch for that.

However, I can't say I really understand the file size problem. The default ASCII font only takes 1208 bytes, and while the extended version would probably ~6 times more currently, you'll be very far from the 2 MB add-in limit. If you can't afford that, then I'm inclined to suggest that whatever is taking the rest of the 2 MB is likely a more important target

(Also the default OS font looks quite bad. )

My US version fx-cg50 supports English and Chinese and other 4 or 5 languages I am sure. No idea about Chinese version of this model though.

My theory is multi-byte charset probably covers the most common characters. Better than nothing;)



Good news! I will probably take this route then.



I cannot provide exact numbers but the Chinese national standard contains lets say 2000 most common characters and 3000 secondly most common used, and a few hundreds rare characters, in addition to Traditional Chinese characters (those used in HK & TW mostly). Those are huge numbers compared to 128 of ASCII.



Hmmmm.. Every drop counts. And I believe anything rare should be treasured and I wont waste it unless I am pretty sure I am not.



Cannot argue. Again, better than nothing!

Wait! Are you suggesting gint allocates separate VRAMs from usable RAM or heap? I rember somewhere in API comments mensioned that two VRAMs are used for cg50

Ok so your add-in normally has 512 kB of data segment + stack, and 128 kB of heap.

Add-ins rarely have 512 kB data segments, so gint automatically creates an additional heap in the unused part of the 512 kB. In addition, gint allocates a separate VRAM but in the system stack, so you don't lose any memory.

(Current gint allocates two VRAMs because of a long-standing triple buffering optimization. This will likely no longer be the default in an upcoming version. Instead we could allocate another 170 kB heap in its place, and if you run out of memory there's also the OS' save VRAM buffer which is another 160 kB.)

Phew..

As a reference, for anyone interested in Chinese fonts, there is an open source bitmap font:

https://github.com/aguegu/BitmapFont

- The 9pt "Lite" version (contains ~4000 characters), has a file size of 1.1MB
- The 16pt Lite version, ~1.3MB
- The 9pt Complete version (~7.5k characters), file size 2MB
- The 16pt Complete version, ~2.5 MB

That's pretty much what we have to learn in school. Sad:( Can English speakers imagine what if you have a 4000 letters alphabet

Yeah, it's different.

But if you think about it in terms of words:
Most Chinese dictionaries have ~400 000 words.
English ones have closer to 500 000 words.

Just being curious, is there a list? I did quick search and found list of about 58K words, however it includes both singular and plural form for nouns. This way e.g. Czech would get every noun as 14 items.
The list: http://www.mieliestronk.com/corncob_lowercase.txt

Well, a dictionary would be a list of words.
Wikipedia says that there are 578 thousand words in Wikitionary, https://en.wikipedia.org/wiki/List_of_dictionaries_by_number_of_words, but most other dictionaries I found were a bit lower.

From what's in my hands,

- Longman dictionary of contemporary english 5th edition, ~230k words and phrases
- Modern Chinese Dictionary 6th, ~13k characters and 69k words

Both are very heavy books! They are of about 3000 and 1800 pages respectively.

In terms of words or pages roughly there is a difference of 2-3 times between the two.

But can you give me a link to the list of the words, please?

There is a git project claiming to have 466K English words: https://github.com/dwyl/english-words
But there are words like:
10-point
11-point
12-point
16-point
18-point
This way every language has infinite count of words

This is getting very off topic, but as I said wikitionary has about 578k words, if you want a list you will have to write a bot to generate it for you.
Languages are always adapting, so there is no definitive answer to how many words there are.

I have something for you that might be interesting. The Casio Prizm can handle Freetype2. With Freetype2 you can use any font that you want and it will look great!

Here is an old example that I dug up:
https://github.com/ComputerNerd/casio-prizm-freetype2-example

Most of it is still good except I think the DPI math I did was a little off. Most notably the DPI for the width and height should likely be the same. I think it would make sense to use 136 for both the width and height.

That's really cool - it wouldn't solve si's space usage problem, but really interesting nonetheless. Do you remember how fast (or, probably, how slow) it was? Did it support antialiasing?

I'm also thinking it could be nice to pre-render vector fonts with partial transparency at fixed sizes. That could be decently compact and also decently fast (190 kB of font data does hurt for ~870 glyphs, and I don't know how large the code is). More options to investigate...

ProgrammerNerd: Thank you for sharing about FREETYPE2. This font engine could be useful when standard fonts support is desireable.

BTW, I am also interested in the implementation of `FT_Outline_Render()` and what's behind the `<fxcg/terminal.h>` header file.

Lephe,

I don't remember exactly how fast it was but I think the performance is likely very good. For sure it draws the text faster than anything I could measure with a stop watch. In other words significantly less than one second.

Freetype2 supports anti-aliasing. In fact I'm certain that sometime in your life you've seen text rendered with the Freetype2 library. Freetype2 is used on Linux, iOS, Android. Also Chrome and Firefox use it.

si,

You can ignore fxcg/terminal.h and also FXCGinitTerminal. Both of those were part of a fork I made to libfxcg https://github.com/ComputerNerd/libfxcg-copyleft

Remove those lines and hopefully it can work with the regular libfxcg.

FT_Outline_Render is documented here: https://freetype.org/freetype2/docs/reference/ft2-outline_processing.html basically once that function is called Freetype2 will call graySpans a bunch of times. Note that within graySpans there is a mistake, I should not have hard-coded the VRAM address.

I see! I would have to time it in more detail then, as I would like to experiment with antialiased fonts in games, where the budget for text rendering in each frame is more like 5 ms.

Also you're right, I think every bit of text I read on my screen is rendered by FreeType! I wasn't sure whether the advanced stuff it would be enabled on the calc, I really like that it works. I'm always impressed by how much stuff the Cemetech community manages to port.