Artifacts at letter s of font Aleo after conversion - but font Aleo itself has no such issue in jspdf

[tomfree]

Artifacts at letter s of font Aleo after conversion - but font Aleo itself has no such issue in jspdf

[tomfree]

Font Aleo is taken from googlefonts (and the license there applies obviously)

[yGuy]

What PDF viewer are you using? In Edge, to me the pdf you uploaded looks like this:

Which doesn't look that wrong to me....

[yGuy]

Ah - it's only now that I see that the yellow stuff was your own "markup" ! Sorry - I thouhg the yellow text was overlapping the blue text, but this is your highlighting. Sorry. I do see that there are artefacts in the font rendering. Typically they can be seen if there is stroking applied or the font weight doesn't match the declared font. Are you sure that the mapping from font and font weight matches the font? I guess one would have to simply debug which calls are being performed on the jspdf context and how they differ from your calls.

[tomfree]

Sorry - wanted to highlight this things as they are pretty small.

Regarding the text/font in question I really just put the following to add the font data to pdf, convert the svg from the ticket and that's pretty much it.

const  fontBase64Data = /* same fontBase64 data as in SVG for font aleo-bold */
pdf.addFileToVFS(`${fontFamily}-Bold.ttf`, fontBase64Data);
pdf.addFont(`${fontFamily}-Bold.ttf`, fontFamily, 'normal', 700);

I may have an understanding issue regarding the API though - when I read your question if the mapping from font and font weight match the font.
From my understanding I load the fontbase64 data and then assign via addFont the family name and if I consider the font loaded to be italic and what weight it has - right? Oder do I have a gap there in my understanding?

The svg at that point reads so the font is bold which I understand is fontweight: 700 as I specify when adding the font. is that correct? Or do I just no get you?

<g transform="matrix(1 0 0 1 282.45 193.07)" style="">
		<text xml:space="preserve" font-family="Aleo" font-size="51" font-weight="bold" style="stroke: rgb(0,42,255); stroke-width: 2; stroke-dasharray: none; stroke-linecap: butt; stroke-dashoffset: 0; stroke-linejoin: miter; stroke-miterlimit: 4; fill: rgb(0,42,255); fill-rule: nonzero; opacity: 1; white-space: pre;"><tspan x="-212.57" y="16.02">This is a test - bold</tspan></text>
</g>

[yGuy]

The point is that svg2pdf (and then jspdf) needs to map font family and font weight and size to a physical font. And if they don't match, it could be that the browser renders something else than the pdf viewer.

You say that you were able to find a sequence of jspdf calls that resulted in the font being rendered, properly.
Since svg2pdf also simply issues a series of such calls, it should be easy to find out with a debugger how they differ. This would give us an idea where to look what might be going wrong.

That said: I now see that you have a "stroke" set on the font - this might be problematic, too, as stroking is a yet another story and it could also be that the font encoding is buggy, here or that either of the rendering engines has a bug, too. Have you tried modifying the stroke and see if this changes anything?