From 2bf2ab46ce6bd543ec898785d12a68265d411719 Mon Sep 17 00:00:00 2001 From: Victor Wheeler Date: Fri, 21 Feb 2025 10:49:14 -0700 Subject: [PATCH] docs(libs): proofread docs batch 19 (#7709) Co-authored-by: Liam Howatt <30486941+liamHowatt@users.noreply.github.com> --- docs/details/libs/fs.rst | 70 +++++--------- docs/details/libs/qrcode.rst | 41 +++++--- docs/details/libs/rle.rst | 68 +++++++++----- docs/details/libs/rlottie.rst | 129 ++++++++++++++------------ docs/details/libs/svg.rst | 31 ++++--- docs/details/libs/tiny_ttf.rst | 33 ++++--- docs/details/main-components/font.rst | 2 +- docs/details/main-components/fs.rst | 8 +- 8 files changed, 206 insertions(+), 176 deletions(-) diff --git a/docs/details/libs/fs.rst b/docs/details/libs/fs.rst index 5fa638aba..f9edb2cf8 100644 --- a/docs/details/libs/fs.rst +++ b/docs/details/libs/fs.rst @@ -4,10 +4,8 @@ File System Interfaces ====================== -LVGL has a :ref:`overview_file_system` module -to provide an abstraction layer for various file system drivers. - -LVG has built in support for: +LVGL's :ref:`file_system` module provides an abstraction that enables you to attach +any type of file system for LVGL's use. File systems already supported are: - `FATFS `__ - STDIO (Linux and Windows using C standard function .e.g ``fopen``, ``fread``) @@ -19,59 +17,33 @@ LVG has built in support for: - Arduino SD (allows for reading from and writing to SD cards) You still need to provide the drivers and libraries, this extension -provides only the bridge between FATFS, STDIO, POSIX, WIN32 and LVGL. +provides only the bridge between LVGL and these file systems. + + .. _libs_filesystem_usage: Usage ***** -In ``lv_conf.h`` enable ``LV_USE_FS_...`` and assign an upper cased -letter to ``LV_FS_..._LETTER`` (e.g. ``'S'``). After that you can access -files using that driver letter. E.g. ``"S:path/to/file.txt"``. +In ``lv_conf.h`` enable ``LV_USE_FS_...`` (by setting its value to ``1``) and assign +an upper cased letter to ``LV_FS_..._DRIVER_LETTER`` (e.g. ``'S'``). If more than +one file system is enabled, each driver will need to have a unique driver-identifier +letter. After that you can access files using that driver letter. Example with +driver identifier letter ``'S'``: -Working with common prefixes -"""""""""""""""""""""""""""" +:Linux-like relative path: ``"S:path/to/file.txt"`` +:Linux-like absolute path: ``"S:/path/to/file.txt"`` +:Windows-like relative path: ``"S:C:path/to/file.txt"`` +:Windows-like absolute path: ``"S:C:/path/to/file.txt"`` -A **default driver letter** can be set by ``LV_FS_DEFAULT_DRIVER_LETTER``, -which allows skipping the drive prefix in file paths. +Do not confuse the driver-identifier letter with the Windows/DOS/FAT "drive letter", +which is part of the path passed to the OS-level functions. For more details, see +:ref:`lv_fs_identifier_letters`. -For example if ``LV_FS_DEFAULT_DRIVER_LETTER`` is set the ``'S'`` *"path/to/file.txt"* will mean *"S:path/to/file.txt"*. +:ref:`Cached reading ` is also supported if ``LV_FS_..._CACHE_SIZE`` is set to +a non-zero value. -This feature is useful if you have only a single driver and don't want to bother with LVGL's driver layer in the file paths. -It also helps to use a unified path with LVGL's file system and normal file systems. -The original mechanism is not affected, so a path starting with drive letter will still work. - -The **working directory** can be set with ``LV_FS_..._PATH``. E.g. -``"/home/joe/projects/"`` The actual file/directory paths will be -appended to it, allowing to skip the common part. - -Caching -""""""" - -:ref:`Cached reading ` is also supported if ``LV_FS_..._CACHE_SIZE`` is set to -not ``0`` value. :cpp:func:`lv_fs_read` caches this size of data to lower the -number of actual reads from the storage. - -To use the memory-mapped file emulation an ``lv_fs_path_ex_t`` object must be -created and initialized. This object can be passed to :cpp:func:`lv_fs_open` as -the file name: - -.. code-block:: c - - lv_fs_path_ex_t mempath; - lv_fs_file_t file; - uint8_t *buffer; - uint32_t size; - - /* Initialize buffer */ - ... - - lv_fs_make_path_from_buffer(&mempath, LV_FS_MEMFS_LETTER, (void*)buffer, size); - lv_fs_res_t res = lv_fs_open(&file, (const char *)&mempath, LV_FS_MODE_RD); - -.. _libs_filesystem_api: - -API -*** +For further details, including how to create support for your own file system, see +:ref:`file_system`. diff --git a/docs/details/libs/qrcode.rst b/docs/details/libs/qrcode.rst index 263f26ccf..13a46a3d8 100644 --- a/docs/details/libs/qrcode.rst +++ b/docs/details/libs/qrcode.rst @@ -1,45 +1,56 @@ .. _qrcode: ======= -QR code +QR Code ======= -QR code generation with LVGL. Uses -`QR-Code-generator `__ by -`nayuki `__. +The `QR-Code-generator library `__ by +`nayuki `__ is a 3rd-party library that generates QR-Code +bitmaps. + +The lv_qrcode LVGL extension is an interface to that library which implements a custom +Widget that generates and displays QR Codes using the library. + + .. _qrcode_usage: Usage ------ +***** -Enable :c:macro:`LV_USE_QRCODE` in ``lv_conf.h``. +Enable :c:macro:`LV_USE_QRCODE` in ``lv_conf.h`` by setting its value to ``1``. -Use :cpp:func:`lv_qrcode_create` to create a qrcode object, and use -:cpp:func:`lv_qrcode_update` to generate a QR code. +Use :cpp:func:`lv_qrcode_create` to create the QR-Code Widget. Then use +:cpp:func:`lv_qrcode_update` to generate the QR Code on it. If you need to re-modify the size and color, use :cpp:func:`lv_qrcode_set_size` and :cpp:func:`lv_qrcode_set_dark_color` or -:cpp:func:`lv_qrcode_set_light_color`, and -call :cpp:func:`lv_qrcode_update` again to regenerate the QR code. +:cpp:func:`lv_qrcode_set_light_color` respectively, and then +call :cpp:func:`lv_qrcode_update` again to update the QR Code. + + Notes ------ +***** + +- QR Codes with less data are smaller, but they are scaled by an integer + value to best fit to the given size. + -- QR codes with less data are smaller, but they scaled by an integer - number to best fit to the given size. .. _qrcode_example: Example -------- +******* .. include:: ../../examples/libs/qrcode/index.rst + + .. _qrcode_api: API ---- +*** :ref:`qrcodegen_h` diff --git a/docs/details/libs/rle.rst b/docs/details/libs/rle.rst index fb2cdb553..a13060890 100644 --- a/docs/details/libs/rle.rst +++ b/docs/details/libs/rle.rst @@ -1,23 +1,26 @@ .. _rle: -============ -RLE Compress -============ +================= +RLE Decompression +================= -LVGL provides a custom RLE compression method. It can be used to reduce binary -image size. The RLE compression is a lossless compression method. +LVGL provides a custom RLE (Run-Length Encoding) decompression method. It can be +used to reduce binary image size. The RLE compression is a lossless compression +method. -The LVGL's built-in binary image decoder supports RLE compressed images. +The LVGL's built-in binary image decoder supports RLE-compressed images. The decoder supports both variable and file as image sources. The original -binary data is directly decoded to RAM +binary data is directly decoded to RAM. + + Benefits --------- +******** -Based on test result from a watch project. Most of the images can be compressed -to save more than 70% space as show in below statistic. It shows the file count -of every compress level. For rare conditions, RLE compress may increase the file -size if there's no large repetition in data. +Most screenshot and UI images (where there are a limited number of colors) can be +compressed to save more than 70% space. The below statistics are from a watch +project. It shows the file count of every compress level. For rare conditions, RLE +compress may increase the file size if there's no large repetition in data. .. image:: rle-compress-statistics.png :alt: RLE compress statistics from a watch project @@ -25,14 +28,14 @@ size if there's no large repetition in data. Theory ------- +****** The RLE algorithm is a simple compression algorithm that is based on the fact that -the for many pixels, the color is the same. The algorithm simply counts how many -repeated data are there and store the count value and the color value. -If the coming pixels are not repeated, it stores the non-repeat count value and -original color value. For more details, the script used to compress the image -can be found from ``lvgl/script/LVGLImage.py``. +for many adjacent pixels, the color is the same. The algorithm simply counts how +many repeated pixels with the same color there are, and stores the count value and +the color value. If the up-coming pixels are not repeated, it stores the non-repeat +count value and original color values. For more details, the script used to compress +the image can be found from ``lvgl/script/LVGLImage.py``. .. code-block:: python @@ -63,24 +66,39 @@ can be found from ``lvgl/script/LVGLImage.py``. return b"".join(compressed_data) + + .. _rle_usage: Usage ------ +***** -To use the RLE Decoder, enable it in ``lv_conf.h`` configuration file by setting :c:macro:`LV_USE_RLE` to `1`. -The RLE image can be used same as other images. +To use the RLE Decoder, enable it in ``lv_conf.h`` configuration file by setting +:c:macro:`LV_USE_RLE` to ``1``. The RLE image can then be used in the same way as +other images. .. code-block:: c lv_image_set_src(img, "path/to/image.rle"); -Generate RLE compressed binary images -------------------------------------- -The image can be directly generated using script ``lvgl/script/LVGLImage.py`` +Generating RLE Compressed Binary Images +*************************************** + +An RLE image binary can be directly generated from another image using script +``lvgl/script/LVGLImage.py``. .. code-block:: bash - ./script/LVGLImage.py --ofmt BIN --cf I8 --compress RLE cogwheel.png + ./scripts/LVGLImage.py --ofmt BIN --cf I8 --compress RLE cogwheel.png + +This will decompress ``cogwheel.png``, and then re-compress it using RLE and write +the output to ``./output/cogwheel.bin``. + + + +API +*** + +:ref:`lv_rle_h` diff --git a/docs/details/libs/rlottie.rst b/docs/details/libs/rlottie.rst index d0067b195..85e645c15 100644 --- a/docs/details/libs/rlottie.rst +++ b/docs/details/libs/rlottie.rst @@ -1,25 +1,27 @@ .. _rlottie: ============== -Rlottie player +Rlottie Player ============== .. warning:: - Rlottie is deprecated. Consider using :ref:`lv_lottie` instead. + Rlottie is deprecated. Consider using the :ref:`lv_lottie` Widget instead. -Allows playing Lottie animations in LVGL. Taken from `lv_rlottie `__. +The `Rlottie animation player for LVGL `__ +is a 3rd-party extension for LVGL that allows playing Lottie animations in LVGL. +It provides an interface to `Samsung/rlottie `__ +library's C API. This Lottie player is not part of LVGL; it needs to be built +separately. -LVGL provides the interface to `Samsung/rlottie `__ library's C -API. That is the actual Lottie player is not part of LVGL, it needs to -be built separately. -Build Rlottie -------------- -To build Samsung's Rlottie C++14 compatible compiler and optionally -CMake 3.14 or higher is required. +Building Rlottie +**************** -To build on desktop you can follow the instructions from Rlottie's +To build Samsung's Rlottie, you will need a C++14-compatible compiler and optionally +CMake 3.14 or higher. + +To build on a desktop you can follow the instructions from Rlottie's `README `__. In the most basic case it looks like this: @@ -40,24 +42,26 @@ And finally add the ``-lrlottie`` flag to your linker. On embedded systems you need to take care of integrating Rlottie to the given build system. -ESP-IDF example at bottom -~~~~~~~~~~~~~~~~~~~~~~~~~ +See the ESP-IDF example below. + + .. _rlottie_usage: Usage ------ +***** You can use animation from files or raw data (text). In either case -first you need to enable :c:macro:`LV_USE_RLOTTIE` in ``lv_conf.h``. +first you need to enable :c:macro:`LV_USE_RLOTTIE` in ``lv_conf.h`` by setting its +value to ``1``. -The ``width`` and ``height`` of the Widget be set in the *create* -function and the animation will be scaled accordingly. +The ``width`` and ``height`` of the Widget is set in the ``lv_rlottie_create_from_...()`` +function, and the animation will be scaled accordingly. -Use Rlottie from file -~~~~~~~~~~~~~~~~~~~~~ +Use Rlottie from File +--------------------- -To create a Lottie animation from file use: +To create a Lottie animation from a file use: .. code-block:: c @@ -66,11 +70,11 @@ To create a Lottie animation from file use: Note that, Rlottie uses the standard STDIO C file API, so you can use the path "normally" and no LVGL specific driver letter is required. -Use Rlottie from raw string data -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Use Rlottie from Raw String Data +-------------------------------- ``lv_example_rlottie_approve.c`` contains an example animation in raw -format. Instead storing the JSON string, a hex array is stored for the +format. Instead of storing the JSON string, a hex array is stored for the following reasons: - avoid escaping ``"`` character in the JSON file @@ -83,7 +87,8 @@ array. E.g.: ./filetohex.py path/to/lottie.json --filter-character --null-terminate > out.txt -``--filter-character`` filters out non-ASCII characters and ``--null-terminate`` makes sure that a trailing zero is appended to properly close the string. +``--filter-character`` filters out non-ASCII characters and ``--null-terminate`` +makes sure that a trailing zero is appended to properly terminate the string. To create an animation from raw data: @@ -92,17 +97,21 @@ To create an animation from raw data: extern const uint8_t lottie_data[]; lv_obj_t* lottie = lv_rlottie_create_from_raw(parent, width, height, (const char *)lottie_data); -Getting animations ------------------- + + +Getting Animations +****************** Lottie is standard and popular format so you can find many animation -files on the web. For example: https://lottiefiles.com/ +files on the web. For example: https://lottiefiles.com/ . You can also create your own animations with Adobe After Effects or similar software. -Controlling animations ----------------------- + + +Controlling Animations +********************** LVGL provides two functions to control the animation mode: :cpp:func:`lv_rlottie_set_play_mode` and :cpp:func:`lv_rlottie_set_current_frame`. @@ -132,11 +141,13 @@ To get the number of frames in an animation or the current frame index, you can cast the :c:struct:`lv_obj_t` instance to a :c:struct:`lv_rlottie_t` instance and inspect the ``current_frame`` and ``total_frames`` members. + + ESP-IDF Example ---------------- +*************** Background -~~~~~~~~~~ +---------- Rlottie can be expensive to render on embedded hardware. Lottie animations tend to use a large amount of CPU time and can use large @@ -155,13 +166,13 @@ lottie animation. In order to pass initialization of the lv_rlottie_t object, you need 240x320x32/8 (307k) available memory. The latest ESP32-S3 has 256kb RAM -available for this (before freeRtos and any other initialization starts +available for this (before FreeRTOS and any other initialization starts taking chunks out). So while you can probably start to render a 50x50 animation without SPIRAM, PSRAM is highly recommended. Additionally, while you might be able to pass initialization of the -lv_rlottie_t object, as rlottie renders frame to frame, this consumes -additional memory. A 30 frame animation that plays over 1 second +``lv_rlottie_t`` object, as rlottie renders frame to frame, this consumes +additional memory. A 30-frame animation that plays over 1 second probably has minimal issues, but a 300 frame animation playing over 10 seconds could very easily crash due to lack of memory as rlottie renders, depending on the complexity of the animation. @@ -169,7 +180,7 @@ renders, depending on the complexity of the animation. Rlottie will not compile for the IDF using the ``-02`` compiler option at this time. -For stability in lottie animations, I found that they run best in the +For stability in lottie animations, this author has found that they run best in the IDF when enabling :c:macro:`LV_MEM_CUSTOM` (using ``stdlib.h``) For all its faults, when running right-sized animations, they provide a @@ -179,15 +190,15 @@ done properly. When picking/designing a lottie animation consider the following limitations: -- Build the lottie animation to be sized for the intended size -- it can scale/resize, but performance will be best when the base lottie size is as intended +- Build the lottie animation to be sized for the intended size. +- It can scale/resize, but performance will be best when the base lottie size is as intended. - Limit total number of frames, the longer the lottie animation is, - the more memory it will consume for rendering (rlottie consumes IRAM for rendering) -- Build the lottie animation for the intended frame rate -- default lottie is 60fps, embedded LCDs likely won't go above 30fps + the more memory it will consume for rendering (rlottie consumes IRAM for rendering). +- Build the lottie animation for the intended frame rate. +- Default lottie is 60fps, embedded LCDs likely won't go above 30fps. IDF Setup -~~~~~~~~~ +--------- Where the LVGL simulator uses the installed rlottie lib, the IDF works best when using rlottie as a submodule under the components directory. @@ -203,19 +214,19 @@ Now, Rlottie is available as a component in the IDF, but it requires some additional changes and a CMakeLists file to tell the IDF how to compile. -Rlottie patch file -~~~~~~~~~~~~~~~~~~ +Rlottie Patch File +------------------ -Rlottie relies on a dynamic linking for an image loader lib. This needs +Rlottie relies on dynamic linking for an image loader lib. This needs to be disabled as the IDF doesn't play nice with dynamic linking. -A patch file is available in lvgl under: +A patch file is available in LVGL under: ``/env_support/esp/rlottie/0001-changes-to-compile-with-esp-idf.patch`` Apply the patch file to your rlottie submodule. CMakeLists for IDF -~~~~~~~~~~~~~~~~~~ +------------------ An example CMakeLists file has been provided at ``/env_support/esp/rlottie/CMakeLists.txt`` @@ -235,13 +246,13 @@ project as any other widget in LVGL ESP examples. Please remember that these animations can be highly resource constrained and this does not guarantee that every animation will work. -Additional Rlottie considerations in ESP-IDF -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Additional Rlottie Considerations in ESP-IDF +-------------------------------------------- While unnecessary, removing the ``rlottie/rlottie/example`` folder can remove -many un-needed files for this embedded LVGL application +many un-needed files for this embedded LVGL application. -From here, you can use the relevant LVGL lv_rlottie functions to create +From here, you can use the relevant LVGL ``lv_rlottie...()`` functions to create lottie animations in LVGL on embedded hardware! Please note, that while lottie animations are capable of running on many @@ -261,33 +272,37 @@ lottie animations. You will need to enable :c:macro:`LV_USE_RLOTTIE` through **idf.py** menuconfig under LVGL component settings. -Additional changes to make use of SPIRAM -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Additional Changes to Make Use of SPIRAM +---------------------------------------- -:cpp:expr:`lv_alloc/realloc` do not make use of SPIRAM. Given the high memory usage +:cpp:expr:`lv_alloc/realloc` does not make use of SPIRAM. Given the high memory usage of lottie animations, it is recommended to shift as much out of internal DRAM into SPIRAM as possible. In order to do so, SPIRAM will need to be enabled in the menuconfig options for your given espressif chip. There may be a better solution for this, but for the moment the -recommendation is to make local modifications to the lvgl component in +recommendation is to make local modifications to the LVGL component in your espressif project. This is as simple as swapping :cpp:expr:`lv_alloc/lv_realloc` calls in `lv_rlottie.c`` with :cpp:expr:`heap_caps_malloc` (for -IDF) with the appropriate :cpp:expr:`MALLOC_CAP` call - for SPIRAM usage this is +IDF) with the appropriate :cpp:expr:`MALLOC_CAP` call --- for SPIRAM usage this is :cpp:expr:`MALLOC_CAP_SPIRAM`. .. code-block:: c rlottie->allocated_buf = heap_caps_malloc(allocated_buf_size+1, MALLOC_CAP_SPIRAM); + + .. _rlottie_example: Example -------- +******* .. include:: ../../examples/libs/rlottie/index.rst + + .. _rlottie_api: API ---- +*** diff --git a/docs/details/libs/svg.rst b/docs/details/libs/svg.rst index 5a9aa13e0..c948e9421 100644 --- a/docs/details/libs/svg.rst +++ b/docs/details/libs/svg.rst @@ -1,22 +1,27 @@ .. _svg: -============== -SVG support -============== +=========== +SVG Support +=========== + +The lv_svg extension provides makes it possible to use SVG images in your LVGL UI using the +`Scalable Vector Graphics (SVG) Tiny 1.2 Specification `__. + +For a detailed introduction, see: https://www.w3.org/TR/SVGTiny12/ -Scalable Vector Graphics (SVG) Tiny 1.2 support in LVGL. -Detailed introduction: https://www.w3.org/TR/SVGTiny12/ Usage ***** -Enable :c:macro:`LV_USE_SVG` in ``lv_conf.h``. +Enable :c:macro:`LV_USE_SVG` in ``lv_conf.h`` by setting its value to ``1``. See the examples below. -If you need support SVG animation attribute parsing, -you can enable :c:macro:`LV_USE_SVG_ANIMATION` in ``lv_conf.h``. +If you need support for SVG animation attribute parsing, +you can set :c:macro:`LV_USE_SVG_ANIMATION` in ``lv_conf.h`` to ``1``. + + .. _svg_example: @@ -28,23 +33,25 @@ Example lv_svg_node_t * svg_doc; const char* svg_data = ""; - /* Create an SVG DOM tree*/ + /* Create an SVG DOM tree */ svg_doc = lv_svg_load_data(svg_data, svg_len); ... - /* Draw SVG image*/ + /* Draw SVG image */ lv_draw_svg(layer, svg_doc); ... - /* Release the DOM tree*/ + /* Release the DOM tree */ lv_svg_node_delete(svg_doc); -`lv_image` also supports svg image, For example: +`lv_image` also supports SVG images, For example: .. code-block:: c lv_image_set_src(widget, "S:path/to/example.svg"); + + .. _svg_api: API diff --git a/docs/details/libs/tiny_ttf.rst b/docs/details/libs/tiny_ttf.rst index 25964bbd9..cc9e2f9fb 100644 --- a/docs/details/libs/tiny_ttf.rst +++ b/docs/details/libs/tiny_ttf.rst @@ -4,24 +4,27 @@ Tiny TTF font engine ==================== +The lv_tiny_ttf extension allows using TrueType fonts in LVGL using the +`stb_truetype 3rd-Party Library `__. + +For a detailed introduction, see: https://github.com/nothings/stb. + + + .. _tiny_ttf_usage: Usage ------ +***** -Allow using TrueType fonts in LVGL. - -Detailed introduction: https://github.com/nothings/stb - -When enabled in ``lv_conf.h`` with :c:macro:`LV_USE_TINY_TTF` +When enabled in ``lv_conf.h`` by setting :c:macro:`LV_USE_TINY_TTF` to ``1``, :cpp:expr:`lv_tiny_ttf_create_data(data, data_size, font_size)` can be used to -create a TTF font instance at the specified line height. You can then +create a TTF font instance with the specified line height. You can then use that font anywhere :c:struct:`lv_font_t` is accepted. By default, the TTF or OTF file must be embedded as an array, either in a header, or loaded into RAM in order to function. -However, if :c:macro:`LV_TINY_TTF_FILE_SUPPORT` is enabled, +However, if :c:macro:`LV_TINY_TTF_FILE_SUPPORT` is enabled (i.e. ``1``), :cpp:expr:`lv_tiny_ttf_create_file(path, font_size)` will also be available, allowing tiny_ttf to stream from a file. The file must remain open the entire time the font is being used. @@ -29,27 +32,31 @@ entire time the font is being used. After a font is created, you can change the font size in pixels by using :cpp:expr:`lv_tiny_ttf_set_size(font, font_size)`. -By default, a font will cache data for upto 256 glyphs elements to speed up rendering. +By default, a font will cache data for up to 256 glyph elements to speed up rendering. This maximum can be changed by using :cpp:expr:`lv_tiny_ttf_create_data_ex(data, data_size, font_size, kerning, cache_size)` or :cpp:expr:`lv_tiny_ttf_create_file_ex(path, font_size, kerning, cache_size)` (when -available). The cache size is indicated in number of entries. Kerning is whether to allow -if supported, or disable. +available). The cache size is indicated in number of entries. The ``kerning`` +argument will be one of the ``LV_FONT_KERNING_...`` values, indicating whether to +allow kerning, if supported, or disable. .. _tiny_ttf_example: Example -------- +******* .. include:: ../../examples/libs/tiny_ttf/index.rst + + .. _tiny_ttf_api: API ---- +*** :ref:`stb_rect_pack_h` :ref:`stb_truetype_htcw_h` + diff --git a/docs/details/main-components/font.rst b/docs/details/main-components/font.rst index 17758d520..cb600c6a4 100644 --- a/docs/details/main-components/font.rst +++ b/docs/details/main-components/font.rst @@ -367,7 +367,7 @@ Loading a Font from a Memory Buffer at Run-Time This function may be useful to load a font from an external file system, which is not supported by LVGL. The font needs to be in the same format as if it were loaded from a file. -:note: To load a font from a buffer :ref:`LVGL's filesystem ` +:note: To load a font from a buffer :ref:`LVGL's filesystem ` needs to be enabled and the MEMFS driver must be added. Example diff --git a/docs/details/main-components/fs.rst b/docs/details/main-components/fs.rst index a6a19c71a..f87a29f82 100644 --- a/docs/details/main-components/fs.rst +++ b/docs/details/main-components/fs.rst @@ -17,7 +17,7 @@ under :ref:`lv_fs_identifier_letters`. -Ready-to-use drivers +Ready-to-Use Drivers ******************** LVGL contains prepared drivers for the API of POSIX, standard C, @@ -29,7 +29,7 @@ Learn more :ref:`here `. .. _lv_fs_identifier_letters: Identifier Letters -********************* +****************** As mentioned above, a file system is identified by an assigned identifier letter. This identifier is merely a way for the LVGL File System abtraction logic to look up @@ -295,7 +295,7 @@ To use files in Image Widgets the following callbacks are required: -.. _overview_file_system_cache: +.. _file_system_cache: Optional File Buffering/Caching ******************************* @@ -386,7 +386,7 @@ The driver's ``tell`` will not actually be called. -.. _overview_file_system_api: +.. _file_system_api: API ***