- Inkscape Devel - Inkscape Mailman

NEW: relinking clones
by bulia byak 15 Jun '08

15 Jun '08

A new command, Relink Clone to Copied in Edit > Clone, allows you to relink any clone to a different original object without changing its other properties. Just copy (Ctrl+C) the object you want to be the new original, select any number of clones, and choose the Relink command. Now all selected clones are linked to the copied object. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

PS/EPS import proposal
by bulia byak 14 Jun '08

14 Jun '08

Would anyone object if I switch PS and EPS import from using pstoedit/skconvert to this: - convert ps to pdf with ps2pdf from Ghostscript - import pdf to Inkscape? Reasons: - Ghostscript is doubtlessly the most competent open source software for dealing with Postscript; it is cross-platform, actively updated and is much more commonly installed than anything else we've been using - our PDF importer is the best importer we have, and it works better than any third party things that claim to produce svg - for multipage postscript, we get for free a dialog for selecting the page (and later, the option to import multiple pages into one multipage SVG will only have to be coded once for PDF and work for PS at once). Testing by people in https://bugs.launchpad.net/bugs/190424 as well as my own experience tells me this route works quite well. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

6 14

Re: [Inkscape-devel] Poppler 0.8.3 change to GfxFont
by Bob Jamison 12 Jun '08

12 Jun '08

-----Original Message----- >From: Luca Bruno <gnug.torte@...112...> > >I know little about poppler but I really trust this guy and know he has >deep knowledge about poppler, and as far as I've the claim is true. >So, can you guys please check the current status and reply/act as >needed? > Yes, I think everyone knows that :) >> Inkscape's sneaky use of some private Poppler APIs finally bit us! However, what I gather is that what Inkscape needs is more than what their APIs provide. Unless there is a hook that can catch each parse event and do some kind of callback into Inkscape code, the dependency will remain. Maybe Miklos can look into that. bob

1 0

warning in LPE
by Jon A. Cruz 12 Jun '08

12 Jun '08

Does anyone have insight on this: live_effects/lpe-envelope.cpp: In member function 'virtual Geom::Piecewise<Geom::D2<Geom::SBasis> > Inkscape::LivePathEffect::LPEEnvelope::doEffect_pwd2(const Geom::Piecewise<Geom::D2<Geom::SBasis> >&)': live_effects/lpe-envelope.cpp:218: warning: control reaches end of non-void function I've been thinking I can address the structural and return issues, but I'd need to know what *should* be returned in the fallback case. Any ideas?

2 1

SPDocument initialization
by Jon A. Cruz 12 Jun '08

12 Jun '08

Hi guys, In cleaning up the autosave patch, I came across an uninitialized member variable in SPDocument (the flag for modified since last save). I cleaned up the initialization and added all the member variables I could find. However, it's possible this might unmask some other bugs or workarounds. Just wanted to give a heads-up on it.

1 0

Re: [Inkscape-devel] Proposal: stick to node or stick to segment
by Valerie 12 Jun '08

12 Jun '08

Hey, guys, Help! I'm trying to think up the interface for sticking, and the easiest would be to add a few buttons to Node edit mode to specify "stick:" you select two nodes and click the icon. Drawing a line from one stick point to another is fine too. I think there could be at least two types: stick node and stick object. Stick object is when you want the whole object to follow the other one around. Stick node only - with ability to stick handlers as well - is more used for linked fills and such. The whole object isn't moved, instead gets deformed by pulling the node in directions. There is one big problem though: does Anybody have any ideas how to make the nodes of two non-combined objects visible simultaneously for sticking? Proposals? The problem with combination, even if temporary, is that the combined objects lose their properties: a big no-no. Possibilities include: 1. Allow node-editing mode to show the nodes of multiple selected objects 2. Instead of targeting any available node, the user must first specify stick points or segments on individual objects. In a "stick" mode, all available stick points on all objects show up. This is also "cleaner" than when All the nodes show up. 3. Or same as above, except the available stick points only appear on mouse-over: you start drawing a line from the starter stick point to the destination stick point, upon drawing on the object the stick points of that object become visible. 4. A bit like above, but without needing to specify a custom stick-point: when drawing the connector, when you approach an object the nodes on said object become visible. So? Which one is acceptable? Or does anybody have completely different proposals in mind?

1 0

GSoC tech drawing project -- status report / outlook
by Maximilian Albert 12 Jun '08

12 Jun '08

