#Librecad move code

Most of its functionality actually doesn't depend that much of SVG, and it could be easily made to export DXF code too, Dan Falck has already made a lot of work in that direction.

On our part, I think there is not much wrong with the Drawing module. But, why would one need that, if they can communicate well together. Embedding librecad into freecad, I don't think it is even remotely possible. There is their new plugin system, which would allow to do things such as fetch data from FreeCAD, and I also tried to interest them into importing svg. I already had a couple of discussions with the librecad people, they would also be quite interested in working better with freecad. And if we would come with precise requirements, some introduced people such as the guy behind told me that the SVG board is very accessible to such technical requests, and would probably be pretty interested. Only indeed the units stuff is pretty uncool, but there might be several ways to overcome that. doc/x?).Īctually if you reduce SVG to its bare-bone components (lines, arcs, rectangles, paths.) it is not that bad as a technical format. for tieing dimensions to model features for automatically updating size), but offers export/inport of regular svg format, and can also export/import dxf for the drawing module (and maybe make it seemlessly as well, like how libreoffice attempts (and occasionally fails) to do with. Personally at this time I support using SVG and FreeCAD having its own drawing module and am willing to continue on with my current work, but will conform to whatever is best in the long run.Īnother thought I just had, maybe its bad: FreeCAD uses a modified svg file format which is basically SVG+some extra stuff (e.g. I think all of them are related to the fact that SVG wasn't really designed from the beginning for technical documents, but am pretty confident that we can overcome these concerns, they have just been nagging at the back of my mind while I have worked on the drawing branch. Although I just had a tought, there are some (many?) javascript SVG editors, perhaps we can embrace and extend one of them. I don't particularily care for Javascript personally. Even AutoCAD manages to mess it up on occasion). I think this means that we will be using some javascript in order to place our text pixel-perfect (which I personally require, have you seen the output of programs like Inventor or SolidWorks? Their text spacing is all wrong and it bothers me to no end. I don't like how you have to access the SVG DOM to get information like the bounding box on text. When printed will an SVG look the same no matter what printer or what renderer you used to print it?ģ. I haven't done any testing of this so my fears may be a little unfounded. It seems that there are 3 common DPIs used, and viewing SVG files through a renderer with a higher DPI makes the SVG smaller than viewing it with a renderer of a lower DPI. I'm not too fond of how different renderers interpret SVG differently. Some renderers handle absolute units a little funky, for example if you try to edit the svg output from the script I have been working on in Inkscape and resave it, Inkscape fuzzies up the numbers.Ģ. I've been coming to terms with this and there is a bit of an elegant workaround to get everything working nicely. Not all tags can use absolute units and so you can get some nasty mixes of user and absolute units. I don't particularily like its handling of absolute units. So unfortunately I think he is quite right to question the SVG direction, and the truth is, as much as I hate DXF, the less than optimal DXF compatibility hinders FreeCAD.ġ.

I do not know if this is a limitation of SVG, or if it's a translation problem. Arcs are not translated as arcs, but rather as bezier curves. I have noticed something about SVG export of FreeCAD drawing sheets. Jriegel mentions that at the time SVG was chosen for the Drawing module he was hoping the SVG format would be extended to include CAD features, and apparently this has not panned out. I believe QCad (and possibly LibreCAD) are the exceptions. DraftSight doesn't (not that I recall), and certainly not AutoCAD nor SolidWorks. But while it is a very good thing, real CAD apps are not able to open SVG. And yes SVG can be opened by many applications, like image viewers and browsers. This means some features are not implemented and workarounds are needed (dimensions for example need many SVG objects). Well from what I understand about the issue, the problem with SVG is, it's a vector graphics file format, not a CAD file format.