SVG standard informations (size & line breaks)

[Daryes]

version : latest release (v1.4.3)

Currently, the SVG rendering, while working fine, seems to lack some information to have the same rendering as the png format

• the header <svg xmlns="" ...> seems to be lacking the height and width and/or the viewBox. While it doesn't stop the browsers to render the files, some converter tools doesn't always plays ball when such information is missing

• the line break between each directory name and the used space isn't supported as is.
  For example, this doesn't work, the text is rendered on a single line :

<text x='339' y='364' font-size='8pt' fill='black' stroke-width='0'>modules
60.6M</text>

On the other hand, using tspan with dy used for a relative vertical placement works :

<text x='339' y='364' font-size='8pt' fill='black' stroke-width='0'>
<tspan x="339" dy="0">modules</tspan>
<tspan x="339" dy="1.2em">60.6M</tspan>
</text>

nb : presented as multi-line for the example, but a single line is also valid, the line break comes from the <tspan ... dy="xx"> tag.

Could both be implemented ? Especially the tspan, as it helps with the readability.

[zevv]

Hi, Quoting Daryes (2018-09-24 19:22:00)

Currently, the SVG rendering, while working fine, seems to lack some information [...] Could both be implemented ? Especially the tspan, as it helps with the readability.

Duc's SVG renderer is actually a bit of legacy code, which was used in the web/CGI backend before the current Javascript graph renderer was implemented. As Duc is built with Cairo by default, and Cairo has a proper SVG render backend, it is probably a good idea to let Cairo handle this instead of doing this by hand. I could leave the old SVG backend in for cases where cairo is not available, or just throw it out (my favourite choice!). The patch below changes the SVG renderer to use Cairo: if you are compiling from source, you might be able to check if this works for you. I have attached two .svg files with the old and new rendering style, let me know if the new one fits your needs. (There is one advantage to the manual SVG renderer though: the output size is about 10 times smaller then the cairo generated SVG. I'm not sure if that is a good reason to keep it, though) Ico diff --git a/src/duc/cmd-graph.c b/src/duc/cmd-graph.c index 7d749f4..f44d736 100644 --- a/src/duc/cmd-graph.c +++ b/src/duc/cmd-graph.c @@ -98,17 +98,19 @@ static int graph_main(duc *duc, int argc, char **argv) duc_graph *graph; switch(format) { - case DUC_GRAPH_FORMAT_SVG: - graph = duc_graph_new_svg(duc, f); - break; case DUC_GRAPH_FORMAT_HTML: graph = duc_graph_new_html(duc, f, 1); break; #ifdef ENABLE_CAIRO case DUC_GRAPH_FORMAT_PNG: case DUC_GRAPH_FORMAT_PDF: + case DUC_GRAPH_FORMAT_SVG: graph = duc_graph_new_cairo_file(duc, format, f); break; +#else + case DUC_GRAPH_FORMAT_SVG: + graph = duc_graph_new_svg(duc, f); + break; #endif default: duc_log(duc, DUC_LOG_FTL, "Requested image format is not supported");

…

-- :wq ^X^Cy^K^X^C^C^C^C

[Daryes]

I'm compiling using usually the tgz releases. Can try directly from master, still.

Anyway, Cairo is the weak link here, at least for my purpose :

• on systems with X11 installed, I'm rendering to PNG using cairo.
• on headless servers, because cairo requirements are linked to too much X11 libs packages on debian/ubuntu, the output is using the SVG format with a dedicated binary built with --disable-x11 --disable-cairo.

Because of that, the native SVG rendered in Duc is clearly appreciated, and is a nice complement to the monitoring for pinpointing files stealing disk space.

[zevv]

Quoting Daryes (2018-09-25 01:50:07) Anyway, Cairo is the weak link here, at least for my purpose :

- on headless servers, because cairo requirements are linked to too much X11 libs packages on debian/ubuntu, the output is using the SVG format with a dedicated binary built with `--disable-x11 --disable-cairo`.

Fair enough, I'll see if I can fit your requirements!

…

-- :wq ^X^Cy^K^X^C^C^C^C

[zevv]

Implemented in dd4db66

SVG attached, does this look ok to you?

duc-svg.zip

[Daryes]

Tested it with both the svg generation and IM convert and the result is much better, without the need to fiddle with additional parameters.

One last thing I just found, related to having 2 lines for both black and white text.
fill='black' paint-order='stroke' stroke='white' would do the same in a single line, but paint-order doesn't play well with older navigator.

Playing with this, I found that using stroke-opacity for the white line declaration gives a much readable text, and a very close result to the Cairo PNG generator :

<text x='369' y='348' font-size='8pt' stroke='white' stroke-width='3' stroke-opacity='0.5'>
 <tspan x='369' dy='0.0em'>firmware</tspan>
 <tspan x='369' dy='1.2em'>41.8M</tspan>
</text>
<text x='369' y='348' font-size='8pt' fill='black'>
 <tspan x='369' dy='0.0em'>firmware</tspan>
 <tspan x='369' dy='1.2em'>41.8M</tspan>
</text>

The changes are on the white line : +1 for the stroke-width and stroke-opacity='0.5' added.
On the other hand, unless I'm mistaken, stroke-width has no effect for the black line without a color for stroke. I didn't see any difference with Firefox and both IE versions

[zevv]

The changes are +1 for the `stroke-width` and `stroke-opacity` added for the white line. On the other hand, unless I'm mistaken, `stroke-width` has no effect for the black line without a color for stroke. I didn't see one anyway with Firefox and both IE versions

Thanks for testing, added your changes!

…

-- :wq ^X^Cy^K^X^C^C^C^C

[Daryes]

Updated the binary, working fine, thank you.

Btw, could you generate a new release ? the last one is 1 year and a half old.

[zevv]

Quoting Daryes (2018-09-28 10:55:04)

Updated the binary, working fine, thank you. Btw, could you generate a new release ? the last one is 1 year and a half old.

Might be about time, will do.

…

-- :wq ^X^Cy^K^X^C^C^C^C

[zevv]

1.4.4 is released.