Hi all, now that my recent changes are committed to trunk (which was a bit delayed because the LPE stacking forced me to rewrite some things), here is a little update on the status of my GSoC project. Caution, it's slightly lengthy! But even if you're not interested in most of it, I'd appreciate any comments on the questions/ideas mentioned (you may want to skip the first few paragraphs in this case). I started by writing three very simple LPEs for various geometric constructions. These are: circle-with-cadius, perpendicular-bisector and tangent-to-curve (in the following abbreviated CwR, PB and TtC). They were mainly chosen for the different kinds of user interaction they require so that I can use them as an indicator of what is still missing. Although LPE parameters can already be adapted using the LPE dialog, it is clear that for a user friendly interface we need knotholder handles for LPE items. I first added these in a quick-and-dirty way but it quickly became apparent that for a "correct" and more powerful solution the knotholder-related classes needed to be converted to C++. So this is what I did next (see my recent email for details). This also made it possible to add on-canvas handles for LPEs in a semi-automatic fashion similar to how parameters are added. I will put a description of how this works on the wiki soon. It works pretty well, but perhaps the mechanism can still be improved or made more elegant. Please let me know if you have any comments. Note that there already existed a PointParam parameter class for LPEs but the new handles do *not* duplicate their functionality since the latter can be used to alter _any_ kind of parameter, analogously to how handles for regular SPItems are used (e.g., with TtC there are handles to adjust the length of the tangent which is controlled by *scalar* parameters, not PointParams). Unfortunately, PointParams are currently broken due to the C++ification process but once I fix this, handles will also be added automatically for them. This will render the inconvenient "edit on canvas" button obsolete and make them much more comfortable to use (I'm looking forward to seeing the new lattice deformation in action then :)). One of the main remaining issues with handles is that we must eventually be able to simultaneously allow KnotHolders and NodePaths for LPE items. E.g., for PB and TtC it is essential to be able to edit the original path while at the same time adjusting the parameters on canvas. Currently this is not possible because an item can only have either a knotholder or a nodepath but not both. My first decent attempts to simply enable both for certain items consistently resulted in crashes. Since I'm not very familiar with the shape-editor code I'd appreciate any hints or even guidelines how this can be done. For instance, which parts of the code rely on the assumption that only one of knotholder/nodepath is active? Bulia, you said that you did some decent work in this direction. Do you have special advice how to proceed? Another simple recent change was to allow LPEs to either suppress the red helper path (which indicates the original path) or to display it permanently while the item is selected. E.g., for spiro splines it is suppressed while for PB and TtC it makes sense to know how the perpendicular bisector or the tangent are located with respect to the original curve so the helper path is displayed. BTW, I noticed a bug in my code - sometimes the helper curve does not disappear when the item is deselected. I will investigate this. What's the correct way to make the item disappear, anyway? The function remove_temporary_canvasitem() doesn't seem to work. IMO, the next big step to improve user interaction is to get rid of the "first draw a shape, then apply LPE" scheme. Most, if not all, of the planned LPEs only require very simple paths to which the LPE is applied. For example, CwR and PB only need a straight line, for a future angular bisector and circle-through-3-points we would need a path consisting of just three nodes, etc. My idea is this: Let's have a special mode in the pen and/or pencil tool which waits for a given number (say N) mouse clicks, then converts these into a polyline consiting of N nodes and (N-1) straight line segments (no curved paths are possible) and finally automatically applies a specified LPE to this polyline. This would be very similar to how the Spiro spline mode of the pen/pencil tool works now, only that arbitrary LPEs could be applied and that (optionally?) only polylines are allowed. As soon as we have a toolbar for the new geometric LPEs in place, the new "LPE mode" in the pen tool would be activated by pressing the corresponding button. Does this make sense? Any suggestions for details of the workflow? After this is done, I'm going to write the remaining planned LPEs (which I haven't done yet because I considered it favorable to have the on-canvas machinery in place in order to avoid major rewritings). This should be very quick (I already have drafts for a couple of them on my hard drive). Then I'd like to start tackling automatic toolbar integration of LPE parameters. I don't have a clear idea yet of what is needed for this so if you have any suggestions, I'd love to hear them. Johan, can you comment on this? Can I simply integrate RegisteredWidgets into existing toolbars or what kind of groundwork is needed to achieve this? Many thanks for reading thus far and for any comments you may have! Max

2 1

Is there a how to for creating integrated printer software for inkscape?
by stuart 12 Jun '08

12 Jun '08

Hi... Is there a how to for creating integrated printer software for inkscape? My assumptions are that inkscape can only print to raster and / or postscript type printers. And postscript is used when plotting or cutting is how the printer works. Beyond that, are there any provisions for "plugin" software printer drivers? For instance, what happens when you want to print to an HP plotter that understands HPGL? ...thanks

2 1

[Fwd: Re: r18847 introduces crash because of ... NULL]
by MenTaLguY 11 Jun '08

11 Jun '08

-------- Forwarded Message -------- From: MenTaLguY <mental@...3...> To: Peter Moulder <Peter.Moulder@...38...> Subject: Re: r18847 introduces crash because of ... NULL Date: Wed, 11 Jun 2008 13:15:31 -0400 On Wed, 2008-06-11 at 23:43 +1000, Peter Moulder wrote: > (If you'll excuse me pointing out the obvious, it's probably not a good > idea to deliberately introduce assertion failures into svn trunk.) I did address the failures I knew of beforehand (modulo the duplicate(NULL) bits I had once FIXMEd but since forgotten about) and those which I had discovered through casual testing (I *did* try various permutations of saving, just not Save As Plain...). However, there's ultimately no way around it -- if you add new assertions for things that can't be statically proven (either in absolute terms, or in practical terms due to e.g. the size of the codebase), there realistically *will* be some failures and you *have* to discover them empirically after introducing the assertions. Absent a complete enough test suite, the only way to discover lingering failures in a reasonable amount of time is to release the change to a branch where there is a large pool of testers. Incidentally, while the prohibition on NULL documents is new, the changes also caught at least one existing violation of an existing precondition: https://bugs.launchpad.net/inkscape/+bug/239092 (I should have tested extensions though. That I've no excuse for.) -mental

1 0

buildtool on linux
by Bob Jamison 11 Jun '08

11 Jun '08

Hi all, I've been working on buildtool some more, to try to make it more generic and portable. There is a lot of work to be done, but as of yesterday, it can now build Inkscape on Linux. build-lx.xml is the build file. Buildtool has a built-in package-config reader, which makes things a LOT easier. I uploaded a build here: http://inkscape.modevia.com/btool/inkscape-0806101650-btool.7z It uses binreloc, so it can be run from anywhere on the disk. It does not include all of the special dependencies of Inkscape. We will work on that later. It will likely just copy the not-so-common .so's to the $INKSCAPE/lib dir, exactly the same as the win32 "dist" target copies dlls. bob

1 0