WireViz [bug] SVG Table borders are exeeded.

If a field is too long, the table border is exceeded. This error happens only in SVG output, not in PNG output. My temporary solution is to convert the GV file directly into a PDF with: "dot -Tpdf example.gv -o example.pdf" to create a correct vector graphic. Is it possible to fix the SVG output? I think this is a graphviz error - so can you add a direct PDF output for propper vectorized graphics? With code:

connectors:
  X1:
    pinlabels: [One, Two, Three]
    manufacturer: Manu1
    mpn: TODO
    type: Power
    subtype: Male
    notes: | 
      Here is a very long note text with very much information about the cables.
  X2:
    pinlabels: [One, Two]
    manufacturer: Here is a long Manufacturer
    mpn: 123456789ABCDEF
    type: Power
    subtype: Male
  X3:
    style: simple
    manufacturer: Manufacturer
    mpn: 1234
    type: Ring Terminal
    
cables:
  Power Cable:
    manufacturer: Here is a long Manufacturer
    mpn: 123456789ABCDEF
    wirecount: 2
    length: 5
    gauge: 22 AWG
    colors: [RD, BK]

  Cable 1:
    manufacturer: Here is a long Manufacturer
    mpn: 123456789ABCDEF
    wirecount: 1
    length: 5
    gauge: 20 AWG
    colors: [BUYE]

connections:
  -
    - X1: [3]
    - Cable 1: [1]
    - X3
  -
    - X1: [1-2]
    - Power Cable: [1-2]
  -
    - Power Cable: [1-2]
    - X2: [1-2]

Oct 13 '20 10:10 norator42

Thank you for reporting this unexpected SVG output, @norator42 . I'm really sorry for you not receiving any feed-back about this issue for more than a year. That is not intentional, but is probably because the contributors to this project are only able to spend their spare time working with this, and there might be long periods without anyone reading new issues. Then some issues might slip through without any answer when trying to catch up after a low-activity period.

I cannot seem to reproduce your issue using Ubuntu 18.04.4 LTS and WSL1 in Windows 10, Pyhon 3.7.5, and WireViz v0.2, v0.3.2, or the current v0.4-dev. The older verison 0.1 cannot have been used because your input contains the connector attribute pinlabels that was added later.

Can this issue depend on the program rendering the SVG output? I have tried Microsoft Edge Version 97.0.1072.55 (Official build) (64-bit) and Google Chrome Version 97.0.4692.99 (Official Build) (64-bit) in Windows 10. Another factor that might affect the result is the currently installed fonts.

Can someone else try to reproduce this issue in different environments than what I have access to? To avoid such problems, we encourage everyone to supply enough information to reproduce the reported state when creating an issue.

Feb 13 '22 02:02 kvid

I am also experiencing this problem using:

Ubuntu 22.04.1
Python 3.10.6
wireviz 0.3.2
graphviz 2.43.0
graphviz (python module) 0.20.1

I am not experiencing the problem using:

Ubuntu 18.04.6 LTS
Python 3.7.5
wireviz 0.3.2
graphviz 2.40.1
graphviz (python module) 0.19.1

Rendered on:

Firefox 106.0.5 (ubuntu 18)
Chrome 107.0.5304.110 (ubuntu 18)
Inkscape 1.0.2 (ubuntu 18)
Firefox 107.0.1 (ubuntu 22)
Chromium 108.0.5359.124 (ubuntu 22)
Inkscape 1.1.2 (0a00cf5339, 2022-02-04) (ubuntu 22)
Chrome 108.0.5359.124 (windows 10)

I've confirmed that my browsers are actually using arial and not the liberation-serif ubuntu default.

Interesting discovery! Its the svg files, not the browser. The files generated on my 18.04 machine look fine on all my machines, but the ones made on 22.04 exceed borders everywhere.

This issue is not resulting from inside wireviz, I can reproduce it by directly calling dot on the gv file to export the svg and png. The problem goes away if I force dot to render the svg using cairo (this is what happens when pngs are generated), unfortunately this results in large file sizes because each glyph is embedded as a path in the svg and the text is not searchable.

On both systems verbose output from dot confirms that they are using the same path to the same font ttf file. It seems like the newer graphviz (specifically its native svg driver) has a different idea of what arial looks like than the rest of the system (smaller kerning), as such the text boxes it draws are too small for the larger kerning when the font is rendered by the browser. The older version of graphviz correctly estimates the text dimensions so everything lines up.

I think further investigation will have to take place over on graphviz's gitlab repo.

In the meantime my workaround for the issue is to modify wv_html.py and replace https://github.com/formatc1702/WireViz/blob/b0d0070f08247e132b11bf45e617da9e8e1881f1/src/wireviz/wv_html.py#L26-L32 with file.write(f'<img src={filename}.png>\n'). This of course means the html file is no longer standalone.

Dec 17 '22 07:12 goopypanther

Thank you very much, @JeremyRuhland for the detailed documentation about your experiments and their results. I agree that the root cause seems to be inside some graphviz component for SVG output.

Interestingly, your suggested work-around seems to be somewhat similar to one of the optional features I argued for some time ago in https://github.com/formatc1702/WireViz/pull/189#issuecomment-727273556 and the owner didn't reject the idea, just wanted to finish the basic new features first.

No surprise then, that I support your suggested work-around as an optional feature.

Jan 09 '23 18:01 kvid

Maybe @JeremyRuhland can edit his posting above (or add a new one) to include one or two image files that demonstrates this problem (together with their YAML source and how they were produced)?
If anyone has already posted this problem as an issue at the graphviz's gitlab repo, please provide a link to it here.
If there are no such issues there yet, are you @JeremyRuhland willing to report it as a problem there (possibly linking to this issue here after providing image(s) demonstrating the problem)? If not, then maybe someone else might help with that part?

Mar 29 '23 18:03 kvid