SVG File Export incompatible with Inkscape - How to batch convert to pdf successfully?
danielphili opened this issue · comments
Hey Kyle,
First of all - great work, thank you so much.
At the moment I am facing troubles when it comes to converting the produced svg output to a pdf file. I managed to find out that these statements will give me a valid file output:
image = svgling.draw_tree(t)
svg_data = image.get_svg()
file = open('t.svg', 'w', encoding='utf-8')
svg_data.write(file, pretty=True, indent=2)
file.close()
The output will look nicely in chrome. However, opening the file in Inkscape will result in an indistinguishable letter-scramble (see below, for reproduction, open your example_tree.svg in Inkscape..).
I suspect the node coordinates to be the reason for that. They are all (0,0), which is ok for chrome or firefox because the nested svg structure will be recognized. Inkscape seems to have problems with that.
My final goal is to save the tree as a pdf file. So I see two ways here: Either get it working with Inkscape - which I definitely need your help for - or finding another svg to pdf converter that is able to perform batch jobs (which I need and thus a solution like opening in browser->pdf print->post processing or any sort of online conversion are not an option). What are your thoughts and concerns about that?
Best regards and again many thanks,
Daniel
Thanks for the report! I have run across this inkscape issue before but couldn't figure out a solution at the time; I agree that it did seem to be related to the recursive SVG structure (I'm handicapped because I, at best, barely got inkscape working on mac). It's certainly something I would like to work.
Re batch conversion to PDF, how about cairosvg? It's not something I have used extensively but I just tried it out on one of the demo svgling trees and it produced nice results.
Thank you very much for the suggestion of cairosvg. Works like a charm on Win10, too :)
Great, glad that worked for you. I will leave this issue open for the export-to-inkscape problem.
Hey Kyle,
Great package, indeed! I managed to make the package work with Inkscape - all you need to do is to convert all x and y values from "em" to "px". Apparently Inkscape has no idea what ems are, but is pretty familiar with pixels. Changing to pixels works fine for Chrome (and I assume for Jupyter as well then).
Thank you again for the package!
Best regards,
Dmytro
oh, interesting, thanks @dkalpakchi ! I'll have to look into whether this is doable as a blanket change, since IIRC some of the dynamic sizing tricks rely on the use of em, but this at least points me towards a solution.
Hope it will be helpful, @rawlins! What is IIRC, btw?
Sorry to take so long to work on this, but I've finally added a compatibility mode that does not use em. Just pass relative_units=False as an option. I have pushed a new version of svgling with this option to pypi. I may eventually make this the default with further testing, but for now it isn't. As far as I can tell, the SVGs generated with this option load just fine in Inkscape. Another suggestion I got from a poster on the Inkscape forum is that LibreOffice draw seems to handle svgling output files fine, and will save them without nested structure or ems, so that is another conversion path.
I've done some more general investigation of the Inkscape compatibility issue, and still can't really get a handle on what's going on. As far as I can tell inkscape should support em (it's in the docs at least), and can handle nested svgs, so it may be the combination of them that is the issue. I'll leave this issue open for now as I don't consider this fully resolved.
(Edit: also sorry for the extremely laggy response to this simple question but IIRC = "if I recall correctly".)
As of 58fb952 I have defaulted relative_units to False, since it was necessary for other reasons (I may eventually remove the option altogether). I'm still not sure why this was a problem, but since I'm moving away from using ems directly for layout (working with font sizes in px instead), I'm going to go ahead and close this issue.