SVG fonts depend upon browser-only APIs

[gingerchris]

When working with a font using the SVG table, in node, I'm experiencing the following error:

const svgDocument = new DOMParser().parseFromString(text, 'image/svg+xml');
                        ^
ReferenceError: DOMParser is not defined

On investigation I can see that the makeSvgImage function makes use of browser-specific DOM APIs:

• DOMParser
• document.createElement / document.appendChild
• svg.getBBox
• new Image

I think these APIs not being available in node pretty much makes opentype SVG fonts unusable in node at present, particularly given the rendering pipeline seems to rely on returning Images.

I have some experience of working with SVGs in node and would like to help resolve this but would need some direction please. Most of what I've done before relies pretty heavily on additional dependencies (svg-path-bbox for bounding box calculation, linkedom for DOM stuff, canvas for Image) but these are not particularly lightweight (particularly canvas which comes with a bunch of overheads).

It seems like it would be better to look at alternative ways of rendering here, like maybe returning SVGs as strings rather than Images? I wonder if it's also possible to get the bounding box dimensions from elsewhere in the font file - like from the fallback glyphs used in environments where the svg table is not supported?

Thanks for all your hard work on this project.

[gingerchris]

Alternatively, maybe a simpler short-term solution would be to bypass this when running in node and use the standard non-svg rendering path instead?

[gingerchris]

Alternatively, maybe a simpler short-term solution would be to bypass this when running in node and use the standard non-svg rendering path instead?

My mistake - I see now that this is possible by passing drawSVG: false as part of the options object

[Connum]

Thanks for your input! I'm a bit confused though, is your issue solved now with that option, or not? Can you post a minimal usage example? Because I think it shouldn't be necessary to call these helper functions manually at all, that's why they are not even properly documented. You can already get SVG path data on a higher level.

[gingerchris]

@Connum sorry - here is a minimal example using purple-magic-svg-font (zipped because github wont allow me to attach an .otf)

note: I also had to change the import & export in index.mjs to point to mjs files for this to run

demo.js

import {parse} from './src/index.mjs';
import * as fs from 'node:fs/promises';

const run = async () => {
  const buffer = await fs.readFile('./PurplemagicdemoSvg-x32mO.otf');
  const font = await parse(buffer);
  console.log(font.getPath('A', 0, 0, 72));
}

run()

command to run

node demo.js

This outputs some path commands as expected but they're followed by the DOMParser error.

adding { drawSVG: false } to the getPath command stops the error.

This option does solve my issue - I think I can just access the SVG glyphs from the svg table, but maybe there could be a fallback for node so it doesn't need this option in order to not error?

[Connum]

maybe there could be a fallback for node so it doesn't need this option in order to not error?

I'll look into that! There should be no need to get the data from the table directly, we should make everything work using API functions.

[gingerchris]

Currently the path.toSVG() method returns the svg path for the fallback: single colour, single <path> element, although I see there is a TODO to get that resolved

[herrstrietzel]

@gingerchris: In case you're mainly interested in extracting the SVG data you may adapt this browser.js approach. All methods should be replaceable or supported in node.js.

You can try to decode the raw SVG markup from the SVG table via new TextDecoder('utf-8').decode(svgData) like so:

(async () => {
    let fonturl = "https://fonts.gstatic.com/s/bungeespice/v12/nwpTtK2nIhxE0q-IwgSpZBqCzyI-aMPF7Q.ttf";

    let buffer = await (await fetch(fonturl)).arrayBuffer();

    // parse
    let font = await opentype.parse(buffer);

    // get metrics
    let {ascender, descender, unitsPerEm} = font;
    let tables = font.tables


    // extract svgs from raw SVG table data
    let svgTable = font.tables.svg;


    for (let item of svgTable.entries()) {
        let [glyphId, svgData] = item;

        // get SVG markup
        let svgText = new TextDecoder('utf-8').decode(svgData);

        // get glyp object
        let glyph = font.glyphs.get(glyphId);

        // get glyph metrics
        let {advanceWidth, leftSideBearing} = glyph;
        let height=unitsPerEm +-descender;
        let top = -unitsPerEm;
        let width = advanceWidth

        // add a viewBox
        let viewBox = `0 ${top} ${width} ${height}`;
        svgText = svgText.replace('version="1.1"', `viewBox="${viewBox}" `);

        // append
        svgs.insertAdjacentHTML('beforeend', svgText)
    }
})();  

See codepen demo. This probably won't work for all OT SVG fonts but at least it worked for your example.

Instead of calculating the bounding box we can map the SVG item to the base glyph object by its ID to retrieve the metrics data.
This way we can add a viewBox according to the glyphs metrics.
This obviously won't be a tight viewBox but a bounding box that respect the EM rectangle.

For a tight bounding box you should be able to retrieve it via native "Glyph.getBoundingBox()"

[gingerchris]

@herrstrietzel thank you - the approach using glyph.getBoundingBox is pretty much the same as what I've ended up doing, so it's great to know I've followed the right track. Thanks very much for your help