-
Notifications
You must be signed in to change notification settings - Fork 229
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
Use correct encoding when processing SVG files #400
Comments
Comment by @formatc1702 in the original thread:
Originally posted by @formatc1702 in #395 (comment) |
Citing the Graphviz FAQ - NonAscii:
So, I would interpret this to be an issue about font selection and not UTF8. Just ensure that we provide a font to GV that is available for rendering (into raster images). Please have a look at Sketchviz, which delivers two embedded CSS fonts along with the SVG. This works nicely because the font name is passed through. |
@martinrieder wrote:
I took the liberty to append the
We can do that, but it shouldn't be critical because utf-8 is default when this attribute is absent: https://graphviz.org/docs/attrs/charset/
WireViz currently use A user that specify a different font must also be responsible to ensure that such a font is available at final rendering time.
PostScript target code is currently not used by WireViz, so these restrictions don't apply, unless this will be the first step to support PDF output in the future.
If the GV file has e.g. However, the SVG output contains This bug might be due to my old version: To generate such an input file, execute e.g.: Path('ch.gv').write_text('graph {\n graph [charset="iso-8859-1"]\n AæøåA -- B\n}\n', encoding="iso-8859-1") When I input UTF-8 encoded GV files, it seems to work.
I don't agree the issue is only about font selection. See my charset experience description above.
I tried this, but was only allowed to download PNG unless I authorized SketchViz to log in to my github account on my behalf. I don't trust a random 3rd party software to access my github resources, and I don't have time to create a dummy account just now. |
@kvid you do not need to link Sketchviz to GitHub. Just have a look at the sources and search for the font "Handlee" that is given from the example. There is a link to Google fonts CSS, which is referenced from the SVG that is embedded in the website. PS: The latter actually contains a bug which resets the font to "Helvetica,Arial,sans-serif", but the embedded CSS font is available. I corrected this and uploaded the file here: PPS: Looking at the logo that I uploaded to #373 (comment), I notice that this SVG file generated by svg2roughjs contains two font definitions. My observation is that the CSS definition |
Here, the SVG file is specified to be utf-8 encoded:
https://github.com/wireviz/WireViz/blob/close_files/src/wireviz/wv_html.py#L45
It's not specified at:
https://github.com/wireviz/WireViz/blob/close_files/src/wireviz/svgembed.py#L62-L64
What is correct? Should we specify utf-8 at both places, or does it really depend on what encoding is specified in the leading part of the SVG file itself?
We probably should assume utf-8 and specify that encoding at both places. I also found a third place where that is already done: https://github.com/wireviz/WireViz/blob/close_files/src/wireviz/Harness.py#L662
Then, we probably also should (as a minimum only where embedding SVG into HTML, or ideally at all places reading SVG) verify that the
encoding
property of the leadingxml
tag is either absent (utf-8 is default, I believe) or equal to any of the legal value variations that specify utf-8. If we detect a discrepancy, should we raise an exception or just print a warning stating e.g. that some characters might be rendered wrongly due to an unexpectedencoding
in the SVG file?If we can get or create some SVG with e.g.
encoding="ISO-8859-1"
containg some known characters outside the common ASCII range, we could test to see the effect of assuming the wrong encoding at the different parts of our code. Then it'll be easier to describe possible consequences in a warning message.Originally posted by @kvid in #395 (comment)
The text was updated successfully, but these errors were encountered: