Is it possible to load a new font from jsx ?

[rik43]

For example, the default font has no Cyrillic support.

api for C: https://docs.lvgl.io/master/overview/font.html

[derekstavis]

Currently this is not supported through the JavaScript binding. You should be able though to go into the LVGL dependency that is vendored in this repo and follow these steps here to get a binary that replaces the builtin font with your custom glyphs.

[derekstavis]

PRs are welcome though. I feel this should be a fairly low lift, but we would need to build a separate Font API to handle this in JavaScript (font loading is not part of React APIs), similar to how Dimensions API work.

[rik43]

follow these steps here

bad link

[derekstavis]

Sorry, here's the right link. Nothing special more than LVGL Font documentation... See the "Add a new font" section.

I tried to take a stab at a way to load fonts from JS, but it seems like LVGL FS is not supported in this binding. @kisvegabor is there a way to load fonts from a buffer instead of using LVGL FS?

[kisvegabor]

is there a way to load fonts from a buffer instead of using LVGL FS?

There is no way for it at this moment. :slightly_frowning_face: Is it critical for the JS binding or rather just a nice to have?

[derekstavis]

Is it critical for the JS binding or rather just a nice to have?

Images are currently handled through a buffer, so I thought it would be nice to have similar handling for fonts, so that bindings that already have FS support could use their own APIs.

In the meantime, I will look into how to integrate with the LVGL FS API as an alternative. The benefit is that it should work for every platform supported by LVGL (for example, I'm aiming to have an ESP32 build target).

[kisvegabor]

We can do 2 things:

1. Add an lv_font_load_from_buffer() function: it would be faster than the file system as lv_fs_read doesn't have to copy anything, just return a pointer.
2. Add a special file system driver that can read from a buffer. It's hacky, slower but generic.

I vote for 1). We could use some function pointers like read_cb which could point lv_fs_read or a buf_read function. This way we don't need to add a bunch of duplication.

What do you think?

[derekstavis]

Option 1 sounds like the cleanest approach to me, as it allows to leverage virtually any loading method -- generating a header file with a a statically allocated buffer, loading from an HTTP source, loading from a native binding, etc -- especially if it doesn't require including and compiling the FS module/drivers

[kisvegabor]

Great, we are on the same page then :slightly_smiling_face:

Are you interested in adding this feature to LVGL? No problem if not, I can open an issue an see if someone picks it up.

[derekstavis]

Sounds like a fun little task to take on :) but right now kind of limited in bandwidth to ramp up in a whole new environment 😛

Feel free to open an issue! If someone picks up, great, otherwise I may pick it up in the future. There's a ton I still need to learn about the platform I'm targeting

[kisvegabor]

Feel free to open an issue! If someone picks up, great, otherwise I may pick it up in the future.

Done :slightly_smiling_face: https://github.com/lvgl/lvgl/issues/4448

[derekstavis]

I got this working locally! Once https://github.com/lvgl/lvgl/pull/4462 lands in LVGL master it should be possible to load fonts using an API similar to the one below:

More sizes and fonts:

Inter	Poppins

Open for feedback on the font loading and registering API:

• The Font constructor takes a JS buffer and creates a new lv_font_t from the buffer that is returned to JS as an instance of Font.
• The Font.load class method takes an URL, either local or remote, loads it asynchronously from the filesystem or network, and returns a new instance of Font.
• The Font.register class method associates a font family and size to a Font instance so that styles can use font-family as a string and font-size as a number.

The caveat of this font loading work is that it will depend on LVGL master branch. This binding master currently points to LVGL v8. I genuinely do not have experience with the stability of LVGL master branch, so in the meantime I can push this into a separate LVGL master-compatible branch.

[kisvegabor]

The caveat of this font loading work is that it will depend on LVGL master branch. This binding master currently points to LVGL v8. I genuinely do not have experience with the stability of LVGL master branch, so in the meantime I can push this into a separate LVGL master-compatible branch.

LVGL master is really not stable yet, so I recommend creating a temporal lvgl-v9-dev branch (or so).

[derekstavis]

The caveat of this font loading work is that it will depend on LVGL master branch. This binding master currently points to LVGL v8. I genuinely do not have experience with the stability of LVGL master branch, so in the meantime I can push this into a separate LVGL master-compatible branch.

LVGL master is really not stable yet, so I recommend creating a temporal lvgl-v9-dev branch (or so).

@kisvegabor is it common for features to be back ported to v8? If so, would it make sense to back port this API?

[kisvegabor]

Normally we rarely backport features to v8 as we are not planning to create new v8 minor releases. However if it's important for the JS binding we can make an exception.