4/30/2023 0 Comments React font picker![]() ![]() With 64 bit floats, that’s 16 bytes for every command with two parameters, though we can use 32-bit floating point numbers to save 8 bytes. Many SVG path commands have two floating point numbers.If we encode the binary data with ascii85 (since binary data can’t be encoded directly in a JavaScript file), it would add ~25% overhead.It’s hard to say whether it would yield any benefit with back-of-the-napkin math: I speculated that a binary encoding would be far more efficient than a text-based one. SVG paths are letters (“commands”) followed by zero or more decimal numbers (“parameters”). I suspected that there was a way to encode SVG paths such that the consume less space. The bundle containing the font path data is over three megabytes on its own. That said, we still don’t want it to take ten or fifteen seconds for your fonts to load when the font picker is first opened. Many users won’t open a font picker, so the problem is mostly mitigated. ![]() Once my font previews were stored in their own file the performance issues are only a problem if you open the font picker. The long and short of it is that you load the bulky JavaScript file after the rest of the page, letting your application load sooner and only blocking rendering of your UI on the download when the UI is rendered before the JavaScript chunk has loaded. I won’t go into details about how to do code splitting with Webpack, as there are many articles out there that go into great detail. You can then load that chunk after the initial bundle has loaded. This technique is known as code splitting.Ĭode splitting is a way of instructing Webpack to generate a second (or third, or fourth…) JavaScript bundle containing a chunk of your application. The other answer is to lean on Webpack to do the heavy lifting for us. This makes it simple to load the font when it’s needed, but there’s a lot of boilerplate involved and it doesn’t play well with the build system. The most naive is to download the font data as a JSON file with fetch. Code splitting to the rescueĪ quick way to stop the bleeding is to load the font data separately from the main JavaScript bundle. This isn’t satisfying, though, and as Google adds new fonts, the problem will only get worse. Even if I discarded all fonts that take more than 14KB as an SVG path, the resulting bundle was three megabytes larger than it was before.Īn argument could be made for slow load times in such a complex application and loading indicators (like spinners or dancing dots) could be used to mitigate the delay in loading the JavaScript bundle. After gzip, the file was megabytes large. The resulting TypeScript file was enormous. This produced the results that I wanted, but a new challenge emerged. The font picker using the pre-rendered font paths I didn’t solve this problem properly (e.g., with a semaphore), but instead used a write stream to dump each line of the rendered font paths to the disk early, allowing the garbage collector to clean up each font file and path as it’s rendered. If done concurrently, Node easily hits out-of-memory errors. Each TTF file is loaded as a Buffer into memory, and the resulting SVG path can be dozens of kilobytes. Each SVG’s path (that is, the vector path, not the file path) is saved as a string to render with React later. ![]() Each font’s TTF file is saved to /tmp and passed to opentype.js to be rendered as an SVG. It filters out poor candidates for fonts to include (like barcodes) and creates data structures to store metadata. This compiler downloads the full list of fonts from the Google Fonts API. I started the project by building a compiler. By doing this, an easily-renderable preview could be stored in my JavaScript and drawn to the screen immediately. Instead, I decided to pre-render each font. Triggering the download when the font is to actually be displayed would make scrolling laggy and cause flashes of unrendered fonts. Using these directly is a poor option for a dropdown because opening the dropdown would trigger thousands of downloads of hundreds of megabytes of font files from Google. This introduced a rather unique and complicated set of challenges.įonts on Google Fonts are served as WOFF2 (or WOFF, or another format if your browser is older). While apps like Google Docs and others only display a handful of fonts to choose from, the Site Builder required the display of over a thousand fonts. Most font pickers in other applications show each typeface off by rendering its own name. A long while ago when building the Pinecast site builder, I came had a need for a dropdown that allows the user to choose a font from Google Fonts. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |