Blank/image offset SVG files when converting Office VSS files

[mans0954]

Some symbols from the "Office Symbols" stencil are not converted correctly.

Steps to reproduce:

Download stencils from https://www.microsoft.com/en-gb/download/details.aspx?id=35772

Run

vss2svg-conv -i ./2012_Stencil_121412.vss -o ./out/

Most of the files are converted, but some files have blank images e.g.

Active_Directory_Federation_Services_Proxy.svg
Address_Book_Policies.svg
Address_Book_Store.svg

etc.

These display correctly in Inkscape using libvisio, so I don'ŧ think this is a libvisio issue.

Thanks.

Christopher Hoskin

[mans0954]

Sorry, looking into this a bit more, the SVG aren't blank, but they're offset considerably from the centre. Opening them up in Inkscape, doing "View/Zoom/Drawing" reveals the previously hidden image. Then setting the X and Y co-ordinates to 0 and saving fixes.

[kakwa]

I've looked a little, it looks like a libvisio bug.

For the Archive icons in 2012_Stencil_121412.vss file:

SVG generated by libvisio (vss2html)

<svg:svg version="1.1" xmlns:svg="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="42.7500" height="58.5000" >
<svg:path d=" 
M-576.0000,58.5000
L-533.2500,58.5000
L-533.2500,0.0000
L-576.0000,0.0000
L-576.0000,58.5000
Z" 
style="fill-rule: evenodd; fill: #ffffff; "/>
<svg:path d=" 
M-574.5000,57.0000
L-534.7500,57.0000
L-534.7500,1.5000
L-574.5000,1.5000
L-574.5000,57.0000
Z" 
style="fill-rule: evenodd; fill: #808080; "/>
<svg:path d=" 
M-573.0000,55.5000
L-536.2500,55.5000
L-536.2500,3.0000
L-573.0000,3.0000
L-573.0000,55.5000
Z" 
style="fill-rule: evenodd; fill: #ffffff; "/>
<svg:path d=" 
M-569.2500,51.7500
L-540.0000,51.7500
L-540.0000,31.5000
L-569.2500,31.5000
L-569.2500,51.7500
Z" 
style="fill-rule: evenodd; fill: #808080; "/>
<svg:path d=" 
M-567.7500,50.2500
L-541.5000,50.2500
L-541.5000,33.0000
L-567.7500,33.0000
L-567.7500,50.2500
Z" 
style="fill-rule: evenodd; fill: #ffffff; "/>
<svg:path d=" 
M-555.7500,47.2500
L-553.5000,47.2500
L-553.5000,45.0000
L-555.7500,45.0000
L-555.7500,47.2500
Z" 
style="fill-rule: evenodd; fill: #808080; "/>
<svg:path d=" 
M-561.0000,42.7500
L-548.2500,42.7500
L-548.2500,41.2500
L-561.0000,41.2500
L-561.0000,42.7500
Z" 
style="fill-rule: evenodd; fill: #808080; "/>
<svg:path d=" 
M-569.2500,27.7500
L-540.0000,27.7500
L-540.0000,7.5000
L-569.2500,7.5000
L-569.2500,27.7500
Z" 
style="fill-rule: evenodd; fill: #808080; "/>
<svg:path d=" 
M-567.7500,26.2500
L-541.5000,26.2500
L-541.5000,9.0000
L-567.7500,9.0000
L-567.7500,26.2500
Z" 
style="fill-rule: evenodd; fill: #ffffff; "/>
<svg:path d=" 
M-555.7500,23.2500
L-553.5000,23.2500
L-553.5000,21.0000
L-555.7500,21.0000
L-555.7500,23.2500
Z" 
style="fill-rule: evenodd; fill: #808080; "/>
<svg:path d=" 
M-561.0000,18.7500
L-548.2500,18.7500
L-548.2500,17.2500
L-561.0000,17.2500
L-561.0000,18.7500
Z" 
style="fill-rule: evenodd; fill: #808080; "/>
</svg:svg>

