Conversation
The APIs will come back after zig build and use fewer dependencies that are easier to static build.
The APIs will come back after zig build and use our fork of lunasvg, which will be significantly easier to static build.
- Binaries are now distributed in a package per target triple - Cross-compiling ability significantly reduces maintenance burden - A single compiler (LLVM) removes tons of macros - Moving to zig-only build instead of node-gyp removes tons of macros - Several new Linux binaries were added with ease: musl, ARM, riscv64 - Back to zero package.json dependencies As the build.zig says, we will maintain our own build.zig files for almost all dependencies. This makes it easier to tailor changes.
This resolves so many open issues that I'm not going to list them. Highlights: - You can now register fonts from buffers - Emojis finally work - Font selection always works now, since it's our code, not Pango - Ability to unregister individual fonts - API is like the browser's
ImageSurface can now be used by the SVG engine to render images from PNG/GIF/JPEG/BMP data.
librsvg is too hard to support. We can't reasonably be shipping a copy of the entire glib library to everyone; this isn't Rust. lunasvg is the best option I could find: js: - canvg requires jsdom and failed to render serveral simple test SVGs - fabricjs also failed simple SVGs cpp: - librsvg is too hard to maintain - resvg is way too big and uses a whole separate (rust) toolchain - nanosvg failed simple SVGs drawbacks: - no support for filters or SVG2 - I don't think it supports font fallbacks or bidi upsides: - registered fonts work inside of SVGs - re-uses our own bitmap parsers
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Once and for all, this fixes the top issues users have experienced, which fall under these categories:
Font issues. Pango doesn't support registering fonts from buffers or indeed, registering fonts at all. Our font selection has always been a hack: we have to guess what family name and attributes should select a font that a user registered. Emojis didn't work unless everything is compiled right, and our current binaries are not.
I wrote our own font stack so we can have full control over font lookup and the registration API. Fonts are the whole reason I got involved in node-canvas over 10 years ago, and I've used most of those 10 years to learn how to write a font layout engine! Instead of Pango, we use zg and SheenBidi to segment the text into shaping boundaries, then HarfBuzz in between shaping boundaries to get glyphs for Cairo. This a relatively easy layout engine - we don't have to do line wrapping in canvas! Getting fonts efficiently from the OS is harder, but Firefox's source was a great guide.
Native builds. Modern node addons are distributed as a wide array of binaries; even users on more rare platforms are not expected to compile. Our existing solution of building for the host machine doesn't support this. We need to be able to cross-compile. Zig is an excellent fit, and I found it easier to use than CMake or Meson. This PR adds 6 more platforms and it'll be easy to add more. Bonus: size is halved in the worst case: some tarballs go from 20MiB to 3MiB.
Native distribution. Post-install scripts are being phased out: npm RFC #868 will block this package's install script by default #2595. NPM packages are the modern way to distribute binaries because it's safer and more reliable. We know the user can access NPM servers, but not necessarily GitHub releases, since corporate internet and proxies can interfere.
Why couldn't I do this in small pieces? (2) and (3) are tied together because it wouldn't make sense to update the old build system. (1) is tied to those because updating the old build before replacing the new (low dependency) font stack would be tons of wasted work. Adding the font stack first would've meant we couldn't use zg. Unicode libraries are hard to package, bug Zig makes it easy. So the PR removes fonts, adds static build, then adds fonts back. Diff accordingly.
As a bonus I fixed #1394 since it became easy on this branch (last commit).
I don't expect anyone to seriously review all of this code, but review at any level is welcome, as well as testing. I'll release some betas off of this PR soon. @LinusU and @zbjornson - it's been a while, but I would love to hear from you!
The Ugly
It isn't possible to keep using librsvg and have a static build, it is just too huge of a library and I don't have the time for it. lunasvg is able to support a surprising number of SVG 1.1 files while still being nimble. Sadly, no
<filter>or SVG2 support, and that is a breaking change.There are too many issues to list here. I'll hunt them down and close them after this gets merged.