[bug] SVG Table borders are exeeded.

[norator42]

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]

[kvid]

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.

[goopypanther]

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.

[kvid]

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.

Edit: An alternative work-around that will keep the HTML file standalone, is to embed the PNG file in the <IMG> tag as described in https://github.com/wireviz/WireViz/pull/189#issuecomment-720104657 (i.e. base64 encoded).

[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?

[ask6483]

Hi all,

I have the same issue on Debian testing. Tried to change the font to Liberation Sans or DejaVu Sans but the issue remains.

Versions:

• Debian Trixie testing
• graphviz 2.42.2-8
• wireviz 0.4-dev
• python 3.11.8
• python graphviz 0.20.1

[kvid]

@ask6483 - thank's for confirming this issue. Are you able to include here, one or two SVG image files that demonstrates this problem (together with their YAML source and how they were produced)?

[kvid]

I suggest adding a few placeholders for usage in HTML templates (a new feature added in v0.4) that can help as a work-around when experiencing SVG problems like this:

• <!-- %filename% --> = output filename with absolute path, but without extension
• <!-- %filename_stem% --> = output filename without path nor extension
• <!-- %diagram_png_base64% --> = base64 encoded PNG diagram that can fit into an image tag like this: <img src="<!-- %diagram_png_base64% -->">

Then any user can make a custom template using an image tag (<img src="...">) for the diagram with either the PNG filename or base64 encoded PNG contents as src.

Please suggest better names for my suggested placeholders, and maybe other placeholder variations that might help.

[ask6483]

@kvid sorry for late reply but I lost the track until yesterday notification, here are the files test_files.zip.

It looks like the issue is more visible in html/pdf render than in svg file itself:

1. PDF
2. SVG

[kvid]

@ask6483 - Thank's for the test files. I agree that the issue is greater when rendering your PDF (in Okular v23.08.1 and in Brave v1.65) than when rendering your SVG and HTML (both in Brave v1.65). How did you render your files? And how did you generate the PDF files?