SVG generated by libvisio2svg:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="42.7500000000" height="58.5000000000">
  <title><![CDATA[Archive]]></title>
  <g transform=" scale(1.000000) ">
    <path xmlns="http://www.w3.org/2000/svg" d="  M-576.0000,58.5000 L-533.2500,58.5000 L-533.2500,0.0000 L-576.0000,0.0000 L-576.0000,58.5000 Z" style="fill-rule: evenodd; fill: #ffffff; "/>
    <path xmlns="http://www.w3.org/2000/svg" d="  M-574.5000,57.0000 L-534.7500,57.0000 L-534.7500,1.5000 L-574.5000,1.5000 L-574.5000,57.0000 Z" style="fill-rule: evenodd; fill: #808080; "/>
    <path xmlns="http://www.w3.org/2000/svg" d="  M-573.0000,55.5000 L-536.2500,55.5000 L-536.2500,3.0000 L-573.0000,3.0000 L-573.0000,55.5000 Z" style="fill-rule: evenodd; fill: #ffffff; "/>
    <path xmlns="http://www.w3.org/2000/svg" d="  M-569.2500,51.7500 L-540.0000,51.7500 L-540.0000,31.5000 L-569.2500,31.5000 L-569.2500,51.7500 Z" style="fill-rule: evenodd; fill: #808080; "/>
    <path xmlns="http://www.w3.org/2000/svg" d="  M-567.7500,50.2500 L-541.5000,50.2500 L-541.5000,33.0000 L-567.7500,33.0000 L-567.7500,50.2500 Z" style="fill-rule: evenodd; fill: #ffffff; "/>
    <path xmlns="http://www.w3.org/2000/svg" d="  M-555.7500,47.2500 L-553.5000,47.2500 L-553.5000,45.0000 L-555.7500,45.0000 L-555.7500,47.2500 Z" style="fill-rule: evenodd; fill: #808080; "/>
    <path xmlns="http://www.w3.org/2000/svg" d="  M-561.0000,42.7500 L-548.2500,42.7500 L-548.2500,41.2500 L-561.0000,41.2500 L-561.0000,42.7500 Z" style="fill-rule: evenodd; fill: #808080; "/>
    <path xmlns="http://www.w3.org/2000/svg" d="  M-569.2500,27.7500 L-540.0000,27.7500 L-540.0000,7.5000 L-569.2500,7.5000 L-569.2500,27.7500 Z" style="fill-rule: evenodd; fill: #808080; "/>
    <path xmlns="http://www.w3.org/2000/svg" d="  M-567.7500,26.2500 L-541.5000,26.2500 L-541.5000,9.0000 L-567.7500,9.0000 L-567.7500,26.2500 Z" style="fill-rule: evenodd; fill: #ffffff; "/>
    <path xmlns="http://www.w3.org/2000/svg" d="  M-555.7500,23.2500 L-553.5000,23.2500 L-553.5000,21.0000 L-555.7500,21.0000 L-555.7500,23.2500 Z" style="fill-rule: evenodd; fill: #808080; "/>
    <path xmlns="http://www.w3.org/2000/svg" d="  M-561.0000,18.7500 L-548.2500,18.7500 L-548.2500,17.2500 L-561.0000,17.2500 L-561.0000,18.7500 Z" style="fill-rule: evenodd; fill: #808080; "/>
    <!--converted by libvisio2svg-->
  </g>
</svg>

They are mostly the same (except for a little formatting (less new lines), <title><![CDATA[Archive]]></title> and the <g transform=" scale(1.000000) ">, those are doing nothing in this case)

The issue is the weird -5xx x coordinate like L-561.0000,18.7500, I suspect either a missing "translate" record handling or mistakes in the origin computation in libvisio.

It looks a lot like the issue I've open recently in libvisio bug tracker:
https://bugs.documentfoundation.org/show_bug.cgi?id=106344

[benschweizer]

Quickfix for the particular icons:
sed -i 's/<g transform=" scale(4.500000) ">/<g transform="translate(-4604,3028) scale(4)">/' *svg

[b-keller]

Hi,

There is a new tracking for this bug (Bug 106344)
https://bugs.documentfoundation.org/show_bug.cgi?id=106344#c13
Do you plane to update libvisio ?

Thx

[kakwa]

No, simply because I use whichever libvisio is provided by the distribution. There is no version pinning on libvisio.

Testing with the latest libvisio version (0.1.6-1) the issue is still present.

I will update the document foundation ticket accordingly.