![](https://secure.gravatar.com/avatar/6114858d84b0f40cf715f12237ab67a1.jpg?s=120&d=mm&r=g)
On 29 June 2016 at 14:12, Hans Hagen wrote:
On 6/29/2016 12:31 PM, Mojca Miklavec wrote:
Hi,
I want to play with CNC and don't yet have any experience with CAD software (nor the licence for the expensive ones) other than perhaps some Blender, so I decided to try to use the super ugly route with metapost -> svg -> dxf -> g-code for the first time.
I have a few questions.
(1) I love Hans' shortcuts in metafun, but I seem to remember that things like input metafun; or perhaps input mp-tool; used to work, so that I don't have to remember to use mpost -mem=metafun my-drawings.mp when compiling the graphics.
Did the method with "input" ever work (or is it supposed to work)? Now I'm getting a bunch of weird errors. I would love to specify everything in the source file and then just call mpost. If that doesn't work, that's fine, I can still add "-mem=metafun", but ...
input metafun.mpiv ;
How should one properly compile that file then to get the SVG? Using just "mpost something.mp" doesn't work that way.
(2) I guess that using "raw metapost" is the only sane way to generate SVG. If I use metapost inside ConTeXt that's probably not going to work, right?
(3) Is there any way to convince the SVG output mode to generate something like
why not just
\startMPpage whatever you want \stopMPpage
and then use mudraw (mutools) to go from pdf to svg (that's what i do when i need svg)
Given that metapost supports SVG natively I imagined that it would produce a simpler/cleaner output. Thanks a lot for the suggestion, I'll test it. It turned out that the (opensource) tools I used for converting SVG into DXF gives very weird result, so I have to change the other parts of the "toolchain" as well. Nevertheless, the question about whether one could convince MP to output true units in cm/mm/in. Mojca