mcauser/Fritzing-Part-WeMos-D1-Mini

export for production faulty

ThomDietrich opened this issue · 7 comments

ThomDietrich commented

Exporting a sketch with this part to pdf, will result in misplaced hole positions.

mcauser commented

You're right!
Looks like svg-pdf converter does not handle transform translate and rotate properly.
I use them pretty heavily.
I'll try applying them to the paths points so they can be removed.
Can't use svg symbols. Can't use svg transformations. Boo!!

  • 👍1
ThomDietrich commented

Heyho, did you already look into that? I would like to export an idea for etching in the next few days ;)

mcauser commented

Version that ships with Fritzing 0.9.3b includes a fix.

ThomDietrich commented

Hey that's great to hear! I'm still seeing the problem though... at least with "male below".

I went ahead and merged your current pull request fritzing/fritzing-parts#62 locally. The WeMos group has two parts with three leg options each. Despite there are no distinguishable differences, they seem to come from different files WeMos-D1-mini-female-headers-above_fixed.fzp and WeMos-D1-mini-male-headers-above_fixed.fzp.

Here's what I tested: two parts times three leg options -> Export to pdf
Only 1+2 out of 6 are exported in the right way.
etch_copper_bottom.pdf
etch_silk_top.pdf

Long story short, seems like

  • WeMos-D1-mini-female-headers-above_fixed.fzp can be deleted?
  • "male below" still needs to be fixed!?
  • "female below" or "no headers" may be added?
ThomDietrich commented

Sorry just realized that "male below" was something in the old version still in my temporary folder. WeMos-D1-mini-female-headers-above_fixed.fzp + "male above" is still a problem.

mcauser commented

There was originally 4 variants, each with different header configurations.

  • female headers above
  • male headers above
  • male headers below
  • no headers

There was a bug in the hand crafted .svg, which looked fine in modern browsers where it was tested, but when parsed by the svg parser used in the app, was ignoring newer svg features. The fix was to move some of the nested transformations from the parent <g> down into the children. I was doing this by hand to avoid illustrator and/or inkspace injecting tons of junk.

Looks like when my part was added to fritzing-parts, they did not notice the 4x variants and squished them into 2x, and labelled them "fixed". I'll need to compare their changes with mine to see if I need to add any more fixes.

Is tacking on "_fixed" to the moduleId the best pattern? What if it gets fixed again? And again? Isn't that what the <version> is for?

ThomDietrich commented

Thanks for your work!
I was wondering about the "_fixed" too...
Seems like you'll have to open yet another pull request with all four variants, with the right svgs and without "_fixed" in the name ;)
I'll go ahead an close the issue.