Re: [Inkscape-devel] Summer of Code: DXF support, and my horrible
On Fri, 8 Jul 2005, Alexandre Prokoudine wrote:
Date: Fri, 8 Jul 2005 21:00:26 +0400 From: Alexandre Prokoudine <alexandre.prokoudine@...400...> To: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Summer of Code: DXF support, and my horrible pessism.
On 7/8/05, Alan Horkan wrote:
Dia already has a library for importing DXF (and there are probably other open source programs with their own custom DXF support and some with more
*cough* dxflib *cough*
That looks somewhat familiar. It is licensed under the GPL.
liberal licensing than others).
So if he chooses to write something new from scratch there is absolutely no point in making it any less than LGPL. I expect the mentors are making sure to keep people on the right track.
generalised and turned into a library that could be shared by Inkscape
and
other applications to share the maintainance burden (or failing that make the new code for Inkscape so that it can be reused by other
applications).
Sure, iirc support for WMF was promised by the same guy.
*cough* libwmf *cough*
That would be pretty sweet alright.
Even if plans change I'm sure there is no shortage of file formats Inkscape would like to support and I'm more optimistic now he will be able to produce something great.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
--__--__--
Here is where I am on the dxf importing so far. A few weeks ago I checked the dxf libraries that are already out there (dime, Qcad (dxflib), blender were specifically mentioned in the proposal) and found all are GPL'd. After a discussion with Jon about licensing I became more aware of the possibility of releasing under several licenses. So I decided to write a dxf importing code using STL containers to hold the various levels of data. I hope that it will be something others can reuse.
I plan to release it at least under the LGPL maybe some other licenses. At lease LGPL.
As far a Dia. I thought about it few days ago but didn't bother to look because I was mostly done with the main parts of dxf reader. After today's posts I looked more closely and it is also GPL'd. Gnuplot will export to dxf so I will check that out in the near future.
BTW what is libwmf?
Matt
On 7/9/05, Matt Squires <matthew.squires@...854...> wrote:
Here is where I am on the dxf importing so far. A few weeks ago I checked the dxf libraries that are already out there (dime, Qcad (dxflib), blender were specifically mentioned in the proposal) and found all are GPL'd. After a discussion with Jon about licensing I became more aware of the possibility of releasing under several licenses. So I decided to write a dxf importing code using STL containers to hold the various levels of data. I hope that it will be something others can reuse.
So you will write yor own library from scratch?
BTW what is libwmf?
A library written specifically for opening Mircosoft Word documents, which contain clipart in this file format.
Alexandre
Alexandre Prokoudine schrieb:
On 7/9/05, Matt Squires <matthew.squires@...854...> wrote:
...
BTW what is libwmf?
WMF means Windows meta file As the name says, this format is used only in Windows. And there is also a more enhanced format: EMF Enhanced Windows Metafile
HTH,
Adib.
On Sat, 2005-07-09 at 15:04 +0400, Alexandre Prokoudine wrote:
On 7/9/05, Matt Squires <matthew.squires@...854...> wrote:
Here is where I am on the dxf importing so far. A few weeks ago I checked the dxf libraries that are already out there (dime, Qcad (dxflib), blender were specifically mentioned in the proposal) and found all are GPL'd. After a discussion with Jon about licensing I became more aware of the possibility of releasing under several licenses. So I decided to write a dxf importing code using STL containers to hold the various levels of data. I hope that it will be something others can reuse.
So you will write yor own library from scratch?
Ok, this worries me a bit. STL is nice as an implementation tool, but why would using it be a feature? Are STL containers to be a visible part of the proposed library's external interface?
Often that's not a good use of STL... especially as it tends to force users of the library away from the prefered STL iterator model and can get very ugly with inlining. It's generally better to provide your own types implementing an STL container/iterator interface on top of a straightfoward base API.
Similarly, when you're using STL containers as part of your internal representation, it's best to keep them encapsulated within objects that provide more domain-specific interfaces. Otherwise when you e.g. decide that your std::list really needs to be a std::vector with a parallel index beside it, you end up having to rewrite all of that object's clients. Typedefs help, but no two containers are 100% interchangable.
Also, using a GPL-licensed library isn't a problem for us. I thought the main goal of the SoC proposal was to add DXF support to Inkscape, not to create a DXF library?
-mental
I think a more critical item than whether or not to use STL containers to map the translations is the issue of what DXF format to support. Autocad has more or less changed DXF formats with each release with many being totally incompatible with previous versions. Most of the Linux programs that support DXF, support it thru R14, which is quite a few years old. Newer versions have included more data items which may or may not be needed. I'm not sure of the DXF exported versions used by some other programs such as Visio, Microstation, etc. Maybe this was addressed in the detailed proposal which I haven't seen, but if not, would be a good early item to address and solicit some feedback from the Inkscape maillist.
Looking forward to seeing this project come about and will be happy to supply some examples and do some testing as it progresses.
MenTaLguY wrote:
On Sat, 2005-07-09 at 15:04 +0400, Alexandre Prokoudine wrote:
On 7/9/05, Matt Squires <matthew.squires@...854...> wrote:
Here is where I am on the dxf importing so far. A few weeks ago I checked the dxf libraries that are already out there (dime, Qcad (dxflib), blender were specifically mentioned in the proposal) and found all are GPL'd. After a discussion with Jon about licensing I became more aware of the possibility of releasing under several licenses. So I decided to write a dxf importing code using STL containers to hold the various levels of data. I hope that it will be something others can reuse.
So you will write yor own library from scratch?
Ok, this worries me a bit. STL is nice as an implementation tool, but why would using it be a feature? Are STL containers to be a visible part of the proposed library's external interface?
Often that's not a good use of STL... especially as it tends to force users of the library away from the prefered STL iterator model and can get very ugly with inlining. It's generally better to provide your own types implementing an STL container/iterator interface on top of a straightfoward base API.
Similarly, when you're using STL containers as part of your internal representation, it's best to keep them encapsulated within objects that provide more domain-specific interfaces. Otherwise when you e.g. decide that your std::list really needs to be a std::vector with a parallel index beside it, you end up having to rewrite all of that object's clients. Typedefs help, but no two containers are 100% interchangable.
Also, using a GPL-licensed library isn't a problem for us. I thought the main goal of the SoC proposal was to add DXF support to Inkscape, not to create a DXF library?
-mental
On 7/10/05, John Taber <jtaber@...480...> wrote:
Looking forward to seeing this project come about and will be happy to supply some examples and do some testing as it progresses.
As for example files, you can count on me as well.
Alexandre
On Sat, 2005-07-09 at 15:04 +0400, Alexandre Prokoudine wrote:
On 7/9/05, Matt Squires <matthew.squires@...854...> wrote:
Here is where I am on the dxf importing so far. A few weeks ago I
checked
the dxf libraries that are already out there (dime, Qcad (dxflib),
blender
were specifically mentioned in the proposal) and found all are GPL'd.
After a discussion with Jon about licensing I became more aware of the
possibility of releasing under several licenses. So I decided to
write
a
dxf importing code using STL containers to hold the various levels of
data. I hope that it will be something others can reuse.
So you will write yor own library from scratch?
Ok, this worries me a bit. STL is nice as an implementation tool, but
why would using it be a feature? Are STL containers to be a visible part of the proposed library's external interface?
Often that's not a good use of STL... especially as it tends to force
users of the library away from the prefered STL iterator model and can get very ugly with inlining. It's generally better to provide your own types implementing an STL container/iterator interface on top of a straightfoward base API.
Similarly, when you're using STL containers as part of your internal
representation, it's best to keep them encapsulated within objects that provide more domain-specific interfaces. Otherwise when you e.g. decide that your std::list really needs to be a std::vector with a parallel index beside it, you end up having to rewrite all of that object's clients. Typedefs help, but no two containers are 100% interchangable.
Also, using a GPL-licensed library isn't a problem for us. I thought
the main goal of the SoC proposal was to add DXF support to Inkscape, not to create a DXF library?
-mental
I agree my SoC is not solely about writing a dxf lib. but (for better and hopefully not worse) I have finished writing the basics of a dxf library and tested it with various files.
On the issue of the STL...I have heard from a few professional programmer friends that the STL is a great tool, but can be abused. As it is now all STL containers are in the private area of the dxf objects, are mostly for storage, and not for directly accessing the extracted dxf info.
My feeling is that different revision issues will come out in testing. Most of the dxf importing I have done in the past with other commercial software has worked no matter the dxf version. I don't do anything crazy in my CAD so I may not notice it. From where I stand Inkscape isn't made to do everthing dxf does. 3D is an easy example of non overlap. So not everything in dxf will be supported in Inkscape, but I hope as much as possible will be.
On another note... what would people rather see; code that is directly tied to Inkscape as a library or a dxf2svg type interpreter? I hope to do both, but what do people want to see?
Thanks for the advice and keeping me on my toes,
Matt
On Sat, 2005-07-09 at 23:35 -0600, Matt Squires wrote:
On another note... what would people rather see; code that is directly tied to Inkscape as a library or a dxf2svg type interpreter? I hope to do both, but what do people want to see?
dxf2svg style script. It is more useful for most projects, and should work in Inkscape just fine through scripting. If you need help writing the .inx file for doing that, just ask.
--Ted
PS - If you want, svg2dxf would be cool too :)
participants (6)
-
Adib Taraben -
Alexandre Prokoudine -
John Taber -
Matt Squires -
MenTaLguY -
Ted Gould