Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support to render OpenType SVG fonts using plutosvg as an alternative to lunasvg (fix #7187) #7927

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

pthom
Copy link
Contributor

@pthom pthom commented Aug 27, 2024

Bonjour Omar,

This is a follow up to these related issues:


SVG Fonts include a set of SVG documents. As per the OpenType specification, some SVG fonts (such as NotoColorEmoji) may group several glyphs in a common svg document (by selecting a subset of the elements in this document).

LunaSvg does support fonts where each glyph is associated to a distinct document. Unfortunately, it is not able to render a subset of a svg document, and will likely not be able to do so in the future.

Its cousin project plutosvg (by the same author):

  • is able to do it
  • provides ready to use freetype hooks
  • is faster according to its author
  • will likely be required by the next version of lunasvg

Example: sammycage/lunasvg#150 shows an example where a single svg document included in the font may contains thousands of glyphs (each glyph is a subset of the svg document).

Pros and Cons

Since this commit may add some complexity in the build process here is a study of the pros and cons:

Pros:

  • plutosvg is faster than lunasvg
  • freetype hooks are provided by plutosvg (no need to provide them in imgui_freetype.cpp)
  • popular font such as NotoColorEmoji are supported

Cons:

  • the compilation setup for plutosvg is a bit more complex than for lunasvg (requires plutovg + plutosvg)
  • no offical release is available yet for plutosvg. No vcpkg package available yet.
  • having two competing compilation flags is not ideal (IMGUI_ENABLE_FREETYPE_LUNASVG vs IMGUI_ENABLE_FREETYPE_PLUTOSVG) (it may be possible to remove IMGUI_ENABLE_FREETYPE_LUNASVG in the future, at the cost of breaking some users build upon upgrade)

Compilation hints for plutovg/plutosvg

Compilation hints for plutovg

  • Compile all source files in plutovg/source/*.c
  • Add include directory: plutovg/include + plutovg/stb

Compilation hints for plutosvg

  • Compile plutosvg/source/plutosvg.c
  • Add include directory: plutosvg/source
  • Add define: PLUTOSVG_HAS_FREETYPE
  • Link with: plutovg, freetype

Demonstration repository

https://github.com/pthom/lunasvg_perf_issue
(a demo repro which can renders all the glyphs of NotoColorEmoji using plutosvg)

…native to lunasvg (fix ocornut#7187)

<SVG Fonts include a set of SVG documents. As per the [OpenType specification](https://learn.microsoft.com/en-us/typography/opentype/spec/svg#glyph-identifiers),
some SVG fonts (such as NotoColorEmoji) may group several glyphs in a common svg document (by selecting a subset of the elements in this document).

LunaSvg does support fonts where each glyph is associated to a distinct document. Unfortunately, it is not able to render
a subset of a svg document, and will likely not be able to do so in the future.

Its cousin project plutosvg (by the same author), is able to do it, and provides ready to use freetype hooks.

Example: sammycage/lunasvg#150 shows an example where a single svg document
included in the font may contains thousands of glyphs (each glyph is a subset of the svg document).

Pros and Cons
-------------
Since this commit adds some complexity in the code here is a study of the pros and cons:

Pros:
- plutosvg is faster than lunasvg
- freetype hooks are provided by plutosvg (no need to provide them in imgui_freetype.cpp)

Cons:
- the compilation setup for plutosvg is a bit more complex than for lunasvg (requires plutovg + plutosvg)
- no offical release is available yet for plutosvg. No vcpkg package available yet.
- having two competing compilation flags is not ideal (IMGUI_ENABLE_FREETYPE_LUNASVG vs IMGUI_ENABLE_FREETYPE_PLUTOSVG)
  (it may be possible to remove IMGUI_ENABLE_FREETYPE_LUNASVG in the future, at the cost of breaking some users build upon upgrade)

Compilation hints for plutovg/plutosvg
--------------------------------------
_Compilation hints for plutovg_
- Compile all source files in `plutovg/source/*.c`
- Add include directory: `plutovg/include` + `plutovg/stb`

_Compilation hints for plutosvg_
- Compile `plutosvg/source/plutosvg.c`
- Add include directory: `plutosvg/source`
- Add define: `PLUTOSVG_HAS_FREETYPE`
- Link with: plutovg, freetype

Demonstration repository
-------------------------
https://github.com/pthom/lunasvg_perf_issue
pthom added a commit to pthom/imgui that referenced this pull request Oct 3, 2024
This is a follow up to these related issues:
- ocornut#7187 (which may need to be reopened, since there is a real rendering issue in ImGui)
- sammycage/lunasvg#150

----
SVG Fonts include a set of SVG documents. As per the [OpenType specification](https://learn.microsoft.com/en-us/typography/opentype/spec/svg#glyph-identifiers), some SVG fonts (such as NotoColorEmoji) may group several glyphs in a common svg document (by selecting a subset of the elements in this document).

LunaSvg did not originally support fonts where each glyph is associated to a distinct document. LunaSvg 3.0.0 now supports this feature

This PR thus adds support for LunaSvg (3.0.0), and its author (@sammycage) was kind enough to provide a patch for ImGui:
sammycage/lunasvg#150 (comment)

Notes
-----
- WARNING: the API of LunaSVG has changed inside the latest version (3.0.0): the current code inside imgui_freetype.cpp
  (without this PR) is not compatible with it!
  A test for this was added in imgui_freetype.cpp:
```cpp
#ifndef LUNASVG_VERSION_MAJOR
#error IMGUI_ENABLE_FREETYPE_LUNASVG requires LunaSvg version >= 3.0
#endif
#if !(LUNASVG_VERSION_MAJOR >= 3)
#error IMGUI_ENABLE_FREETYPE_LUNASVG requires LunaSvg version >= 3.0
#endif
```

- Performance: NotoColorEmoji-Regular is now correctly loaded in approx 1 second (versus > 1 hour with current ImGui)

- Alternative PR, using PlutoSvg instead of LunaSvg:
  There is an alternative PR that would replace LunaSvg by PlutoSvg (ocornut#7927).
  We will likely have to choose between those two.
  The present PR does not propose to replace LunaSvg by PlutoSvg, but to update LunaSvg to the latest version.

- Demonstration repository: https://github.com/pthom/lunasvg_perf_issue / branch "lunasvg_patch_oct24"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants