Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] SVG text output: CDATA container may contain invalid string #43

Open
albrechtd opened this issue Jul 29, 2022 · 1 comment
Open

Comments

@albrechtd
Copy link

I noticed that the contents of text elements in the svg file produced by emf2svg-conv is wrapped into an extra CDATA container. E.g. the attached trivial EMF file (Sample.zip; created by LibreOffice) is converted into a SVG file containing

<text  clip-path="url(#clip-1804289383)" font-family="Liberation Sans" fill="#000000" style ="white-space:pre;" font-weight="400" text-anchor="start" x="273.9291" y="508.8484" font-size="25.4705" ><![CDATA[This is a simple test.]]></text>

My problem: I usually use GraphicsMagick (on Debian Bullseye) to convert the result to a bitmap (gm convert …), which apparently just skips the text. This actually might be a GraphicsMagick issue (as ImageMagick does render the text, but it is way slower and a little unstable, so I prefer GraphicsMagick), though. What is the reason for the extra CDATA container? Would it be possible to omit it?

Thanks, Albrecht.

@albrechtd albrechtd changed the title SVG text output: extra CDATA container? [Bug] SVG text output: CDATA container may contain invalid string Aug 1, 2022
@albrechtd
Copy link
Author

albrechtd commented Aug 1, 2022

Digging deeper into this issue, it appears that the text output is actually broken iff an EMF text item contains the CDATA termination string ]]>: running the sample from 43_sample_bug.zip through emf2svg-conv (on Debian Bookworm, Version 1.1.0+ds-3) produces an invalid SVG file. E.g. xmllint reports

Sample-orig.svg:6: parser error : Sequence ']]>' not allowed in content
art" x="10.3602" y="301.2697" font-size="25.4705" ><![CDATA[CDATA end marker ]]>
                                                                               ^

Proposed solution: Instead of writing the string verbatim in a CDATA container, escape the reserved XML characters <, & and > (escaping the latter is not strictly required) as in this patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant