it's possible to include an example with Japanese/Korean/Chinese chars?

[ferrolive]

I was able to use the included fonts in a Raspberry Pi Pico with an OLED display, but I couldn't create any that works with Asian fonts (Japanese/Korean/Chinese). Is there any example that can be included in the documentation?

[peterhinch]

I'm afraid I have no idea how Asian fonts are handled. If they are Unicode there should be no problem - see the docs where the -k arg has been used to create Cyrillic fonts and fonts with Greek glyphs and special symbols. If they are not Unicode then there will be a problem.

I'd be interested in any information you may have.

[lizhaoguosina]

It seems that, for Unicode character, we need to provide a character set file to filter the fonts to be generated.

But for Chinese, it will prompt "OverflowError: int too big to convert". Maybe the character set file is larger than the max length? Is there any solution?

The fonts file I used: Smiley-sans. It contains most of Asian fonts (Japanese/Korean/Chinese).

Thanks for your reply.

[peterhinch]

The only supported font file formats are TTF, OTF, BCF or PCF.

[lizhaoguosina]

Actually, the release zip file contains TTF, OTF and woff2 files.

In last night, I found that the max number of characters is about the char height.
When the height was set 18 pixels, font_to_py.py can deal less than 1767 chars, which means 5113 bytes.
When the height was set 20 pixels, font_to_py.py can deal less than 1643 chars, which means 4739 bytes.

It seems that, the 421st line in font_to_py.py, sparse += (len(data)).to_bytes(2, byteorder='little') # Start throw the error"OverflowError: int too big to convert"

[peterhinch]

I think the problem is the total size of the font data. The index comprises four bytes per entry. The first two bytes are the ordinal value of the glyph. The second two are the offset to the start of the bitmap data for that glyph. If the total size of the glyph data cannot fit into 16 bits this error will occur. Solutions are to reduce the height or to reduce the number of characters in the font.

[peterhinch]

I have pushed an update which produces a clearer error report.

This could be fixed by changing the index to use a bigger field width for the offset, but this would impose a size penalty on all users. In the context of microcontrollers a font size > 65535 total data bytes is very large.

[peterhinch]

@lizhaoguosina I think I have found a fix for this. I have pushed an experimental version in the branch "sparse-24-bit": please could you test this with your character set.

It works by padding each glyph such that the size of the glyph's data % 8 is zero. The index value is now divided by 8, allowing for a total font size of up to 524287 bytes. Rendering of the glyph is unaffected because its reported width and height are unchanged by the padding.

The file size is slightly larger, but padding is only performed for sparse character sets. More typical ASCII type sets are completely unchanged.

This works in my testing, but I don't have access to your font files.

[lizhaoguosina]

Thanks for your update.

It works in my testing. Thanks for your working again.

And I would pull requests an example include Japanese/Chinese chars in next week.

[peterhinch]

Thank you for testing, I will merge this branch.

An example would be good. I'd like to be able to demonstrate these chars on an LCD or OLED display.