I see the following in the PrinceXML 13 release notes: "Fixed issues affecting SVG dominant-baseline auto and use the correct font size for SVG baseline-shift super/sub."

A DocRaptor customer is seeing stark differences between web browser and PDF rendering of SVG text containing subscript unicode characters. See the attached files for reference.

Is this something we can expect to be resolved in PrinceXML 13, based on the above notes, and / or is there potentially a solution or workaround in the meantime?

Regards,

Alex
DocRaptor Support

1. svg_with_subscript (1).html‎ 14.2 kB
2. svg_with_subscript (1).pdf‎ 10.8 kB

It looks like the subscript character is coming from the Apple Myungjo font as Arial does not have any glyphs for this character, however the DejaVu Sans font does so perhaps you could use that instead, perhaps via sans-serif as the fallback?

The baseline and vertical-align properties don't actually have any effect on the Unicode sub/superscript characters.

Got it. I'll forward that information along.

Thanks for the rapid response! - Alex

Hi,

I was the DocRaptor user with the original inquiry.

Thanks for checking. Things are clearer now. The fonts that I have been using trigger font substitution in order to display the subscripted character.

What is still strange to me is why a more reasonable font substitution is made in the html tagged texts vs. in the SVG, and in Safari vs. Prince. Safari appears to replace Arial with a version that apparently has the subscripted char. (I see no substitution happen in the SVG.)

See attached samples which have both SVG and a <p> with the same subscripted 2 character.

Safari aside, if I could force Prince to make a better substitute in the SVGs (same substitute as it does inside the p tags), then I wouldn't need to edit all of my files manually.

-- Chris

1. svg_with_subscript.html‎ 13.4 kB
2. svg_with_subscript.pdf‎ 1.7 MB

The SVG specifies "font-family: Arial" (with serif implied) while the rest of the HTML specifies "ArialMT, Arial, sans-serif" so that's going to get slightly different fallback.

In most cases though I don't think font substitution is going to lead to an elegant outcome here, it would be best to use a font for the text that includes glyphs for the subscript characters, or use a subscript span instead. Perhaps in future Prince could automatically generate fake subscripts like it does for small-caps when they are not present in the font.

OK, wow, I wasn't aware that the font-family attribute in SVG works the same way as HTML/CSS. Duh!

Short term problem solved! (I'll find some workable and available substitution font.)

I agree that using a font that includes the correct glyphs would be better.

A future Prince feature for fake subscripts/superscripts would be neat for scientific publications, but I understand if there are other priorities.