April 2008 - Inkscape Devel - Inkscape Mailman

Win32 Builds with Cairo-1.6.2
by Bob Jamison 11 Apr '08

11 Apr '08

Hi, all, I don't know if everyone noticed, but Carl Worth and his troupe have released Cairo-1.6.2. (Yaay!) I've gotten out of the habit of posting every new thing in the Inkscape/win32 world, but I think that this version of Cairo is a notable milestone. I uploaded another lib bundle with it here: http://inkscape.modevia.com/win32libs/devlibs-2.12-080411.7z ...and started making builds with it already. Here is the first: http://inkscape.modevia.com/win32/Inkscape0804111855.7z Also, note that there is a new "fulldbg" build there. These are the builds I make separately with -g turned on for everything. Thanks , Carl! ishmal (bob)

4 3

Autopackage for 0.46
by Jan Niklas Hasse 10 Apr '08

10 Apr '08

Hi everyone, Some guys have asked in the forum about an autopackage for 0.46. I think the developer mailing list seems to be a better place to ask that. As I think no one has done it yet, I'm trying to ask now, because I'm interested in an autopackage for 0.46, too. :) Here are the forum threads: http://www.inkscapeforum.com/viewtopic.php?f=22&t=799 http://www.inkscapeforum.com/viewtopic.php?f=22&t=784 http://www.inkscapeforum.com/viewtopic.php?f=22&t=766

2 1

Clarification of supported image formats
by microUgly 10 Apr '08

10 Apr '08

There's a been a few people coming to inkscapeforum.com due to confusion over Inkscapes suggested support for various file formats and I was hoping someone might be able to clarify it for me. Some release announcements for 0.46 says that it supports importing EPS files, and on the Wiki it's states it can "natively" save as AI - both appear to be incorrect for the Windows platform, and it looks like it might be true under Linux only through the use of third-party software. Is it safe to say that if filetype is not listed in the save/open dialog then it's not 'natively' supported, for the respective operation, despite what is stated on some sources? Thanks -- View this message in context: http://www.nabble.com/Clarification-of-supported-image-formats-tp16533912p1… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

5 13

lib poppler dependency for pdf support
by MilesTogoe 10 Apr '08

10 Apr '08

Since pdf import is a key feature of .46, perhaps the lib-poppler-dev dependency should be noted in the Readme for compiling from source. Without it, Inkscape will still compile, and even show cairo-poppler okay in the config log but pdf import support won't be there (well at least in Gutsy anyway).

3 2

constructor initializing problem
by unknown＠example.com 09 Apr '08

09 Apr '08

