You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
svgTextMeasure does not consider font-family when measuring text width. Instead it uses a fallback.
svg2pdf.js version: 2.2.4
JSPDF version: 2.5.1
To Reproduce
To reproduce visually with an SVG:
Create a jsPDF doc const doc = new jsPDF()
Add a font to the doc. For mine I used Noto Serif from fontsource CDN. It's likely not relevant since I did verify the font works, but just in case my process for adding fonts is
a. fetch font using JS fetch
b. await response.arrayBuffer(), then convert array buffer into binary string
c. doc.addFileToVFS(${name}-${style}.ttf, btoa(binaryString));
d. doc.addFont(${name}-${style}.ttf, name, style);
e. Verify the font does work with a simple SVG to PDF case (<svg><text font-family="Noto Serif">Test</text></svg>
Observe that an SVG like the following doesn't work properly.
You can also reproduce this by just manually overriding the fontFamily used in svgTextMeasure to something nonsensical and observe that when the canvas vs. svg text measuring method decision happens with the test string, the svg text element's bbox().width value is always 760.640625, regardless of whether you use your custom font or not.
With the canvas measuring method the issue is still present, but less so:
Expected behavior
The PDF should display the tspans at the correct distance.
Screenshots
Screenshots above
Desktop (please complete the following information):
OS: Windows
Browser: Chrome
Version: 126.0.6478.127
The text was updated successfully, but these errors were encountered:
Well, one could argue that the result should still be consistent, even if the CSS rules make no particular sense. Ideally svg2pdf should have resolved the style rule, applied the font and then rendered the spans properly. However it is hard to automatically resolve styles like this to the effective font being used, so I guess the problem here is that we are either not properly resolving the font or embedding the wrong one in the end. Or is it just a missing font (for the export)? Ideally there should be some kind of warning, then.
Describe the bug
svgTextMeasure
does not consider font-family when measuring text width. Instead it uses a fallback.svg2pdf.js version: 2.2.4
JSPDF version: 2.5.1
To Reproduce
To reproduce visually with an SVG:
const doc = new jsPDF()
a. fetch font using JS
fetch
b. await
response.arrayBuffer()
, then convert array buffer into binary stringc.
doc.addFileToVFS(
${name}-${style}.ttf, btoa(binaryString));
d.
doc.addFont(
${name}-${style}.ttf, name, style);
e. Verify the font does work with a simple SVG to PDF case (
<svg><text font-family="Noto Serif">Test</text></svg>
The text overlaps incorrectly.
![image](https://private-user-images.githubusercontent.com/15696989/351436101-975a90f9-d91c-4890-b69b-5c002bcac8ea.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQ3MTEwOTAsIm5iZiI6MTcyNDcxMDc5MCwicGF0aCI6Ii8xNTY5Njk4OS8zNTE0MzYxMDEtOTc1YTkwZjktZDkxYy00ODkwLWI2OWItNWMwMDJiY2FjOGVhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODI2VDIyMTk1MFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTc1ODk2YWQzZTVlYWI0MmVhZDA3ODBhODU0YzFmOTc5MDQ0ZDZjYzIwMjE2ZTA5YjU1NDQ4ZDk3MDc4MDZjOTImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.h_0r7aHhncHoq4zJvZWIV2FPuDE6-Y_C1xKZ3na3fO4)
You can also reproduce this by just manually overriding the
fontFamily
used insvgTextMeasure
to something nonsensical and observe that when the canvas vs. svg text measuring method decision happens with the test string, the svg text element'sbbox().width
value is always760.640625
, regardless of whether you use your custom font or not.With the canvas measuring method the issue is still present, but less so:
![image](https://private-user-images.githubusercontent.com/15696989/351437260-a0758203-8e9a-49fe-864a-cdd1f40c8e06.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQ3MTEwOTAsIm5iZiI6MTcyNDcxMDc5MCwicGF0aCI6Ii8xNTY5Njk4OS8zNTE0MzcyNjAtYTA3NTgyMDMtOGU5YS00OWZlLTg2NGEtY2RkMWY0MGM4ZTA2LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODI2VDIyMTk1MFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTkzYzY0YmY4MzZmMjU4YjlkYjRjOTQxZjVkZjY0OWJiZjAzNmNiZWI1NDFjNTNmMGNkY2NmOGIzN2QyMWRhZjAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.ltDq0jKNNbfmoztAXYOX34LJbB41UyS2bixu_S4HJBs)
Expected behavior
The PDF should display the tspans at the correct distance.
Screenshots
Screenshots above
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: