Make compatible with Inkscape about tracespace HOT 17 CLOSED

I wonder if this is related to mcous/svgerber#26 (Also wow it's been nearly a year since that PR and I completely lost track of it...)

It looks like the solution there was to wrap the children of <mask> elements in a <g>; I wonder if the same thing would help here

Edit: Yup; github doesn't like it when you write <something> without the backticks

from tracespace.

I think you accidentally a <g>. Oh man, I totally forgot I found some workarounds for this in svgerber. Looking at the output SVG I can't see an obvious place for the groups though.

from tracespace.

Tried this but didn't work

--- 8bit-mixtape_top.svg    2016-07-25 19:32:17.372072303 +0100
+++ 8bit-mixtape_top_grouped.svg    2016-07-25 19:33:31.912069666 +0100
@@ -23488,15 +23488,21 @@
       <use xlink:href="#S1h34QA7O_pad-8" x="1381.3" y="1386.5"/>
     </g>
     <mask id="Hyn47AQ__top_mech-mask" fill="#000" stroke="#000">
-      <use xlink:href="#Hyn47AQ__top_out"/>
-      <use xlink:href="#Hyn47AQ__top_drl1"/>
+      <g>
+        <use xlink:href="#Hyn47AQ__top_out"/>
+        <use xlink:href="#Hyn47AQ__top_drl1"/>
+      </g>
     </mask>
     <mask id="Hyn47AQ__top_cf-mask" fill="#fff" stroke="#fff">
-      <use xlink:href="#Hyn47AQ__top_sm"/>
+      <g>
+        <use xlink:href="#Hyn47AQ__top_sm"/>
+      </g>
     </mask>
     <mask id="Hyn47AQ__top_sm-mask" fill="#000" stroke="#000">
-      <rect x="168.2" y="102.3" width="3799.7" height="1540.1" fill="#fff"/>
-      <use xlink:href="#Hyn47AQ__top_sm"/>
+      <g>
+        <rect x="168.2" y="102.3" width="3799.7" height="1540.1" fill="#fff"/>
+        <use xlink:href="#Hyn47AQ__top_sm"/>
+      </g>
     </mask>
   </defs>
   <g transform="translate(0,1744.6999999999998) scale(1,-1)">

Posted our examples to https://bugs.launchpad.net/inkscape/+bug/794472

from tracespace.

Oh hang on this might have something to do with a weird CSS thing I did to get the outline to work in the mech-mask (that was not used svgerber)

1. Does it render properly without maskWithOutline?
2. Maybe try [email protected]; It uses a clipPath for the outline instead of sticking it in the same mask as the drill files

from tracespace.

What other code changes are required for the update?

from tracespace.

No breaking API changes, just did a major bump in case clipPath instead of mask broke things

tracespace/pcb-stackup-core#2

from tracespace.

Upgrading core gives:

Turning off maskWithOutline gives:

from tracespace.

Grouping masks as above gets us the drills

from tracespace.

Hey look, progress!

If I didn't know any better, it looks like the styles aren't being applied. Comparing to svgerber, pcb-stackup does two things differently:

1. pcb-stackup places the <style> node inside of <defs> instead of at the same level as
2. pcb-stackup does not add type="text/css" to the style node

from tracespace.

Did some more investigating. Removing the !CDATA stuff fixes it.

Full diff:

--- before.svg	2016-12-29 22:01:40.414884129 +0000
+++ after.svg	2016-12-29 22:00:43.998569898 +0000
@@ -1,13 +1,13 @@
 <?xml version="1.0"?>
 <svg xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" id="HkqwHZQHg_top" version="1.1" stroke-linecap="round" stroke-linejoin="round" stroke-width="0" fill-rule="evenodd" clip-rule="evenodd" viewBox="168.2 102.3 3799.7 1540.1" width="3.7996999999999996in" height="1.5400999999999998in">
   <defs>