Hi all, I have a strange problem with initializing the bool called "concatenate_before_pwd2" in my Effect class. I want to set it to 'false' per default, so in the constructor of Effect. A derived class LPEBendPath needs it to be true so does that in the constructor. I think this bool should now evaluate to true for the rest of LPEBendPath's life. But for some reason... it doesn't! Thanks for enlightening me. Johan Relevant excerpts from the code follow below. Attached the complete files. Effect::Effect(LivePathEffectObject *lpeobject) : concatenate_before_pwd2(false) { lpeobj = lpeobject; oncanvasedit_it = 0; } class LPEBendPath : public Effect, LivePathEffect_group_bbox { LPEBendPath::LPEBendPath(LivePathEffectObject *lpeobject) : Effect(lpeobject), ... { ... concatenate_before_pwd2 = true; } Effect* Effect::New(EffectType lpenr, LivePathEffectObject *lpeobj) { Effect* neweffect = NULL; ... case BEND_PATH: neweffect = static_cast<Effect*> ( new LPEBendPath(lpeobj) ); break; ... return neweffect; } std::vector<Geom::Path> Effect::doEffect_path (std::vector<Geom::Path> & path_in) { std::vector<Geom::Path> path_out; if ( !concatenate_before_pwd2 ) { // this expression for some reason is true for LPEBendPath ! ... }

2 3

LPE internals - conversions
by unknown＠example.com 09 Apr '08

09 Apr '08

Hello all, Currently, LPEs have a 'doEffect' chain: basically a stack of functions that are called sequentially that convert from Inkscape's path type, to several 2geom types in steps. An LPE defines a doEffect within this chain to override the default behavior (pass on to next down the stack). The problem is this: Inkscape's paths can be discontinuous, meaning for the user that visually they are 2 separate paths. The LPE doeffect chain now converts it to one path. This means that for example lpe-PatternAlongPath will see discontinuous paths as a single path (thanks JFB!), so when applying a pattern (copy modus: single stretched) the pattern is applied along the whole path, ignoring the discontinuity. 1. Take two separate paths and combine them into one (ctrl+k) 2. draw a circle, convert to path, copy it 3. apply lpe-Pattern Along Path to (1) and paste the circle as pattern 4. the result will be two circle halves. where actually I would have expected to see two circles, since it looks like the original path is 2 paths. This is undesired behavior I think. Note that e.g. lpe-Gear also suffers from this: it just seems to ignore the second path. Do people consider this as a bug, or as a feature? The solution is to break the path into separate parts, group it, and apply an LPE on the group... but... especially with the lpe stacking, this is no longer possible and we do need to consider what lpe should do with discontinuous paths. I have made a fix, which I will probably apply to the whole doEffect chain. But perhaps people do not see this as a bug in PatternAlongPath, which means I will have to add a checkbox for the new behavior.... Basically, instead of concatinating all paths, run the effect multiple times on the differnt paths: Technical, instead of: std::vector<Path> doEffect_path (std::vector<Path> & path_in) { Piecewise<D2<SBasis> > pwd2_in; for (unsigned int i=0; i < path_in.size(); i++) { pwd2_in.concat( path_in[i].toPwSb() ); } Piecewise<Geom::D2<Geom::SBasis> > pwd2_out = doEffect_pwd2(pwd2_in); std::vector<Path> path_out = path_from_piecewise( pwd2_out, LPE_CONVERSION_TOLERANCE); return path_out; } I want to change it to: std::vector<Path> doEffect_path (std::vector<Path> & path_in) { std::vector<Path> path_out; for (unsigned int i=0; i < path_in.size(); i++) { Piecewise<Geom::D2<Geom::SBasis> > pwd2_in = path_in[i].toPwSb(); Piecewise<Geom::D2<Geom::SBasis> > pwd2_out = doEffect_pwd2(pwd2_in); std::vector<Path> path = path_from_piecewise( pwd2_out, LPE_CONVERSION_TOLERANCE); for (unsigned int j=0; j < path.size(); j++) { path_out.push_back(path[j]); } } return path_out; } Note that: Piecewise<D2<SBasis> > doEffect_pwd2 (Piecewise<D2<SBasis> > & pwd2_in) ==> this one does the actual effect Thanks for your consideration. I'll make sure this will not break the other effects. Regards, Johan

2 3

Re: [Inkscape-devel] [Bug 174720] Re: currentColor in style= is misinterpreted
by Jasper van de Gronde 09 Apr '08

09 Apr '08

bulia byak wrote: > On Tue, Apr 8, 2008 at 7:56 AM, Martin von Gagern > <martin.vgagern@...240...> wrote: > ... >> Another interesting way to avoid these issues might be some more >> extensive verification. An invalid style attribute like the one above >> certainly should never have been generated by inkscape itself. If you >> were to implement appropriate error checking code in sp_style_read_*, >> you could enable it while processing internally generated attributes. >> You might wish to disable it for file reading or attributes entered in >> the XML editor, or even better, you might wish to handle errors there >> differently. So perhaps you want a format error listener interface, and >> pass instance of that along. Quite a bit of work, but maybe worthwhile, >> as it would also help identify SVG documents in the wild that aren't >> fully understood by inkscape. > > I don't think we want to overburden Inkscape itself with checks over > and above those prescribed by the SVG/CSS standard. But an external > consistency checker for Inkscape-produced files might be a great > addition to the testing project. Instead of making sure that Inkscape knows how to parse/serialize CSS properly, wouldn't it be better to simply use libcroco for all of this? At first glance it seems to provide plenty of functionality.

2 1

BZR EOL
by Aaron Spike 09 Apr '08

09 Apr '08

There is some activity in the bzr community right now about EOL handling. If you are interested, see the thread at: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/39636… Couldn't hurt to voice our concerns there. Aaron Spike

1 0

uniconv conversion from .cdr on Windows XP
by Alvin Penner 07 Apr '08

07 Apr '08

has anyone been able to successfully use the python utility uniconv to do a conversion on a win32 machine from .cdr to .svg, preferably from a DOS prompt, since that is easier? I can do a successful conversion from .svg to .svg in DOS, but that is not very interesting. When I try either a .cdr to .svg, or .wmf to .svg, I get the following errors http://www.nabble.com/file/p16517282/uniconv.txt uniconv.txt -- View this message in context: http://www.nabble.com/uniconv-conversion-from-.cdr-on-Windows-XP-tp16517282… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

1 1

GSoC Tech Drawing proposal (and a question/further suggestion)
by Maximilian Albert 07 Apr '08

07 Apr '08

Hi all, here is finally my application for this year's GSoC (still up to minor modifications and slight abridgement; please also note that the website for the proposal is not updated yet, I will do this tomorrow or on Monday). If you have any comments, suggestions or criticism, I'd love to hear them. Apart from many of the suggestions mentioned on this list (thanks again to everyone, the resonance was overwhelming!), I also included a new idea which struck me tonight but could turn out quite involved (or else rather easy if I'm lucky) so I thought I'd ask whether it is appropriate for inclusion. Namely, since LPEs are intended to be used as the basis for further tools (or for refactoring existing ones), the need for integrating LPE parameter controls into toolbars is likely to arise sooner or later. Since I need to add a toolbar for the new Tech Drawing tool anyway, I was wondering whether I could set up a general framework that allows LPE parameter controls to be automatically added to certain toolbars and to be activated/toggled visible when the LPE is used by the respective tools. This would eliminate the need to recode toolbar controls over and over again when tools want to make use of functionality provided by a LPE. It would work similarly to how controls are currently added to the various LPE dialogs (but with some extended functionality). I haven't thought this through yet but at first sight it doesn't seem _too_ difficult to do (since much of Johan's code could probably be reused), yet very convenient and highly desirable, at least from my biased point of view :). Or is it complete nonsense? What do you think? Max === GSoC Proposal: Tech Drawing Abilities for Inkscape === == Abstract == While Inkscape is very powerful as vector graphics editor, it is mainly suited for artists. Technical drawings and geometric constructions are possible, but they are cumbersome to do and difficult to edit later on, especially if mutual relations like "is parallel to", "passes through", etc., are to be retained. Already a limitation for artistic work, this is a showstopper for people like architects or scientific researchers who wish to use Inkscape for precise drawings in construction plans or academic posters. I propose a new Tech Drawing tool, combined with a number of related enhancements, that will establish Inkscape as a mature tool for these purposes and further strenghten its status as the leading open source vector graphics editor. == Deliverables and goals == (1) New "Tech Drawing" tool for geometric constructions (2) UI framework for on-canvas and toolbar adaption of LPE parameters (see below) (3) Refactoring of code obsoleted by this work (4) Documentation for the new frameworks (5) As time permits, implementation of more advanced tech drawing features === Details === Graphical illustrations, more details and further ideas are provided at the accompanying web page for this proposal. [1] 1) The new tool will comprise a number of "modules" for the most commonly needed geometric constructions, including: - parallel/perpendicular to a line (at a given distance or through a given point) - angle/segment bisector - circle with given center and radius / circle through 3 points - interactive path mirroring/rotation (for symmetric drawings) - measurements (distances, angles, possibly path lengths and areas) All parameters involved in a construction (angles, distances, coordinates, etc.) will be settable both by mouse and via exact numeric keyboard input through toolbar controls. Internally, the tool will be implemented as a collection of "Live Path Effects" (LPEs) [2]; the algorithms for non-trivial path manipulations are provided by the 2geom library [3]. LPEs are designed as a general framework for new tools in Inkscape and provide excellent low-level support for a unified treatment of these seemingly quite disparate geometric construction modules. 2) Notwithstanding, LPEs lack a good *interactive* user interface for easy on-canvas adaption of their parameters. Moreover, the existing controls are only accessible in a cumbersome way through the LPE dialogs. In view of these limitations and the intended use of LPEs for future tools in Inkscape, I will - expand the current rudimentary support for on-canvas interaction to a flexible UI - implement a general framework that allows automatic integration of LPE controls into the toolbars of existing tools (similar to how they are now added to the LPE dialogs) as well as toggling their visibility depending on the LPE being used The latter will essentially also implement the toolbar of the new Tech Drawing tool and greatly simplify the creation of future tools through LPEs. 3) Some old and heavily buggy cold will become obsolete by my work. This is certainly true for "linked/dynamic offsets" (which 2geom's algorithms and the new UI supersede) but likely applies to other code, too (possibly guidelines). I will look for code that falls into this category and plan my work accordingly, in agreement with the internal refactoring goals of Inkscape's upcoming version 0.47. 4) As a matter of course, the new frameworks will be extensively documented during their implementation (following the excellent example of existing LPE structure [2]). 5) Inkscape's bug tracker lists a huge number of feature requests related to geometric/CAD drawing. If time permits (which I expect), I will implement a suitable number of these. Here is an incomplete collection (visually illustrated and continued at [1]), in rough order of expected difficulty/desirability. - "Preserve angles" mode for node editing of polygons - Marker improvements (correct color, direction/point of alignment) - Improved snapping (in particular, "tangent snapping" of lines/paths to other paths) - User-defined coordinate origin/axis directions (up vs. down); this should be combined with removing Inkscape's internal usage of two different coordinate systems (an endless source of confusion and bugs) - Document units scaling (e.g., 1cm = 200m); particularly useful for map creation - "Real time helpers" such as "dynamic/smart guides" or "interactive rulers"; since the recent addition of temporary canvas items to Inkscape this has become within closer reach == Timeline == Throughout the project I will gather user feedback regarding feature desirability and UI design. The resonance from the community has already been overwhelming during the write-up of this proposal (which also attests the great need for the proposed features). Coding will start by implementing the above-mentioned geometric construction modules as LPEs. Telling from two proof-of-concept implementations (a "circle construction"-LPE and a "perspective path"-LPE) [4][5] this should be accomplishable within the first week. The next 2-3 weeks will be spent on the UI for on-canvas parameter adaption. Allowing for some time to deal with unexpected problems, this should leave us with a basic but functional tool after about one month. The second part of my work will focus on implementing the automatic toolbar integration framework as described under item (2) above. I anticipate this phase to take also roughly 4 weeks. Depending on the remaining time and based on discussion with my mentor and the user community, I will then implement a suitable number of more advanced features such as the ones collected under item (4). Together with whatever work on the documentation still remains at that point, this will easily fill the time until the end of SoC. == Experience with Inkscape and qualification == I started coding for Inkscape during GSoC '07 when I implemented the new 3D box tool which is included in the just released version 0.46. After SoC I considerably refactored the tool to lay the foundation for further 3D features. This has led to a "perspective path LPE" [5] as first payoff with many more things planned. I also worked on numerous bug fixes (code-wise or by providing feedback) and am an active member of the devel mailing list. My acquaintance with Inkscape's code will allow me to dive into the real work right from the start (unlike last year when getting used to unknown parts consumed a considerable amount of time even at later stages of the program). For a description of other former coding projects and general open source experience see [1]. == About me == I'm a 27-year-old student of mathematics from Heidelberg, Germany. I'm currently in the phase of my final exams which will lead to my graduation in May. Having neither classes nor other obligations in summer, I can devote my full time to the SoC project. I'm a passionate a-capella singer, performing in various choirs and vocal groups. My resulting experience with organizing concerts and communicating with people will stand me in good stead for this project, too (after all, open source is all about community). I also enjoy sports (running, volleyball), reading, and hanging out with friends. See [1] for my detailed CV. == Other GSoC applications == I have not applied for any other GSoC projects. [1] http://www.rzuser.uni-heidelberg.de/~malbert/ [2] http://wiki.inkscape.org/wiki/index.php/MakingLivePathEffects [3] http://lib2geom.sourceforge.net/ [4] SVN commit #18177, viewable online at http://tinyurl.com/yvyftz [5] SVN commit #18093, viewable online at http://tinyurl.com/6pkw76

3 3