- Inkscape Devel - Inkscape Mailman

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

GSoC 2008 Extensions Proposal
by Karlisson 07 Apr '08

07 Apr '08

Hi! I'm Karlisson Bezerra, from Brazil. I'm a system analisys student, web developer and work with Inkscape ilustrating websites and comics. Here is my blog, where I post comics drawn in Inkscape: http://nerdson.com I like programming and I've studying Python for a while, and got interested in extensions for Inkscape, so decided to propose a simple Application to GSoC 2008, to start colaborating with this excelent project. Unfortunately, I have submitted the proposal before reading the SOC Application Template (I'm sorry :-), but I'll respond the questions: I have first hear of Inkscape in a local free software meeting, and fell in love with it =). I'm working with it since this meeting, and wish to learn to program in C++ to collaborate more. I still have a short participation, with some questions and e-mails. My plan to GSoC is just to start coding for Inkscape, in a language which I have some knowledge. My past collaborations were just html code, illustrations and layouts for free software meetings and projects. I'm just starting to help coding =). I'm updating and reviewing the subversion trunk a fews months ago, since the great modifications to 0.46. My application (as described in the proposal) is a set of Python extensions for Inkscape that gets text objects and "break apart" it in lines, words or letters, and creates different text objects for each fragment of the text. The set can have also a extension to "join" every piece of text in one unique text object. Original request is here: https://bugs.launchpad.net/inkscape/+bug/171748 I've already started coding and have a functional extension. The splitted words get all aligned below the original text. :) The others extensions will be based on it. Hope you like the proposal, thanks! -- Karlisson de Macêdo Bezerra http://nerdson.com/ - "Don´t panic!"

1 0

GSoC: Customizable toolbars
by Krzysztof Kosiński 06 Apr '08

06 Apr '08

Seeing that the deadline has been extended, I'm considering applying for the Google Summer of Code. My idea is to implement customizable toolbars (preferably via a drag-and-drop interface similar to that in Firefox). This would apply to both the tools bar and the toolbar that sits below the menus, but wouldn't need to apply to the toolbox (the tool-specific toolbar). The steps involved: 1. (required) Create the required prefs infrastructure (proposed: eq. "tools.selector.order", -1 means not in the toolbar, sorting by this pref determines order) 2. (required) Move the relevant portions of code to gtkmm, probably refactoring along the way. 3. (required) Implement a drag-and-drop customization interface ("Customize Interface" item in Edit), using the Gtk::Toolbar class. 4. (bonus) Work on a preliminary architecture to allow extensions to define custom toolbar buttons. 5. (bonus) Allow grouping toolbar buttons into a compound button like the New button in OpenOffice or Back/Forward in Firefox I would like to know: a) Whether it is doable in the GSoC timeframe, b) Where is the code that creates & manages the tool buttons? I need a further look at it before I decide. Obviously it's not in tools-switch.cpp. Is it dispersed among the event context GObjects? Regards, Krzysztof (Chris) Kosiński -- View this message in context: http://www.nabble.com/GSoC%3A-Customizable-toolbars-tp16429222p16429222.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

1 1