-    <style>/* <![CDATA[ */.HkqwHZQHg_fr4 {color: #666;}
+    <style>.HkqwHZQHg_fr4 {color: #666;}
 .HkqwHZQHg_cu {color: #ccc;}
 .HkqwHZQHg_cf {color: #c93;}
 .HkqwHZQHg_sm {color: rgba(00, 66, 00, 0.75);}
 .HkqwHZQHg_ss {color: #fff;}
 .HkqwHZQHg_sp {color: #999;}
-.HkqwHZQHg_out {color: #000;}/* ]]> */</style>
+.HkqwHZQHg_out {color: #000;}</style>
     <rect x="-45" y="-45" width="90" height="90" id="BJu5vr-QHx_pad-12"/>
     <polygon points="36.99992,15.32587 15.32587,36.99992 -15.32587,36.99992 -36.99992,15.32587 -36.99992,-15.32587 -15.32587,-36.99992 15.32587,-36.99992 36.99992,-15.32587" id="BJu5vr-QHx_pad-13"/>
     <rect x="-19.7" y="-21.65" width="39.4" height="43.3" id="BJu5vr-QHx_pad-14"/>
@@ -35784,15 +35784,21 @@
     </clipPath>
     <mask id="HkqwHZQHg_top_mech-mask" fill="#000" stroke="#000">
+      <g>
       <rect x="168.2" y="102.3" width="3799.7" height="1540.1" fill="#fff"/>
       <use xlink:href="#HkqwHZQHg_top_drl1"/>
+      </g>
     </mask>
     <mask id="HkqwHZQHg_top_cf-mask" fill="#fff" stroke="#fff">
+      <g>
       <use xlink:href="#HkqwHZQHg_top_sm"/>
+      </g>
     </mask>
     <mask id="HkqwHZQHg_top_sm-mask" fill="#000" stroke="#000">
+      <g>
       <rect x="168.2" y="102.3" width="3799.7" height="1540.1" fill="#fff"/>
       <use xlink:href="#HkqwHZQHg_top_sm"/>
+      </g>
     </mask>
   </defs>
   <g transform="translate(0,1744.6999999999998) scale(1,-1)">

How do you want to proceed on this?

For me it would be useful as svg2png is letting me down (well, PhantomJS or QtWebkit or whatever is -- it's crashing on some SVGs) and using Inkscape without GUI seems like a solid alternative.

EDIT: Wait a minute the styles say this board should be green! So they are still not being applied properly.

from tracespace.

Ok, so it doesn't like rgba either.

--- before.svg	2016-12-30 00:25:30.285613610 +0000
+++ after.svg	2016-12-30 00:30:24.639262394 +0000
@@ -4,7 +4,7 @@
     <style>.H1RI-FGXHe_fr4 {fill: #666;}
 .H1RI-FGXHe_cu {color: #ccc;}
 .H1RI-FGXHe_cf {color: #c93;}
-.H1RI-FGXHe_sm {color: rgba(00, 66, 00, 0.75);}
+.H1RI-FGXHe_sm {color: #004200; opacity:0.75;}
 .H1RI-FGXHe_ss {color: #fff;}
 .H1RI-FGXHe_sp {color: #999;}
 .H1RI-FGXHe_out {color: #000;}</style>

(switched to arduino because the mixtape silkscreen is a pain and slows everything down)

• Solder finish isn't showing up
• Solder mask isn't masked in all the right places yet

EDIT: Seems to me only circular and hexagonal pads are being cleared of solder mask, hard to tell from just one board though.

from tracespace.

Interesting! The CDATA is there to say that the stuff inside the CDATA shouldn't be treated as XML (https://stackoverflow.com/questions/2784183/what-does-cdata-in-xml-mean) so we can use special characters (https://stackoverflow.com/questions/21758345/what-are-the-official-xml-reserved-characters). It looks like we don't actually use any of those special characters, so we can probably ditch the CDATA as long as we protect / escape whatever's input as the color options.

I don't see any appreciable difference color: rgba(... vs color: ...; opacity: .... Perhaps we should parse the the strings in color and write them as a base format (e.g. color and opacity). This would also take care of our special characters problem from above.

As for the finish and the mask stuff, the SVG output relies pretty heavily on <use> tags, and nesting <use> tags (e.g. a use for all the individual soldermask "pads", and then a use for the whole soldermask layer) can cause all sorts of problems. I wonder if that's what we're encountering here with InkScape and svg2png... There's def some potential for reducing the number of uses we do in gerber-to-svg

from tracespace.

Just using gerber-to-svg the solder mask renders fine in Inkscape. I guess this means something is going wrong with the masking of it?

from tracespace.

Removing fill attributes in the solder mask declaration gives us the surface mount pads.

.

I noticed there are loads of different circles and polygons with the same IDs, e.g ryygLWKGmrl_pad-18. How does it even know which one you are talking about in the use tags?

from tracespace.

Adding stroke=#000 to the soldermask paths seems like an improvement in Inkscape.

But messes with the solder finish in browsers.

from tracespace.

Alright! I've got it!

I made a git repo to track all the changes required. Looks like these could all be done in pcb-stackup-core right? Removing fill-attributes in the sm declaration is not needed, which was the only change that would have had to be done in s2g I guess.

EDIT: Are you ok with depending on color-string in core for the color parsing? Bug was already opened with Inkscape in 2015, so doesn't seem likely to be fixed soon. Was just playing around with it and it would be something like:

function convert(v) { 
    var rgba = colorString.get.rgb(v)
    var color = colorString.to.hex(rgba)
    return 'color:' + color + '; opacity:' + rgba[3] + ';'
}

We lose support for hsl and hwb color declarations though I believe as color-string doesn't convert them. We could try and convert rgba only, and leave the rest alone. People can choose to be Inkscape incompatible if they want to use different color spaces I guess?

from tracespace.

Closed by updating core with #46

from tracespace.