Difference between revisions of "SOC Accepted Proposals"
(Categorization) |
NeoPhyte Rep (talk | contribs) m (→SOC Accepted Proposals: Expanded OCAL Acronym) |
||
Line 5: | Line 5: | ||
* [http://www.csse.monash.edu.au/~mwybrow/soc-proposal.txt Connectors] - [http://code.samediff.net/ Michael Wybrow] [[UsingTheConnectorTool]] | * [http://www.csse.monash.edu.au/~mwybrow/soc-proposal.txt Connectors] - [http://code.samediff.net/ Michael Wybrow] [[UsingTheConnectorTool]] | ||
* [http://www.rose-hulman.edu/~yipdw/inkscape-proposal.txt Inkboard] - David Yip ([[InkboardIntegrationSchedule]]) ([[Inkboard2.0]]) | * [http://www.rose-hulman.edu/~yipdw/inkscape-proposal.txt Inkboard] - David Yip ([[InkboardIntegrationSchedule]]) ([[Inkboard2.0]]) | ||
* [https://developer.berlios.de/docman/display_doc.php?docid=934&group_id=4098 OCAL Interface] - [https://developer.berlios.de/users/gsteff/ Greg Steffensen] (project being developed at [http://developer.berlios.de/projects/ocalhelper Berlios]) | * [https://developer.berlios.de/docman/display_doc.php?docid=934&group_id=4098 Open Clip Art Library (OCAL) Interface] - [https://developer.berlios.de/users/gsteff/ Greg Steffensen] (project being developed at [http://developer.berlios.de/projects/ocalhelper Berlios]) | ||
* DXF Import / Export (proposal below) - Matthew Squires | * DXF Import / Export (proposal below) - Matthew Squires | ||
Latest revision as of 16:45, 2 December 2011
SOC Accepted Proposals
Four proposals were accepted.
- Connectors - Michael Wybrow UsingTheConnectorTool
- Inkboard - David Yip (InkboardIntegrationSchedule) (Inkboard2.0)
- Open Clip Art Library (OCAL) Interface - Greg Steffensen (project being developed at Berlios)
- DXF Import / Export (proposal below) - Matthew Squires
DXF import/export
The proposal pretty much follows the Perl funding outline that was linked on the SOC website.
Name: Matthew Squires
Project Title: Creation of a library for the import/export of dxf in Inkscape
Benefits to Inkscape
A library for importing/exporting dxf files would make Inkscape a more flexible piece of software especially for those that create technical drawings. For example, I have used Macromedia Freehand to import dxf technical drawings so I could add artistic elements for papers and presentations. Directly importing and exporting dxf in Inkscape would make Inkscape a more attractive piece of software for those that already have CAD drawings but would like to make them "presentable."
Synopsis
I will create a library that will import/export data to/from Inkscape from/to the dxf format. This library will directly import all of the basic properties common to the dxf format and Inkscape (e.g. lines and layers). Objects that do not directly convert (e.g. spirals) will be supported by using extra information to properly complete the translation. It should be assumed that any 3D data contained in the dxf will be flattened.
Deliverables
The conversion functions will be made to incorporate into Inkscape via a library. I will also include documentation of the library including examples. I would like to create a svg2dxf and a dxf2svg directly from the code, but I do not want to commit to delivery of stand-alone programs in the time allotted.
Project Details
I will create a library that will directly convert all of the directly convertible information between a dxf/svg. That includes but is not limited to: lines, splines, layers, and text. All 3D information will be flattened but I would imagine that in the future a simple method for translating elevation to layers could be implemented, but not this summer. Because dxf does not include units this information will need to be supplied for all conversions.
Items that require additional information will be converted if the information is given. This is done in other programs (i.e. FlexPDE) that require more information than dxf can provide. An example would be importing a spiral from dxf into svg. Additional tags can be applied to the dxf to supply the additional information (e.g. revolution) to create a spiral in Inkscape. Some items that would be supported in dxf import are spirals, stars, color, fills, and text on a path. On the other hand a spiral can be exported to dxf as a series of splines. The user can set the export resolution, or use the default resolution. Some items that would be exported to dxf are spirals and stars. I would like to work on exporting text on a path, but at this time I won’t promise that it will be functional until I understand better how Inkscape performs this task.
Project Schedule
First I will take a few days to better understand the Inkscape file format. Then I will break the schedule into two pieces: svg->dxf and dxf->svg. For the dxf->svg I estimate that the directly convertible code (DCC) can be written in a 2-3 days, the non-direct conversion code (NDCC) in 3-4. I think the svg->dxf DCC will take 3-4 days. The NDCC is a little more complicated because extra information will need to be processed, so I am going to estimate about a week for that code. The total is about 2.5 weeks. As mentioned on the Inkscape wiki all projects take about pi times longer to complete, so the completion of this code should be reasonable in a summer. The documentation code should be written at the same time functions are written. Example programs will be developed along the way as result of testing.
Bio
I am a physics Phd candidate at the University of Colorado and I have recently been using Inkscape to create figures for papers and presentations. I have been coding in C++ for about 5 years. I am self-taught in C++, but have some formal education in other languages. I would say I am a proficient programmer and can create good code. I have mostly worked on ing magnetic fields, but part of my code reads some basic information from dxf files to define the regions of interest (ROI). I am familiar with the dxf standard and what it takes to read dxf. I have looked at open source dxf libraries, specifically dime and QCad. I also recently found Blender reads dxf files. I would have no problem pulling code from those sources.
I am familiar with the SVG format, and actually looked at reading ROI information from SVG's but for some reason several years ago chose dxf instead (probably because at the time I found better CAD editors). I have also used a variant of XML in LabVIEW to control the parameters of my experiment. A lab mate performed most of the coding, but I have a working knowledge of XML. I think there is open source code for reading XML tags, so I would like to find some code that already reads the XML tags and information from a file to hurry the project along.
ACI to RGB conversion
ACI stands for AutoCAD color index. It is a table of codes which describe color in DXF files. Here is some code to convert ACI to RGB, which I've written for my simple DXF reader. Resulting R, G and B values are 8-bit, in range 0-255. You can create a macro RGB(R,G,B) to convert it to proper colorspace values. I hope it can help a bit. The code is released under GPL.
P.S. I know it is not the best place for pasting a code. Please remove it from this place, when it is no more useful or if it can be placed somewhere else.
float aci_to_rgb(int aci) { aci = abs(aci); // hidden layers have negative color values if (aci<10 || aci>249) // values of these ranges are special colors { switch (aci) { case 1: return RGB(255,0,0); // basic colors case 2: return RGB(255,255,0); case 3: return RGB(0,255,0); case 4: return RGB(0,255,255); case 5: return RGB(0,0,255); case 6: return RGB(255,0,255); case 7: return RGB(255,255,255); case 8: return RGB(128,128,128); case 9: return RGB(192,192,192); case 250: return RGB(51,51,51); // grey shades case 251: return RGB(91,91,91); case 252: return RGB(132,132,132); case 253: return RGB(173,173,173); case 254: return RGB(214,214,214); case 255: return RGB(255,255,255); case 256: // "by layer" // Here you should decide how to handle "by layer" logical color. // Maybe it is a good idea to return a value like -1. // The outer code will find what is the color of the layer which // this entity belongs to. return -1; } } // for all the rest of ACI codes float H,S,L, R,G,B; int remainder = aci % 10; H = 1.5f * (aci - remainder - 10); // hue in range 0-360 S = ((aci % 2) ? 0.5f : 1.0f); // odd colors have 50% of saturation, even - 100% // set lighteness, the last digit of aci code stands for this if (reminder == 0 || reminder == 1) L = 1.0f; if (reminder == 2 || reminder == 3) L = 0.8f; if (reminder == 4 || reminder == 5) L = 0.6f; if (reminder == 6 || reminder == 7) L = 0.5f; if (reminder == 8 || reminder == 9) L = 0.3f; // here we have H,S,L set already // let's convert it to RGB, first without consideration of S and L if (H<=120) { R = (120-H)/60; G = H/60; B = 0; } if (H>120 && H<=240) { R = 0; G = (240-H)/60; B = (H-120)/60; } if (H>240 && H<=360) { R = (H-240)/60; G = 0; B = (360-H)/60; } R = min(R, 1); G = min(G, 1); B = min(B, 1); // influence of S and L float max_value = max(R,max(G,B)); R = (max_value-S*(max_value-R)) * L * 255; G = (max_value-S*(max_value-G)) * L * 255; B = (max_value-S*(max_value-B)) * L * 255; return RGB(R,G,B); }