while fixing a SVG export issue for techDraw I noticed that some SVG files have program-dependent (and thus not clean) code in it. These are traces of the programs Sodipodi and Inkscape, like e.g. this line:
inkscape:export-filename="/home/yorik/PartDesign_Groove.png
This is unnecessary and FC should not use program-dependent code in the SVG but use instead plain SVG strictly following the SVG specification.
This PR transforms the few affected SVGs to a plain version.
The OpenSCAD Workbench crashes on open on macOS with error
"a bytes-like object is required, not 'str'", due to python 2 to
python 3 incompatibility. This is me implementing the fix described by
oapa at
https://forum.freecadweb.org/viewtopic.php?t=35384#p311908 (with an
untested attempt to make it also still run with python 2).
Found via `codespell -q 3 -I ../fc-word-whitelist.txt -S ./.git,*.po,*.ts,./ChangeLog.txt,./src/3rdParty,./src/Mod/Assembly/App/opendcm,./src/CXX,./src/zipios++,./src/Base/swig*`
This happens when the git version of OpenSCAD is installed (which uses YYYYMMDD), instead of
the latest released version (from 2015, which uses YYYY.MM.DD).
In CMake 3.0 the policy CMP0050 was introduced where it could be set to OLD to keep this behaviour while for NEW an error was raised.
Since CMake 3.5.2 a warning comes up when using the OLD behaviour and that it will be removed in a future version.
In FreeCAD we switched to the new behaviour now and removed the SOURCE signature from add_custom_command which affects the macros
fc_copy_sources, fc_target_copy_resource and fc_target_copy_resource_flat and their usage.
It's not possible any more to add files to a target by using the macros. Now a file must be added to the target before using the macros.
This commit fixes it for Arch, Draft, OpenSCAD, Material, Plot and Ship
- by default, OpenScad represents circles from
dxf files as octogons. This fix provides
access to the OpenScad variable "$fn" which
controls the number of polygon sides.
