Update the vendored FreeType version to 2.13.3 by iscgar · Pull Request #1543 · solvespace/solvespace

iscgar · 2025-03-06T21:13:41Z

The existing version (2.7.1) is using an ancient zlib version, which fails to build with modern Xcode tools on macOS.

The existing version (2.7.1) is using an ancient zlib version, which fails to build with modern Xcode tools on macOS. Fixes solvespace#1539

iscgar · 2025-03-06T21:44:13Z

Had to force push because I didn't have a way to test this before pushing, and apparently the name of the configuration variables to disable dependencies changed between the versions (and Brotli was added as well). What's weird though, is that we were already using WITH_ZLIB=OFF with the older version, but for some reason FreeType code was including its vendored header file of zlib regardless.

Because we build our vendored zlib and libpng anyway, there's no point in disabling their build, so I didn't include them in the list of dependencies to disable. Since they're included and found earlier, CMake picks our versions and statically links them.

.gitmodules

ruevs · 2025-03-07T08:38:22Z

CMakeLists.txt

-            WITH_HarfBuzz           OFF
+            FT_DISABLE_BZIP2        ON
+            FT_DISABLE_HARFBUZZ     ON
+            FT_DISABLE_BROTLI       ON


Suggested change

FT_DISABLE_BROTLI ON

FT_DISABLE_BROTLI ON

FT_DISABLE_PNG ON

FT_DISABLE_ZLIB ON

We should disable PNG - as it was before.
And I do not see why not to FT_DISABLE_ZLIB=ON - it disables the system ZLIB and uses the internal one anyway.

I'm fine with disabling libpng (which disables support of PNG compressed OpenType embedded bitmaps), although we build it anyway as a direct dependency of SolveSpace, so I'm not sure why we would want to prevent FreeType from using it.

As for zlib, "system" is a bit confusing here. When disabling zlib it does not use the zlib that we build as a direct dependency of SolveSpace, but rather the copy of zlib vendored in FreeType, so we just end up with two copies of zlib in the binary, each from a different version. Without disabling it, CMake ends up using the SolveSpace zlib that we introduce into the build before adding FreeType, so we have only a single version of zlib in the binary.

so I'm not sure why we would want to prevent FreeType from using it.

I'm not sure what "PNG compressed OpenType embedded bitmaps." are but I presume that since they are bitmaps they would be useless for the text feature of SolveSpace, which uses only the curves from the fonts.

However enabling the option causes the EXE (Windows 32 bit build with MSVC 2019 with LTO) size to decrease for me:

FT_DISABLE_PNG ON:
5.93 MB (6,218,752 bytes)

FT_DISABLE_PNG OFF:
5.92 MB (6,208,512 bytes)

WTF?!

The FT_DISABLE_ZLIB option does not influence the EXE size. So let us leave them as you configured them.

Weird. On Linux I see the reverse (when forcing building with vendored zlib, libpng, and freetype, and with cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_LTO=1 -DENABLE_SANITIZERS=0):

$ ls -ln --time-style=+"" bin/solvespace -rwxr-xr-x 1 1000 1000 52871080 bin/solvespace $ ls -ln --time-style=+"" ../solvespace-png -rwxr-xr-x 1 1000 1000 52884800 ../solvespace-png

I'll try to boot into Windows and check what's happening there when I have some time.

Same result, though to a bit lesser extent, with -DCMAKE_BUILD_TYPE=Release:

$ ls -ln --time-style=+"" bin/solvespace -rwxr-xr-x 1 1000 1000 5290248 bin/solvespace $ ls -ln --time-style=+"" ../solvespace-png -rwxr-xr-x 1 1000 1000 5294640 ../solvespace-png

And after strip -g:

$ ls -ln --time-style=+"" bin/solvespace -rwxr-xr-x 1 1000 1000 5287192 bin/solvespace $ ls -ln --time-style=+"" ../solvespace-png -rwxr-xr-x 1 1000 1000 5291592 ../solvespace-png

@ruevs I'm having trouble reproducing your results on Windows (Visual Studio 2022, with -DCMAKE_BUILD_TYPE=Release -DENABLE_LTO=1):

>dir /c bin\solvespace.exe ..\solvespace-png.exe 8,433,152 solvespace.exe 1 File(s) 8,433,152 bytes 8,436,224 solvespace-png.exe 1 File(s) 8,436,224 bytes

Given the fact that as you noted embedded bitmaps support is unneeded, and that on both Windows and Linux I see an increase in file size of 3-4KB, it's probably best if we disable libpng support in FreeType. Should I submit a PR?

ruevs · 2025-03-07T09:23:33Z

What's weird though, is that we were already using WITH_ZLIB=OFF with the older version, but for some reason FreeType code was including its vendored header file of zlib regardless.

I think it is not weird because regardless of its description:

