I'm gonna go out on a limb and say that this is a font issue. The glyphs appear to be made up of several smaller elements instead of one big one.

@LaurenzV

I don't know enough about how the stroke feature works in Typst, but yeah it looks like the outlines in the font have overlaps (which is fine in principle), but I guess this then ends up looking weird if you add an additional stroke to the outlines.

I don't know enough about how the stroke feature works in Typst, but yeah it looks like the outlines in the font have overlaps (which is fine in principle), but I guess this then ends up looking weird if you add an additional stroke to the outlines.

I guess that, in theory, typst could merge them together first before applying the stroke.

That’s a big “in theory”, I think, as far as I know overlap removal is a very difficult problem.

That’s a big “in theory”, I think, as far as I know overlap removal is a very difficult problem.

They're described as the interior of closed bezier curves no? I'm fairly confident there are existing libraries that can compute unions of such sets.

That being said, it would obviously be best if the font didn't do this in the first place.

Edit: Some googling leads me to believe that this is very common in variable fonts, so presumably this will become a bigger issue over time.

@yankydoo are you using the variable or static version of the font? Typst doesn't properly support the former yet, so you may as well try the static version (which had a greater likelihood of not containing overlap).

I'm gonna go out on a limb and say that this is a font issue. The glyphs appear to be made up of several smaller elements instead of one big one.

... it would obviously be best if the font didn't do this in the first place. Some googling leads me to believe that this is very common in variable fonts, so presumably this will become a bigger issue over time.

💯 , this is not a font issue, this is how the OpenType font specification works, and it is unreasonable to expect fonts not to do this in 2024 :) In the early 80s, the PostScript Type 1 format didn't allow glyphs "to be made up of several smaller elements instead of one big one", and that has persisted until recently as OpenType-CFFv1 is really just a wrapper around that Type1 format to bring into the Unicode era in the late 90s. But it is required for variable fonts to vary, and it is allowed by the OpenType-TTF spec for static fonts.

That’s a big “in theory”, I think, as far as I know overlap removal is a very difficult problem.

They're described as the interior of closed bezier curves no? I'm fairly confident there are existing libraries that can compute unions of such sets.

Yes, removeOverlap() is the typical function name, and Google Fonts pays to maintain a Python binding to Skia PathOps.

@yankydoo are you using the variable or static version of the font? Typst doesn't properly support the former yet, so you may as well try the static version (which had a greater likelihood of not containing overlap).

Despite that GF maintains that project, the static fonts in the download zips from Google Fonts don't yet have this applied. It is common that applications don't properly support outling-stroking of fonts with overlaps, sadly, as I mention in the Flutter issues I mentioned in #185

(Potential stupid idea alert!) Would drawing the stroke behind the ‘fill’ part be a possible workaround?

(Potential stupid idea alert!) Would drawing the stroke behind the ‘fill’ part be a possible workaround?

That would work assuming alpha isn't involved. The proper solution is still removing overlaps, which also cause other issues than just strokes.