Closed saidwho12 closed 3 years ago
sometimes this happens as well, this is a Japanese font
Yes, it is because of different directions of the path. Use msdfgen::resolveShapeGeometry
.
Is there any way to fix this without skia? I am setting it up but it's quite large especially for my project.
The skia project is literally ~600MB, how hard really is it to implement this into msdfgen? Thanks for the solution btw I'll implement it for now but I have a feeling this might be a bit too large for my project which is a reading application. Maybe it's not too slow at runtime but the binary is very large. Another issue is I don't want too many dependencies, and skia has many by itself which sucks. If it's not too bad I'd be willing to try and solve this problem myself.
If the problem is just winding order for glyph paths and segments shouldn't it be something quite easy to solve?
@Chlumsky Do you have the file FindSkia.cmake? I have just built Skia but no idea how this should be structured.
If it's easy to solve, then you can go ahead and solve it, that'd be quite helpful.
For some of the cases like the brackets and the "é", you can probably just use Shape::orientContours
, but for other cases like the Chinese character, Skia is needed to resolve self-intersections. As for how to compile it with CMake, I don't use it so no idea.
Aight, I'll try get Skia working.
I assume this is an issue with the direction of the path, no idea if this is a known issue or not. It doesn't happen on all fonts thankfully.
The font I'm using for this is
LibreCaslonText-Regular.ttf
, I'm using freetype and passing theFT_Face
to msdfgen. I wanna know is this easily solvable at all?(edit 1) This happens either on whole glyphs or parts of glyphs.