# . Set the `WITH_ZLIB', `WITH_BZip2', `WITH_PNG', and `WITH_HarfBuzz'
#   CMake variables to `ON' or `OFF' to force or skip using a dependency.
#   Leave a variable undefined (which is the default) to use the dependency
#   only if it is available.  Example:
#
#     cmake ... -DWITH_ZLIB=ON -DWITH_HarfBuzz=OFF ...
#
# . Installation of FreeType can be controlled with the CMake variables
#   `SKIP_INSTALL_HEADERS', `SKIP_INSTALL_LIBRARIES', and `SKIP_INSTALL_ALL'
#   (this is compatible with the same CMake variables in zlib's CMake
#   support).

it seems that the WITH_ZLIB define is not used anywhere in version 069083ccc ("* Version 2.7.1 released.") (or am I not finding it?).

The new option disables looking for a system ZLIB and uses the internal one instead:

if (NOT FT_DISABLE_ZLIB)
  if (FT_REQUIRE_ZLIB)
    find_package(ZLIB REQUIRED)
  else ()
    find_package(ZLIB)
  endif ()
endif ()

iscgar · 2025-03-07T11:30:36Z

What's weird though, is that we were already using WITH_ZLIB=OFF with the older version, but for some reason FreeType code was including its vendored header file of zlib regardless.

I think it is not weird because regardless of its description:

[snip]

it seems that the WITH_ZLIB define is not used anywhere in version 069083ccc ("* Version 2.7.1 released.") (or am I not finding it?).

It is a bit obscure, but it is used in the CMake loop here to find the package.

iscgar · 2025-03-07T11:54:28Z

Accidentally closed this. Sorry for the noise.

Makes the executable a bit smaller and we have no use for them anyway. https://learn.microsoft.com/en-us/typography/opentype/spec/cbdt#compressed-color-bitmaps See #1543 for discussion.

Makes the executable a bit smaller and we have no use for them anyway. https://learn.microsoft.com/en-us/typography/opentype/spec/cbdt#compressed-color-bitmaps See solvespace#1543 for discussion.

iscgar mentioned this pull request Mar 6, 2025

macOS build instructions in README don't work #1539

Closed

freetype: update the vendored version to 2.13.3

c3926d0

The existing version (2.7.1) is using an ancient zlib version, which fails to build with modern Xcode tools on macOS. Fixes solvespace#1539

iscgar force-pushed the iscgar/update-freetype branch from e4b6b12 to c3926d0 Compare March 6, 2025 21:30

ruevs reviewed Mar 7, 2025

View reviewed changes

.gitmodules Show resolved Hide resolved

ruevs reviewed Mar 7, 2025

View reviewed changes

iscgar closed this Mar 7, 2025

iscgar reopened this Mar 7, 2025

ruevs merged commit bd7b627 into solvespace:master Mar 7, 2025
8 checks passed

iscgar deleted the iscgar/update-freetype branch March 7, 2025 14:48

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update the vendored FreeType version to 2.13.3#1543

Update the vendored FreeType version to 2.13.3#1543
ruevs merged 1 commit intosolvespace:masterfrom
iscgar:iscgar/update-freetype

iscgar commented Mar 6, 2025

Uh oh!

iscgar commented Mar 6, 2025 •

edited

Loading

Uh oh!

Uh oh!

ruevs Mar 7, 2025 •

edited

Loading

Uh oh!

iscgar Mar 7, 2025

Uh oh!

ruevs Mar 7, 2025

Uh oh!

iscgar Mar 8, 2025 •

edited

Loading

Uh oh!

iscgar Mar 8, 2025 •

edited

Loading

Uh oh!

iscgar Mar 14, 2025 •

edited

Loading

Uh oh!

ruevs Mar 14, 2025

Uh oh!

ruevs commented Mar 7, 2025 •

edited

Loading

Uh oh!

iscgar commented Mar 7, 2025 •

edited

Loading

Uh oh!

iscgar commented Mar 7, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

iscgar commented Mar 6, 2025

Uh oh!

iscgar commented Mar 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

ruevs Mar 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iscgar Mar 7, 2025

Choose a reason for hiding this comment

Uh oh!

ruevs Mar 7, 2025

Choose a reason for hiding this comment

Uh oh!

iscgar Mar 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iscgar Mar 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iscgar Mar 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ruevs Mar 14, 2025

Choose a reason for hiding this comment

Uh oh!

ruevs commented Mar 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iscgar commented Mar 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iscgar commented Mar 7, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

iscgar commented Mar 6, 2025 •

edited

Loading

ruevs Mar 7, 2025 •

edited

Loading

iscgar Mar 8, 2025 •

edited

Loading

iscgar Mar 8, 2025 •

edited

Loading

iscgar Mar 14, 2025 •

edited

Loading

ruevs commented Mar 7, 2025 •

edited

Loading

iscgar commented Mar 7, 2025 •

edited

Loading