rawlins/svgling

linguistics tree drawing to SVG in python, aimed at Jupyter

svgling's Issues

SVG File Export incompatible with Inkscape - How to batch convert to pdf successfully?

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

SVG line drawing issues

It is notoriously challenging to get crisp thin lines in svg, and some aspects of svgling run up against this problem. Issues arise when lines are positioned across physical pixels relative to the display resolution, and in my testing it is extremely hard to avoid this in a general way (SVG makes no real provision for snapping a picture to pixel space). On hidpi screens this is basically not an issue, but it shows up on lower-resolution devices.

Right now, movement lines (and a few other things) have shape-rendering="crispEdges" set, which prevents this, at the cost of causing them to dodge slightly off center relative to the arrowhead. This isn't a generally useful setting, because in addition to forcing pixel alignment, it also will disable antialiasing in all browsers that I've tested, and so anything off 90 degree alignments looks terrible with this setting. This setting doesn't seem to work (at least the way I'm using it) on safari.

I've tried various other hacks with limited success:

• applying a vacuous transform (translate(0) or rotate(360)) is reported to cause snapping to pixels in some browsers, but I haven't had much luck with this.
• offsetting the image by 0.5px works in some browser/screen configurations, but isn't generally applicable. (Some browsers align round values with the lines between pixels, rather than the middles of pixels themselves.)
• changing the opacity or color of lines can help, but it's not a very user-friendly solution.
• early versions of svgling used line thicknesses that were less than 1px (e.g. I was using 0.5pt). These do look better in a lot of cases, but I became unsure how safe they really are to use in general.

Many applications use some browser-sniffing javascript to apply one or more of these tricks as needed. This may be what I'll need to do in the end.

save svg

hi
how to save svg file?

Stability of svgling.html across browsers and mathjax renderers

There are a bunch of combinations that aren't working great, this issue is to track them.

Safari issues with SVG sizing. Safari is handling scaling of SVGs with keepAspectRatio="none" differently than other browsers (I want to say it's wrong, but I'm not really sure). What seems to happen is that if you set a height and leave width as auto, then it provides a default size for the svg that uses the width that you'd get if you just stuck it in a div without scaling. Other browsers seem to use the width that would keep the aspect ratio. Ideally I guess I'd want to use intrinsic sizing or something, but I don't know how to get this to work.

nbconvert outputs. Like many similar issues I've had in the Lambda Notebook, MathJax responsive linebreaking is really unreliable in nbconvert outputs.

CommonHTML whitespace bugs. In the CommonHTML renderer, nodes consisting of a multiline MathJax output where the linebreaks are done by MathJax insert width:100% in some of the contained spans. This impacts auto sizing of the containing node and adds some whitespace. For node labels in particular, the result is that their positioning is off. This only comes up for nbviewer outputs since CommonHTML is not even available for interactive Jupyter yet, but given that it's been by far the best renderer for nbconvert outputs, I will need to deal with this at some point.

This bug seems to only impact multiline nodes done via MathJax - so single MathJax lines are fine, and multiline nodes with mathjax where the linebreak is inserted manually via html somehow seem fine (though I haven't done a lot of this yet). I should investigate the possibility that this CommonHTML behavior is a MathJax bug? It doesn't happen in any other renderer.

I found a partial fix by using intrinsic sizing, but this is a bit variable/beta across browsers and in particular didn't handle nodes that mixed regular text and mathjax, so I decided it wasn't reliable enough to use. This potential fix works by adding the following style to the containing div in svgling.html.html_text_wrap:

"width: -webkit-min-content;width: -moz-min-content;width: min-content;"

Per node styling support, eg. font colors

Hey there,

is there any support for separate SVG styles per node? My current workaround is to use HTML trees, but that blocks the usage of other useful features, like leaf_nodes_align, or non-binary trees.

Also, big thanks for this project, really easy to use and well documented!