What's left to do before 0.48.1?
Hello
Looks like nearly everything is done for 0.48.1 now: https://launchpad.net/inkscape/+milestone/0.48.1
The remaining unclosed issues are minor: 427514 only result in some confusion when working with 2 windows at once, 520521 is a build system improvement and 510618 is a connector-related quirk we can live with for now. There's also the bezier stamping regression, but I don't think the feature is used often enough to warrant further delay; the same effect can also be achieved with some more work using Ctrl+D.
Is there anything else holding up the release 0.48.1? There are several important bugs fixed in it, so I think it's important to push it out as soon as possible.
Regards, Krzysztof
Krzysztof,
I believe it's pretty close, however, I seem to recall Jon thinking that there still might be tablet issues on Windows. I don't know that it's a blocker for 0.48.1 as I'm game for us to go for a 0.48.2 if people would be interested. 0.49 is somewhat slow going, so I think we may want to revisit what the goals of it will end up being as well a potential target timeframe for that release. Additionally, we really should take the time to revisit the roadmap and do some long term planning (including if we want to revisit the version numbering system).
Jon, any thoughts? What about you su-v?
Cheers, Josh
2010/12/8 Krzysztof Kosiński <tweenk.pl@...400...>:
Hello
Looks like nearly everything is done for 0.48.1 now: https://launchpad.net/inkscape/+milestone/0.48.1
The remaining unclosed issues are minor: 427514 only result in some confusion when working with 2 windows at once, 520521 is a build system improvement and 510618 is a connector-related quirk we can live with for now. There's also the bezier stamping regression, but I don't think the feature is used often enough to warrant further delay; the same effect can also be achieved with some more work using Ctrl+D.
Is there anything else holding up the release 0.48.1? There are several important bugs fixed in it, so I think it's important to push it out as soon as possible.
Regards, Krzysztof
What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 14/12/10 00:43, Josh Andler wrote:
2010/12/8 Krzysztof Kosiński <tweenk.pl@...400...>:
Looks like nearly everything is done for 0.48.1 now: https://launchpad.net/inkscape/+milestone/0.48.1
The remaining unclosed issues are minor: 427514 only result in some confusion when working with 2 windows at once, 520521 is a build system improvement and 510618 is a connector-related quirk we can live with for now.
Bug #510618 also affects documents without any connectors. Opening the tutorials for example (which default to open in new windows) immediately dirties the file and prompts new users (trying to learn about Inkscape and first steps) when closing the tutorial window about saving changes even if they only wanted to read the introduction.
AFAIU it is not just a 'connector-related quirk'. After the commits for the text tool improvements, the entry in the undo history is no longer from the connector code in 'src/widgets/toolbox.cpp' but from the text tool. There seems something unintended going on when initializing new windows for newly opened documents (i.e. without reusing the current document window with an unchanged copy of the default template). And it does or can affect the initial rendering / routing of existing connectors (but not with every file).
Bug #510618 “Closing unchanged SVG asks for saving” https://bugs.launchpad.net/inkscape/+bug/510618
There's also the bezier stamping regression, but I don't think the feature is used often enough to warrant further delay; the same effect can also be achieved with some more work using Ctrl+D.
Is there anything else holding up the release 0.48.1? There are several important bugs fixed in it, so I think it's important to push it out as soon as possible.
I believe it's pretty close, however, I seem to recall Jon thinking that there still might be tablet issues on Windows. I don't know that it's a blocker for 0.48.1 as I'm game for us to go for a 0.48.2 if people would be interested. 0.49 is somewhat slow going, so I think we may want to revisit what the goals of it will end up being as well a potential target timeframe for that release. Additionally, we really should take the time to revisit the roadmap and do some long term planning (including if we want to revisit the version numbering system).
Jon, any thoughts? What about you su-v?
a) Proposing to get 0.48.1 out as soon as possible.
b) Proposing to aim for 0.48.2 as second bug fix release.
No new features, and only if it is possible with reasonable efforts to handle two increasingly diverging branches, especially after the merge of the C++ification GSoC project to trunk (which AFAIU could make it more difficult to backport bug fixes from trunk to 0.48.x):
Issues I could imagine being addressed with 0.48.2 (cherry-picked based mainly on recurring support questions and duplicates filed in the bug tracker [1]):
- tablet configuration: seems to still have issues, mainly on Windows - node tool: fix bugs, regressions and implement missing features [2] - various issues after resizing page or changing its orientation: -- connectors + groups + transforms -- clones + groups + transforms -- 3dbox + groups + transforms -- extensions + groups + transforms (perspective, envelope) - CSS: class attribute not saved in plain svg - selection glitch with clips & masks - clipboard: use internal renderer not Cairo PNG for system clipboard - align (not average) nodes (as in 0.47) - connectors: crashes, displacement under various circumstances - linked offsets (merge proposal) - precision of numerical transforms (toolbar, transform dialog) - trace bitmap preview broken on Windows - SVG: fix <symbol> in PDF export
c) Inkscape 0.49 / revisit roadmap
Features I could imagine being addressed for 0.49 (besides merging the Cairo renderer & implementing a configurable coordinate system [3]; not based on any existing, official roadmap but cherry-picked from bug reports/feature requests and user requests/questions in support forums or on irc):
- SVG: image links: fix (optional) relative linking - UI: image properties dialog enhancements (blueprint + branch) - UI: redesign export dialog (blueprint save vs export, GSoC 2010): - support selection/custom for vector formats, - extended support for raster graphics formats - UI: new from template (blueprint) - UI: redesign tiled clones dialog (spec available) - UI: redesign filter editor, custom filter effects (blueprint) - crop: razor tool for vectors, crop for embedded raster graphics - fonts: font substitution (manager) - PDF/SVG import - fonts: import text as path - PDF import - LPE: technical drawing tools, powerstroke - LPE: pattern along path: implement ribbon mode - LPE: better UI for envelope and lattice deformation - LPE: add perspective transform - CSS: extended CSS support (external and multiple style sheets) - SVG: full support of viewBox attribute (GUI options) - SVG: embedded fonts / glyphs support - SVG: support references to external files for <use> objects aka clones as basis for object libraries (for shapes, stencils, symbols etc) - SVG: support linking SVG files as images on all platforms
~suv
Notes:
[1] links to related bug reports on request
[2] compiled list of the reported issues from various places (inkscape-devel, bug tracker, user reports/questions) is on my todo list; will post it as soon as possible
[3] IMHO it is crucial to make this configurable, else Inkscape will shut out major user groups (technical drawings, diagrams / function plots for scientific publications, possibly font design, etc.), which haven't been vocal in the recent discussions because they are not aware of planned changes to just switch the coordinate system (to accommodate the (IMHO) more vocal web design community).
W dniu 14 grudnia 2010 17:10 użytkownik ~suv <suv-sf@...58...> napisał:
a) Proposing to get 0.48.1 out as soon as possible. b) Proposing to aim for 0.48.2 as second bug fix release.
I agree. The recent GSoC merge mostly renamed functions and added new ones, so it should be quite simple to backport any patches to the 0.48 branch (though they probably won't compile after a simple cherry pick).
[3] IMHO it is crucial to make this configurable, else Inkscape will shut out major user groups (technical drawings, diagrams / function plots for scientific publications, possibly font design, etc.), which haven't been vocal in the recent discussions because they are not aware of planned changes to just switch the coordinate system (to accommodate the (IMHO) more vocal web design community).
I'm not 100% sure about making this configurable. The first step would be to make the UI coord system match the document coord system; then we can make improvements in configurability.
As for function plotting, I don't think anyone is going to manually input points using document coordinates, they are going to define a transform which establishes the coordinate system of their choice. There's also the function plotter extension.
I don't know enough about font design or technical drawings to say whether the coord system change would have a big negative impact.
Regards, Krzysztof
On 14/12/10 20:16, Krzysztof Kosiński wrote:
W dniu 14 grudnia 2010 17:10 użytkownik ~suv
[3] IMHO it is crucial to make this configurable, else Inkscape will shut out major user groups (technical drawings, diagrams / function plots for scientific publications, possibly font design, etc.), which haven't been vocal in the recent discussions because they are not aware of planned changes to just switch the coordinate system (to accommodate the (IMHO) more vocal web design community).
I'm not 100% sure about making this configurable. The first step would be to make the UI coord system match the document coord system; then we can make improvements in configurability.
As for function plotting, I don't think anyone is going to manually input points using document coordinates, they are going to define a transform which establishes the coordinate system of their choice. There's also the function plotter extension.
Take 'function plotting' off that list as an unfortunate choice of terms - technical drawings, diagrams and (mathematical) illustrations is what I most had in mind - anything that relates to being constructed or arranged with coords based on the Carthesian coordinate system with a positive or standard orientation, as used in math and e.g. in CAD applications.
~suv
On Dec 14, 2010, at 11:16 AM, Krzysztof Kosiński wrote:
W dniu 14 grudnia 2010 17:10 użytkownik
[3] IMHO it is crucial to make this configurable, else Inkscape will shut out major user groups (technical drawings, diagrams / function plots for scientific publications, possibly font design, etc.), which haven't been vocal in the recent discussions because they are not aware of planned changes to just switch the coordinate system (to accommodate the (IMHO) more vocal web design community).
I'm not 100% sure about making this configurable. The first step would be to make the UI coord system match the document coord system; then we can make improvements in configurability.
As for function plotting, I don't think anyone is going to manually input points using document coordinates, they are going to define a transform which establishes the coordinate system of their choice. There's also the function plotter extension.
I don't know enough about font design or technical drawings to say whether the coord system change would have a big negative impact.
I think we need to do an overall cleanup that clarifies what are UI coords, which are document coords, etc. The cleaner we can make this, the easier it will be to maintain and expand upon.
I definitely seen the need for a standard doc-to-ui transform that is configurable and dynamic. Among other things this will make it easy to have the document rotate as the ring on a wacom tablet is 'turned'. That's a very common bit of functionality that really helps artists.
2010/12/15 Jon Cruz <jon@...18...>:
I think we need to do an overall cleanup that clarifies what are UI coords, which are document coords, etc. The cleaner we can make this, the easier it will be to maintain and expand upon.
We just need to get rid of this artificial situation where what is shown in the UI does not match what is written into the document.
I definitely seen the need for a standard doc-to-ui transform that is configurable and dynamic. Among other things this will make it easy to have the document rotate as the ring on a wacom tablet is 'turned'. That's a very common bit of functionality that really helps artists.
This will be very hard to do, because the display system assumes the transformation from desktop to screen is a pure translate + uniform scale; the tiling system in SPCanvasArena is built on this assumption.
Regards, Krzysztof
2010/12/15 Krzysztof Kosiński <tweenk.pl@...400...>:
2010/12/15 Jon Cruz <jon@...18...>:
I think we need to do an overall cleanup that clarifies what are UI coords, which are document coords, etc. The cleaner we can make this, the easier it will be to maintain and expand upon.
We just need to get rid of this artificial situation where what is shown in the UI does not match what is written into the document.
I have to say, I really agree with Jon on this one (there's a lot of technical stuff I'd just rather not get involved in). To me it's almost a CSS & HTML type situation where presentation (in this case, the UI) and content should be able to be separate. If we end up locking it down it will really take away a lot of the all-purpose functionality (this coming from having used Inkscape for technical drafting about 3 weeks ago and relying on the UI coords the way they are now).
I definitely seen the need for a standard doc-to-ui transform that is configurable and dynamic. Among other things this will make it easy to have the document rotate as the ring on a wacom tablet is 'turned'. That's a very common bit of functionality that really helps artists.
This will be very hard to do, because the display system assumes the transformation from desktop to screen is a pure translate + uniform scale; the tiling system in SPCanvasArena is built on this assumption.
I don't think level of difficulty should push us to make short-sighted decisions. This really is the question of do we want to limit ourselves to being a graphic design tool or keep it open ended to users with other needs?
Cheers, Josh
On Dec 15, 2010, at 8:23 AM, Krzysztof Kosiński wrote:
This will be very hard to do, because the display system assumes the transformation from desktop to screen is a pure translate + uniform scale; the tiling system in SPCanvasArena is built on this assumption.
We do need to fix that in a unified manner. That is, we also need to fix the hardcoded DPI assumption and also the Y-axis inversion. These are different facets of the same problem.
On 14/12/10 17:10, ~suv wrote:
On 14/12/10 00:43, Josh Andler wrote:
Jon, any thoughts? What about you su-v?
a) Proposing to get 0.48.1 out as soon as possible. b) Proposing to aim for 0.48.2 as second bug fix release.
Issues I could imagine being addressed with 0.48.2 (cherry-picked based mainly on recurring support questions and duplicates filed in the bug tracker [1]):
- node tool: fix bugs, regressions and implement missing features [2]
[2] compiled list of the reported issues from various places (inkscape-devel, bug tracker, user reports/questions) is on my todo list; will post it as soon as possible
List (summary, detailed) attached: it merges open issues discussed in inkscape-devel, the Inkscape Forum and the bug tracker which (AFAICT) are still present in current trunk (or need to be checked) and sorts them by topic (not importance or status).
Please update if I missed some threads from inkscape-devel, included others that are either general or debatable feature requests (i.e. not based on comparing with the old node tool), or any other mistakes I made.
'detailed' is with quotes from inkscape-devel or the forum (including links to the threads); for issues already filed in the bug tracker I only provided the links (no further details).
~suv
1 Selection 1.1 tabbing through nodes|sub-paths, finding first/last node 1.2 node status details not shown in notification area in 0.48 1.3 notify about number of (sub-)paths in the node selection 1.4 skew transformation handles missing for x- or y-aligned nodes
2 Transforming nodes 2.1 Stamping tool does not work with node tool in version 0.48 2.2 Multiple Nodes Do Not Move Along Path in 0.48 2.3 "Join selected nodes" adds an extraneous node when joining near-duplicate nodes 2.4 Skew transformation is not updated in path data 2.5 duplicate node(s) with 'Shift+D' 2.6 break/join nodes shifts start node of closed path 2.7 node aligning vs averaging
3 Transforming handles 3.1 lost feature when rotating or scaling handles via kb 3.1 Handle can't be "fixed" when node smoothing in 0.48 3.3 Constrained rotation of handles with 'Ctrl+drag' 3.4 preserve symmetric shape when deleting a node
4 Node types 4.1 Shift+S convert cusp to semi-smooth, then smooth node? 4.2 Tangent node doesn't remain smooth after removing control handles 4.3 Node editor lies about node type when you convert a curve with smooth nodes to straight
5 Node sculpting 5.1 sculpting pressure sensitivity 5.2 sculpting node handles 5.3 sculpting profiles
6 Snapping 6.1 Nodes rotation center doesn't snap to grid 6.2 Scale/stretch/skew transforms with transform handles don't snap
7 Edit clip-path/mask/pattern/textframe
7.1 node-edit frame of flowed-text 7.2 edit mask/clip of spiro path 7.3 Make pattern assigned to group editable with the node tool 7.4 Editing a mask or clip Shape object doesn't work
8 LPE
8.1 switcher does not show with Knot LPE 8.2 show all parameter paths while node-editing a path with an LPE
9 Keyboard shortcuts
9.1 panning with space+LMB fails
1 Selection
1.1 tabbing through nodes|sub-paths, finding first/last node ------------------------------------------------------------ In Inkscape 0.47 r22583 I could conveniently find the first node of a path by selecting the path with the select tool, switch to the node tool and <TAB> once for the first node (or Shift+<TAB> for the last) and continue through all nodes with <TAB>.
With the new node tool this no longer works: now I have to select at least one node of a sub-path and <TAB> goes from there. If by chance I picked the last node I'm out of luck: the first <TAB> deselects all nodes and neither a second <TAB> nor a Shift+<TAB> does allow me to further select adjacent nodes of the sub-path. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/32978
Partially fixed: Tab selects the first node when nothing is selected. I am not sure what exactly Tab should when operating on a path with multiple subpaths, so there might be other issues. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33026
See the code of the old node tool. It was all worked out: it traversed nodes within one subpath, then jumped to the next subpath and traversed it, then when there are no more subpath it went to the beginning and started the cycle anew. Shift+tab cycled the other way around. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33027
A-ha! I checked 0.47, and the first Tab selects only one node. I was working under the assumption that it shifts the selection around. I'll fix this shortly. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33028
**needs checking: only selects first sub-path, never the others
1.2 node status details not shown in notification area in 0.48 -------------------------------------------------------------- the statusbar used to say how much total nodes are there ("2 of 5 nodes selected") and, for a single node, its type (smooth, cusp, auto) http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33185
Lost feature: the statusbar used to say how much total nodes are there
Partially fixed (x of x nodes), working on subpath reporting http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33212
Bug #654783 "node status details not shown in notification area in 0.48" https://bugs.launchpad.net/inkscape/+bug/654783
1.3 notify about number of (sub-)paths in the node selection ------------------------------------------------------------ Suggested feature: now that we can select multiple objects, the statusbar hints must reflect that, in the same way as subpaths, e.g. "2 of 9 nodes selected in 2 of 3 subpaths in 1 of 2 selected paths", or simply "2 of 9 nodes selected in 1 of 2 selected paths" if there are no subpaths involved. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33185
I would rather show other hints than information about how many objects are selected, because this information is not very useful, and if the user really wants this information it's available by switching to the selector tool. The new paradigm of the node tool makes little distinction between subpaths in the same path and subpaths in different paths. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33212
Exactly, and here you gave the reason why we should in fact show this information :) See, it's no distinction for your code (kudos to you), but it's different concepts and behavior for the user. So, being able to easily find out how many of these things are actually different objects and how many are subpaths is very useful. And if you're not using subpaths, you're not losing anything, there won't be any space wasted on the number of subpaths then. Ditto for paths when only one path is selected. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33214
1.4 skew transformation handles missing for x- or y-aligned nodes ----------------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/590260
2 Transforming nodes
2.1 Stamping tool does not work with node tool in version 0.48 -------------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/669162
2.2 Multiple Nodes Do Not Move Along Path in 0.48 ------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/642536
2.3 "Join selected nodes" adds an extraneous node when joining near-duplicate nodes -------------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/614628
2.4 Skew transformation is not updated in path data --------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/590259
2.5 duplicate node(s) with 'Shift+D' ------------------------------------ Missing feature: duplicate node handles too (like in 0.47) Different implementation for start nodes: 0.47 extended the path on both ends (new start or end node selected), 0.48.1 always selects the next (new) node(s) in path direction. https://bugs.launchpad.net/inkscape/+bug/555449
2.6 break/join nodes shifts start node of closed path ----------------------------------------------------- http://imgh.us/node-tool-sort-order-roundtrip-047-2.svg http://imgh.us/node-tool-sort-order-roundtrip-048-2.svg
2.7 node aligning vs averaging ------------------------------ If I try to align multiple selected nodes from one selected object, they are not aligned by the position of last selected nodes as I expected and as is in older INkscape versions, but now they are aligned in the middle of all selected nodes. http://www.inkscapeforum.com/viewtopic.php?f=29&t=5911&p=24984 http://www.inkscapeforum.com/viewtopic.php?f=22&t=4062&p=25136
https://bugs.launchpad.net/inkscape/+bug/171287 comment #3 ff https://bugs.launchpad.net/inkscape/+bug/457749 comment #9 https://bugs.launchpad.net/inkscape/+bug/557777
3 Transforming handles
3.1 lost feature when rotating or scaling handles via kb -------------------------------------------------------- when rotating or scaling handles via kb w/ R/L-Alt modifiers, it no longer controls the individual handles. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33185
3.1 Handle can't be "fixed" when node smoothing in 0.48 ------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/642533
3.3 Constrained rotation of handles with 'Ctrl+drag' ---------------------------------------------------- Lost feature: When rotating a handle with Ctrl, the previous behaviour was: - snap to origin, - its opposite and perpendicular, - to vertical/horizontal, and - to 15 deg steps from vertical. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33185
Fixed http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33212
You missed the "and perpendicular" part :) Also, just in case, the "15 degrees" everywhere should be "the value set in prefs", 15 is just the default (you probably got this right, just clarifying) http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33214
When ctrl+alt+dragging a node, it should slide along the handles *and their perpendiculars*; similarly when rotating a handle with Ctrl, it should snap to origin, its opposite *and perpendicular*, to vertical/horizontal, and to 15 deg steps from vertical - all works except the perpendiculars. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33671
Bug #590755 ctrl-dragging node handle does not snap to a line collinear with the opposite handle https://bugs.launchpad.net/inkscape/+bug/590755
3.4 preserve symmetric shape when deleting a node ------------------------------------------------- Regression (not filed as bug): <del> a node creates handles with random angle/length even if the path was fully symmetrical.
4 Node types
4.1 Shift+S convert cusp to semi-smooth, then smooth node? ---------------------------------------------------------- Lost feature: 1) create a cusp node next to a linear segment; 2) press Shift+S; it becomes semismooth, aligned with the segment (correct); 3) now press Shift+S again; old behavior is to make it fully smooth, extending the second handle, but your tool does nothing. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33185
Fixed http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33212
Works but buggy: the second handle appears in some random position instead of aligned with the segment! http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33214
**needs checking
4.2 Tangent node doesn't remain smooth after removing control handles --------------------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/655222
4.3 Node editor lies about node type when you convert a curve with smooth nodes to straight ------------------------------------------------------------------ https://bugs.launchpad.net/inkscape/+bug/610817
5 Node sculpting
5.1 sculpting pressure sensitivity ---------------------------------- Pressure sensitivity when sculpting (if I figure out a sensible behavior for it) http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33946
Node-sculpting pressure sensitivity with tablet lost. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/35345
Feature change or regression. The behavior of all node tool drags made uniform in that the outcome of the drag depends only on the current state of modifiers and the change in position of the mouse pointer. If pressure sensitive sculpting used the same paradigm (outcome depends only on the current pressure and position of the pen), it would be rather hard to do anything with it because the pressure decreases smoothly as you lift the pen from the tablet. If there is demand for this feature, I could break the paradigm in this one instance. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/35346
In 0.47, the shape of the path between the selected nodes is frozen when the Alt key is released. This isn't the perfect solution as the nodes will still move a bit (with the shape fixed) as the pen is lifted. Perhaps releasing the Alt key should also disable moving the nodes until the pen is returned to the tablet (or the mouse button released and pressed again). http://article.gmane.org/gmane.comp.graphics.inkscape.devel/35351
Not fixed, unlikely to be fixed in 0.48.1 unless someone comes up with a precise behavior to implement http://article.gmane.org/gmane.comp.graphics.inkscape.devel/35363
To match 0.47, the higher the pressure, the wider the effected region. The shape is fixed when the Alt key is released. You can see a picture in my guide book http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Paths-Editing.html#Paths-Editing-Node Scroll down a bit or search for "pressure sensitivity".
To make this more useful, I would suggest disabling moving nodes after the Alt key is released until the mouse button is also released. This would prevent the nodes from shifting due to mouse movement once the desired shape is obtained. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/35364
5.2 sculpting node handles -------------------------- Node handles are not sculpted based on their position! so if you drag the middle of a text string down it becomes all jagged because all handles stay horizontal while the text itself is bent. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33671
Oops, I did the testing on a rectangle with some inserted nodes so I didn't catch this. Will fix as well. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33672
a thing I already reported, still not fixed: sculpting node handles http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33948
5.3 sculpting profiles ----------------------
Lost feature: node sculpting. Will you work on it, or do you want me to work on porting it?
I will port it, but for now only one "sculpting profile" will be available. I would like to add enum support to preferences before introducing even more magic numbers to it.
Thanks! Actually as I remember the other profiles were more or less placeholders in the old code too, I intended to enable them in UI one day, but for now only bell-shape worked. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33195
Just tested with both 0.47 and 0.48+devel - the new node tool indeed doesn't seem to support sculpting profiles. http://www.inkscapeforum.com/viewtopic.php?f=5&t=5836&p=24673
6 Snapping
6.1 Nodes rotation center doesn't snap to grid ---------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/667072
6.2 Scale/stretch/skew transforms with transform handles don't snap ------------------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/590261
7 Edit clip-path/mask/pattern/textframe
7.1 node-edit frame of flowed-text ---------------------------------- just noticed one more regression: the node tool can no longer edit flowed text's rectangle envelope. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33942
7.2 edit mask/clip of spiro path -------------------------------- if you draw path in Spiro mode and then clip and/or mask it, in Node tool its clip/mask will not be editable even if you turn on their toggles. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33214
7.3 Make pattern assigned to group editable with the node tool -------------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/686245
7.4 Editing a mask or clip Shape object doesn't work ---------------------------------------------------- Same for masks and clipping paths -- you cannot edit them, only the objects that are clipped or masked, http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33943
You can edit them, but they must be paths. Multi-shape editing isn't implemented, and it's a rather substantial piece of work, so do not expect it to be in 0.48 (I haven't even started on it yet :( ). http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33946
editing a clippath or mask often fails if clippath or mask is a shape (vs. a path) and clips or masks a single object (vs. a group) (not filed as bug yet because I haven't figured out how to consistently reproduce it.) http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33947
What does *multi*shape editing has to do with it? All the tool has to do is edit shapes like it has been doing for years. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33952
The difference is that now the clipping mask and the base shape are edited at the same time - the clip / mask editing buttons are toggles and do not change the selection. Before that, clip / mask editing buttons were pushbuttons that selected the clip or mask for editing.
It should still be possible to edit 1 normal shape in addition to all the paths, so I think this is actually a bug somewhere in my code. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33956
Bug #589092 "Editing a mask or clip Shape object doesn't work" https://bugs.launchpad.net/inkscape/+bug/589092
**needs checking: any changes with multiple shape editing?
(...) As a bonus we get multiple shape editing (e.g. editing 4 rects and 2 ellipses at the same time) for free in the node tool. The shape tools still can't handle many shapes at once though, and there are no multi-shape features. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/35282
8 LPE
8.1 switcher does not show with Knot LPE ---------------------------------------- *LPE: Switcher does not show with Knot LPE. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/32943
unstable: node-editing path parameters, missing symbol for switcher http://www.inkscapeforum.com/viewtopic.php?f=5&t=5622&p=24029
8.2 show all parameter paths while node-editing a path with an LPE ------------------------------------------------------------------ https://bugs.launchpad.net/inkscape/+bug/609839
9 Keyboard shortcuts
9.1 panning with space+LMB fails -------------------------------- https://bugs.launchpad.net/inkscape/+bug/623660
Status as of r9962
1 Selection 1.1 tabbing through nodes|sub-paths, finding first/last node
Fixed
1.2 node status details not shown in notification area in 0.48
Won't fix in 0.48.1 due to the necessary string changes; can be fixed in 0.48.2 or 0.49
1.3 notify about number of (sub-)paths in the node selection
See above
1.4 skew transformation handles missing for x- or y-aligned nodes
Won't fix - skew handles are hidden on purpose. Otherwise they would overlap with rotation handles, making either difficult to use. I could introduce a setting in 0.48.2 that allows you to pick which handles are shown in preference.
2 Transforming nodes 2.1 Stamping tool does not work with node tool in version 0.48
Will fix in 0.48.1
2.2 Multiple Nodes Do Not Move Along Path in 0.48
Fixed
2.3 "Join selected nodes" adds an extraneous node when joining near-duplicate nodes
Essentially a duplicate of: https://bugs.launchpad.net/inkscape/+bug/515237 - requires changes in path data output
2.4 Skew transformation is not updated in path data
Fixed
2.5 duplicate node(s) with 'Shift+D'
Endnode problem - fixed; handle problem - this is on purpose, this behavior makes more sense to me. We also avoid introducing visual artifacts into the path.
2.6 break/join nodes shifts start node of closed path
Won't fix
2.7 node aligning vs averaging
Won't fix - order of selection is not stored for nodes; should be fixed by introducing new buttons / options to the A&D dialog
3 Transforming handles 3.1 lost feature when rotating or scaling handles via kb
Can't reproduce reliably, seems to be a problem with unreliable events
3.1 Handle can't be "fixed" when node smoothing in 0.48
Fixed
3.3 Constrained rotation of handles with 'Ctrl+drag'
Fixed
3.4 preserve symmetric shape when deleting a node
An example of wrong and correct behavior would be very useful
4 Node types 4.1 Shift+S convert cusp to semi-smooth, then smooth node?
Can't reproduce - pressing Shift+S the second time extend the second handle for me
4.2 Tangent node doesn't remain smooth after removing control handles
Fixed
4.3 Node editor lies about node type when you convert a curve with smooth nodes to straight
Fixed
5 Node sculpting 5.1 sculpting pressure sensitivity
Won't fix for now - can't see a way to implement this that is consistent with the effect of other modifiers and mouse sculpting (history of the current drag is not taken into account when determining the result, only the current position and modifier state)
5.2 sculpting node handles
Fixed some time ago
5.3 sculpting profiles
Could be addressed in 0.48.2 if there is user demand
6 Snapping 6.1 Nodes rotation center doesn't snap to grid
Fixed
6.2 Scale/stretch/skew transforms with transform handles don't snap
Won't fix for 0.48.1 - this is rather complex, could fix in 0.48.2 or 0.49
7 Edit clip-path/mask/pattern/textframe 7.1 node-edit frame of flowed-text
Won't fix for 0.48.1
7.2 edit mask/clip of spiro path
A case of "everything needs to be special cased for LPEs" - won't fix for 0.48.1
7.3 Make pattern assigned to group editable with the node tool
Won't fix for 0.48.1
7.4 Editing a mask or clip Shape object doesn't work
Fixed some time ago - I tested with a rectangle. No outline is shown though, which could be fixed in 0.49 or later.
8 LPE 8.1 switcher does not show with Knot LPE
Workaround: deselect after applying knot effect, then select again
8.2 show all parameter paths while node-editing a path with an LPE
This and the item above are another case of "everything needs to be special cased for LPEs". Instead of breaking the node tool further to accomodate LPEs, I'd rather spend some time fixing their API so that supporting them isn't such a pain. Could be addressed in 0.49.
9 Keyboard shortcuts 9.1 panning with space+LMB fails
How do I trigger this in the selector tool? It doesn't seem to work for me at all. Do I need to enable this somewhere?
Regards, Krzysztof
Hi Krzysztof,
thank you for your quick response to this long list - I hope it was ok to post it here as is and at least somewhat helpful to quickly focus on reported issues or wishes.
Some first notes (haven't updated from bzr yet):
On 17/12/10 00:20, Krzysztof Kosiński wrote:
1.4 skew transformation handles missing for x- or y-aligned nodes
Won't fix - skew handles are hidden on purpose. Otherwise they would overlap with rotation handles, making either difficult to use. I could introduce a setting in 0.48.2 that allows you to pick which handles are shown in preference.
As commented, it works with the select tool (skew handles visible and usable), even when the geometric bbox is used, for objects with zero width or height.
2.6 break/join nodes shifts start node of closed path
Won't fix
Why? It changes e.g. the position of Start/end markers or of text put on path (ignoring path effects for now) and can be hard to control or avoided when node-editing.
2.7 node aligning vs averaging
Won't fix - order of selection is not stored for nodes; should be fixed by introducing new buttons / options to the A&D dialog
Looking forward to being able to align nodes again (for many users averaging just isn't as useful as aligning to a fixed anchor (node) or x-|y-coordinate.
3.4 preserve symmetric shape when deleting a node
An example of wrong and correct behavior would be very useful
Example attached: original paths, marked nodes deleted in 0.47 and 0.48.0
Another test in 0.48: draw a rectangle, convert to path and delete one corner in the node tool: to me, the resulting curve is unexpectedly asymmetric.
6.2 Scale/stretch/skew transforms with transform handles don't snap
Won't fix for 0.48.1 - this is rather complex, could fix in 0.48.2 or 0.49
Maybe Diederik can help?
7.4 Editing a mask or clip Shape object doesn't work
Fixed some time ago - I tested with a rectangle. No outline is shown though, which could be fixed in 0.49 or later.
Still fails for me repeatedly (or occasionally?), but I haven't systematically tested it since confirming the report (I do use the setting to autogroup clipped/masked objects most of the time). I'll see if I can attach some example files to the report.
9.1 panning with space+LMB fails
How do I trigger this in the selector tool? It doesn't seem to work for me at all. Do I need to enable this somewhere?
Inkscape > Preferences > Scrolling: [x] Left mouse button pans when Space is pressed
suv
W dniu 17 grudnia 2010 01:26 użytkownik ~suv <suv-sf@...58...> napisał:
1.4 skew transformation handles missing for x- or y-aligned nodes
Won't fix - skew handles are hidden on purpose. Otherwise they would overlap with rotation handles, making either difficult to use. I could introduce a setting in 0.48.2 that allows you to pick which handles are shown in preference.
As commented, it works with the select tool (skew handles visible and usable), even when the geometric bbox is used, for objects with zero width or height.
I doesn't look very well in this case, and it's hard to pick the handle you want. It does limit the functionality a bit though. Does anyone else have an opinion on this?
2.6 break/join nodes shifts start node of closed path
Won't fix
Why? It changes e.g. the position of Start/end markers or of text put on path (ignoring path effects for now) and can be hard to control or avoided when node-editing.
There is no data that allows me to guess where the start of the path was before the break. Fixing this would require storing extra data in the XML (which would have to be invalidated at correct times), and if you did something else before joining and forget that the path was broken, it would be very surprising to see the end of the path end up in a different place than it was before the join. It's possible that I'm thinking of something different than you though - I'll investigate this in detail tommorow
6.2 Scale/stretch/skew transforms with transform handles don't snap
Won't fix for 0.48.1 - this is rather complex, could fix in 0.48.2 or 0.49
Maybe Diederik can help?
After backporting the current round of fixes to 0.48, I was reminded that there are some important snapping API improvements in trunk that were not backported to 0.48. Trying to implement this without those API changes would require absurd amounts of repetitive code. I guess it will be addressed in 0.49 at the earliest.
Thanks for all information, you're doing a lot of great work.
Regards, Krzysztof
On Dec 16, 2010, at 4:44 PM, Krzysztof Kosiński wrote:
W dniu 17 grudnia 2010 01:26 użytkownik ~suv <suv-sf@...58...> napisał:
1.4 skew transformation handles missing for x- or y-aligned nodes
Won't fix - skew handles are hidden on purpose. Otherwise they would overlap with rotation handles, making either difficult to use. I could introduce a setting in 0.48.2 that allows you to pick which handles are shown in preference.
As commented, it works with the select tool (skew handles visible and usable), even when the geometric bbox is used, for objects with zero width or height.
I doesn't look very well in this case, and it's hard to pick the handle you want. It does limit the functionality a bit though. Does anyone else have an opinion on this?
Ahh, good info here.
Instead of staying caught in the low-level 'how', we get a glimpse into the big-picture 'why'.
To summarize:
Negatives are * Doesn't look good in this case. and * Hard to pick the handle you want
Positives are * Would be consistent with the select tool * Approach works for the select tool * Restores lost functionality.
Given that a different tool is currently showing both, it sounds reasonable to match that. But in the long term it is better to explicitly address the negatives of the approach instead of abandoning the whole approach.
Now that the negatives have been detailed, a few different solutions start to come to mind. I think one of the simplest is to add a little placement logic to the handles so that if too many handles are starting to show up we will invoke code to intelligently place them slightly farther away from the object center so as to allow them to function. Another option that can be used in combination would be to make specific handles 'fly out' a bit more on mouse over.
Regardless, we probably just need to detail all aspects of what is a problem and then we'll be able to come up with a good overall solution.
2010/12/17 Jon Cruz <jon@...18...>:
Given that a different tool is currently showing both, it sounds reasonable to match that. But in the long term it is better to explicitly address the negatives of the approach instead of abandoning the whole approach.
In fact, I was thinking about modifying the selector to match the node tool.
Now that the negatives have been detailed, a few different solutions start to come to mind. I think one of the simplest is to add a little placement logic to the handles so that if too many handles are starting to show up we will invoke code to intelligently place them slightly farther away from the object center so as to allow them to function.
I like this better than simply copying the selector tool. The skew handles could be farther away from the bounding box than the rotation handles. I'll see whether this can be done
Regards, Krzysztof
On 17/12/10 01:26, ~suv wrote:
3.4 preserve symmetric shape when deleting a node
An example of wrong and correct behavior would be very useful
Example attached: original paths, marked nodes deleted in 0.47 and 0.48.0
Another test in 0.48: draw a rectangle, convert to path and delete one corner in the node tool: to me, the resulting curve is unexpectedly asymmetric.
Oops - for the second test, draw a _square_ (with 'Ctrl' pressed), not a _rectangle_.
~suv
On 17/12/10 08:40, ~suv wrote:
On 17/12/10 01:26, ~suv wrote:
3.4 preserve symmetric shape when deleting a node
An example of wrong and correct behavior would be very useful
Example attached: original paths, marked nodes deleted in 0.47 and 0.48.0
Another test in 0.48: draw a rectangle, convert to path and delete one corner in the node tool: to me, the resulting curve is unexpectedly asymmetric.
Oops - for the second test, draw a _square_ (with 'Ctrl' pressed), not a _rectangle_.
And I made yet another mistake: in the previously attached file, I forgot to save in Inkscape 0.47 after deleting the one node in the lower row (see new attachment):
Seems that for some curves (lower row in the example), 0.47 produces the same approximation results as 0.48, but not for all (upper row)?
~suv
On 17/12/10 00:20, Krzysztof Kosiński wrote:
Status as of r9962
4 Node types 4.1 Shift+S convert cusp to semi-smooth, then smooth node?
Can't reproduce - pressing Shift+S the second time extend the second handle for me
See attached file: difference is after the first use of 'Shift+S': in 0.48 and later, it extracts both handles, whereas in 0.47 it only extracts one handle, making the cusp node half-smooth it if is between a straight line and a curved segment.
~suv
[ reposting with lists inline for easier quoting ]
On 14/12/10 17:10, ~suv wrote:
On 14/12/10 00:43, Josh Andler wrote:
Jon, any thoughts? What about you su-v?
a) Proposing to get 0.48.1 out as soon as possible. b) Proposing to aim for 0.48.2 as second bug fix release.
Issues I could imagine being addressed with 0.48.2 (cherry-picked based mainly on recurring support questions and duplicates filed in the bug tracker [1]):
- node tool: fix bugs, regressions and implement missing features [2]
[2] compiled list of the reported issues from various places (inkscape-devel, bug tracker, user reports/questions) is on my todo list; will post it as soon as possible
List (summary, detailed) below: it merges open issues discussed in inkscape-devel, the Inkscape Forum and the bug tracker which (AFAICT) are still present in current trunk (or need to be checked) and sorts them by topic (not importance or status).
Please update if I missed some threads from inkscape-devel, included others that are either general or debatable feature requests (i.e. not based on comparing with the old node tool), or any other mistakes I made.
'detailed' is with quotes from inkscape-devel or the forum (including links to the threads); for issues already filed in the bug tracker I only provided the links (no further details).
~suv
[Node tool 0.48.2 summary.txt]
1 Selection 1.1 tabbing through nodes|sub-paths, finding first/last node 1.2 node status details not shown in notification area in 0.48 1.3 notify about number of (sub-)paths in the node selection 1.4 skew transformation handles missing for x- or y-aligned nodes
2 Transforming nodes 2.1 Stamping tool does not work with node tool in version 0.48 2.2 Multiple Nodes Do Not Move Along Path in 0.48 2.3 "Join selected nodes" adds an extraneous node when joining near-duplicate nodes 2.4 Skew transformation is not updated in path data 2.5 duplicate node(s) with 'Shift+D' 2.6 break/join nodes shifts start node of closed path 2.7 node aligning vs averaging
3 Transforming handles 3.1 lost feature when rotating or scaling handles via kb 3.1 Handle can't be "fixed" when node smoothing in 0.48 3.3 Constrained rotation of handles with 'Ctrl+drag' 3.4 preserve symmetric shape when deleting a node
4 Node types 4.1 Shift+S convert cusp to semi-smooth, then smooth node? 4.2 Tangent node doesn't remain smooth after removing control handles 4.3 Node editor lies about node type when you convert a curve with smooth nodes to straight
5 Node sculpting 5.1 sculpting pressure sensitivity 5.2 sculpting node handles 5.3 sculpting profiles
6 Snapping 6.1 Nodes rotation center doesn't snap to grid 6.2 Scale/stretch/skew transforms with transform handles don't snap
7 Edit clip-path/mask/pattern/textframe
7.1 node-edit frame of flowed-text 7.2 edit mask/clip of spiro path 7.3 Make pattern assigned to group editable with the node tool 7.4 Editing a mask or clip Shape object doesn't work
8 LPE
8.1 switcher does not show with Knot LPE 8.2 show all parameter paths while node-editing a path with an LPE
9 Keyboard shortcuts
9.1 panning with space+LMB fails
[Node tool 0.48.2 detailed.txt]
1 Selection
1.1 tabbing through nodes|sub-paths, finding first/last node ------------------------------------------------------------ In Inkscape 0.47 r22583 I could conveniently find the first node of a path by selecting the path with the select tool, switch to the node tool and <TAB> once for the first node (or Shift+<TAB> for the last) and continue through all nodes with <TAB>.
With the new node tool this no longer works: now I have to select at least one node of a sub-path and <TAB> goes from there. If by chance I picked the last node I'm out of luck: the first <TAB> deselects all nodes and neither a second <TAB> nor a Shift+<TAB> does allow me to further select adjacent nodes of the sub-path. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/32978
Partially fixed: Tab selects the first node when nothing is selected. I am not sure what exactly Tab should when operating on a path with multiple subpaths, so there might be other issues. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33026
See the code of the old node tool. It was all worked out: it traversed nodes within one subpath, then jumped to the next subpath and traversed it, then when there are no more subpath it went to the beginning and started the cycle anew. Shift+tab cycled the other way around. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33027
A-ha! I checked 0.47, and the first Tab selects only one node. I was working under the assumption that it shifts the selection around. I'll fix this shortly. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33028
**needs checking: only selects first sub-path, never the others
1.2 node status details not shown in notification area in 0.48 -------------------------------------------------------------- the statusbar used to say how much total nodes are there ("2 of 5 nodes selected") and, for a single node, its type (smooth, cusp, auto) http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33185
Lost feature: the statusbar used to say how much total nodes are there
Partially fixed (x of x nodes), working on subpath reporting http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33212
Bug #654783 "node status details not shown in notification area in 0.48" https://bugs.launchpad.net/inkscape/+bug/654783
1.3 notify about number of (sub-)paths in the node selection ------------------------------------------------------------ Suggested feature: now that we can select multiple objects, the statusbar hints must reflect that, in the same way as subpaths, e.g. "2 of 9 nodes selected in 2 of 3 subpaths in 1 of 2 selected paths", or simply "2 of 9 nodes selected in 1 of 2 selected paths" if there are no subpaths involved. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33185
I would rather show other hints than information about how many objects are selected, because this information is not very useful, and if the user really wants this information it's available by switching to the selector tool. The new paradigm of the node tool makes little distinction between subpaths in the same path and subpaths in different paths. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33212
Exactly, and here you gave the reason why we should in fact show this information :) See, it's no distinction for your code (kudos to you), but it's different concepts and behavior for the user. So, being able to easily find out how many of these things are actually different objects and how many are subpaths is very useful. And if you're not using subpaths, you're not losing anything, there won't be any space wasted on the number of subpaths then. Ditto for paths when only one path is selected. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33214
1.4 skew transformation handles missing for x- or y-aligned nodes ----------------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/590260
2 Transforming nodes
2.1 Stamping tool does not work with node tool in version 0.48 -------------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/669162
2.2 Multiple Nodes Do Not Move Along Path in 0.48 ------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/642536
2.3 "Join selected nodes" adds an extraneous node when joining near-duplicate nodes -------------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/614628
2.4 Skew transformation is not updated in path data --------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/590259
2.5 duplicate node(s) with 'Shift+D' ------------------------------------ Missing feature: duplicate node handles too (like in 0.47) Different implementation for start nodes: 0.47 extended the path on both ends (new start or end node selected), 0.48.1 always selects the next (new) node(s) in path direction. https://bugs.launchpad.net/inkscape/+bug/555449
2.6 break/join nodes shifts start node of closed path ----------------------------------------------------- http://imgh.us/node-tool-sort-order-roundtrip-047-2.svg http://imgh.us/node-tool-sort-order-roundtrip-048-2.svg
2.7 node aligning vs averaging ------------------------------ If I try to align multiple selected nodes from one selected object, they are not aligned by the position of last selected nodes as I expected and as is in older INkscape versions, but now they are aligned in the middle of all selected nodes. http://www.inkscapeforum.com/viewtopic.php?f=29&t=5911&p=24984 http://www.inkscapeforum.com/viewtopic.php?f=22&t=4062&p=25136
https://bugs.launchpad.net/inkscape/+bug/171287 comment #3 ff https://bugs.launchpad.net/inkscape/+bug/457749 comment #9 https://bugs.launchpad.net/inkscape/+bug/557777
3 Transforming handles
3.1 lost feature when rotating or scaling handles via kb -------------------------------------------------------- when rotating or scaling handles via kb w/ R/L-Alt modifiers, it no longer controls the individual handles. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33185
3.1 Handle can't be "fixed" when node smoothing in 0.48 ------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/642533
3.3 Constrained rotation of handles with 'Ctrl+drag' ---------------------------------------------------- Lost feature: When rotating a handle with Ctrl, the previous behaviour was: - snap to origin, - its opposite and perpendicular, - to vertical/horizontal, and - to 15 deg steps from vertical. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33185
Fixed http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33212
You missed the "and perpendicular" part :) Also, just in case, the "15 degrees" everywhere should be "the value set in prefs", 15 is just the default (you probably got this right, just clarifying) http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33214
When ctrl+alt+dragging a node, it should slide along the handles *and their perpendiculars*; similarly when rotating a handle with Ctrl, it should snap to origin, its opposite *and perpendicular*, to vertical/horizontal, and to 15 deg steps from vertical - all works except the perpendiculars. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33671
Bug #590755 ctrl-dragging node handle does not snap to a line collinear with the opposite handle https://bugs.launchpad.net/inkscape/+bug/590755
3.4 preserve symmetric shape when deleting a node ------------------------------------------------- Regression (not filed as bug): <del> a node creates handles with random angle/length even if the path was fully symmetrical.
4 Node types
4.1 Shift+S convert cusp to semi-smooth, then smooth node? ---------------------------------------------------------- Lost feature: 1) create a cusp node next to a linear segment; 2) press Shift+S; it becomes semismooth, aligned with the segment (correct); 3) now press Shift+S again; old behavior is to make it fully smooth, extending the second handle, but your tool does nothing. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33185
Fixed http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33212
Works but buggy: the second handle appears in some random position instead of aligned with the segment! http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33214
**needs checking
4.2 Tangent node doesn't remain smooth after removing control handles --------------------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/655222
4.3 Node editor lies about node type when you convert a curve with smooth nodes to straight ------------------------------------------------------------------ https://bugs.launchpad.net/inkscape/+bug/610817
5 Node sculpting
5.1 sculpting pressure sensitivity ---------------------------------- Pressure sensitivity when sculpting (if I figure out a sensible behavior for it) http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33946
Node-sculpting pressure sensitivity with tablet lost. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/35345
Feature change or regression. The behavior of all node tool drags made uniform in that the outcome of the drag depends only on the current state of modifiers and the change in position of the mouse pointer. If pressure sensitive sculpting used the same paradigm (outcome depends only on the current pressure and position of the pen), it would be rather hard to do anything with it because the pressure decreases smoothly as you lift the pen from the tablet. If there is demand for this feature, I could break the paradigm in this one instance. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/35346
In 0.47, the shape of the path between the selected nodes is frozen when the Alt key is released. This isn't the perfect solution as the nodes will still move a bit (with the shape fixed) as the pen is lifted. Perhaps releasing the Alt key should also disable moving the nodes until the pen is returned to the tablet (or the mouse button released and pressed again). http://article.gmane.org/gmane.comp.graphics.inkscape.devel/35351
Not fixed, unlikely to be fixed in 0.48.1 unless someone comes up with a precise behavior to implement http://article.gmane.org/gmane.comp.graphics.inkscape.devel/35363
To match 0.47, the higher the pressure, the wider the effected region. The shape is fixed when the Alt key is released. You can see a picture in my guide book http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Paths-Editing.html#Paths-Editing-Node
Scroll down a bit or search for "pressure sensitivity".
To make this more useful, I would suggest disabling moving nodes after the Alt key is released until the mouse button is also released. This would prevent the nodes from shifting due to mouse movement once the desired shape is obtained. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/35364
5.2 sculpting node handles -------------------------- Node handles are not sculpted based on their position! so if you drag the middle of a text string down it becomes all jagged because all handles stay horizontal while the text itself is bent. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33671
Oops, I did the testing on a rectangle with some inserted nodes so I didn't catch this. Will fix as well. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33672
a thing I already reported, still not fixed: sculpting node handles http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33948
5.3 sculpting profiles ----------------------
Lost feature: node sculpting. Will you work on it, or do you want me to work on porting it?
I will port it, but for now only one "sculpting profile" will be available. I would like to add enum support to preferences before introducing even more magic numbers to it.
Thanks! Actually as I remember the other profiles were more or less placeholders in the old code too, I intended to enable them in UI one day, but for now only bell-shape worked. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33195
Just tested with both 0.47 and 0.48+devel - the new node tool indeed doesn't seem to support sculpting profiles. http://www.inkscapeforum.com/viewtopic.php?f=5&t=5836&p=24673
6 Snapping
6.1 Nodes rotation center doesn't snap to grid ---------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/667072
6.2 Scale/stretch/skew transforms with transform handles don't snap ------------------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/590261
7 Edit clip-path/mask/pattern/textframe
7.1 node-edit frame of flowed-text ---------------------------------- just noticed one more regression: the node tool can no longer edit flowed text's rectangle envelope. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33942
7.2 edit mask/clip of spiro path -------------------------------- if you draw path in Spiro mode and then clip and/or mask it, in Node tool its clip/mask will not be editable even if you turn on their toggles. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33214
7.3 Make pattern assigned to group editable with the node tool -------------------------------------------------------------- https://bugs.launchpad.net/inkscape/+bug/686245
7.4 Editing a mask or clip Shape object doesn't work ---------------------------------------------------- Same for masks and clipping paths -- you cannot edit them, only the objects that are clipped or masked, http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33943
You can edit them, but they must be paths. Multi-shape editing isn't implemented, and it's a rather substantial piece of work, so do not expect it to be in 0.48 (I haven't even started on it yet :( ). http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33946
editing a clippath or mask often fails if clippath or mask is a shape (vs. a path) and clips or masks a single object (vs. a group) (not filed as bug yet because I haven't figured out how to consistently reproduce it.) http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33947
What does *multi*shape editing has to do with it? All the tool has to do is edit shapes like it has been doing for years. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33952
The difference is that now the clipping mask and the base shape are edited at the same time - the clip / mask editing buttons are toggles and do not change the selection. Before that, clip / mask editing buttons were pushbuttons that selected the clip or mask for editing.
It should still be possible to edit 1 normal shape in addition to all the paths, so I think this is actually a bug somewhere in my code. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33956
Bug #589092 "Editing a mask or clip Shape object doesn't work" https://bugs.launchpad.net/inkscape/+bug/589092
**needs checking: any changes with multiple shape editing?
(...) As a bonus we get multiple shape editing (e.g. editing 4 rects and 2 ellipses at the same time) for free in the node tool. The shape tools still can't handle many shapes at once though, and there are no multi-shape features. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/35282
8 LPE
8.1 switcher does not show with Knot LPE ---------------------------------------- *LPE: Switcher does not show with Knot LPE. http://article.gmane.org/gmane.comp.graphics.inkscape.devel/32943
unstable: node-editing path parameters, missing symbol for switcher http://www.inkscapeforum.com/viewtopic.php?f=5&t=5622&p=24029
8.2 show all parameter paths while node-editing a path with an LPE ------------------------------------------------------------------ https://bugs.launchpad.net/inkscape/+bug/609839
9 Keyboard shortcuts
9.1 panning with space+LMB fails -------------------------------- https://bugs.launchpad.net/inkscape/+bug/623660
Krzysztof Kosi?ski wrote:
Looks like nearly everything is done for 0.48.1 now: https://launchpad.net/inkscape/+milestone/0.48.1
...
Is there anything else holding up the release 0.48.1? There are several important bugs fixed in it, so I think it's important to push it out as soon as possible.
I don't know whether this is a show-stopper, but I reported a bug which is still undecided: https://bugs.launchpad.net/inkscape/+bug/655048
How to reproduce: In MS Windows (I don't have access to other systems), create an Inkscape drawing from scratch with default settings, containing - a single line text in normal orientation - as well as rotated 90°ccw, - and a multi line text in normal orientation - and rotated 90°ccw. Then save a copy - to wmf, - to emf with text - and to emf with text converted to pathes.
Results: In wmf export, multiline text is merged into a single line. In emf export, rotated text is NOT rotated. Only in emf export with text converted to pathes, all texts are exported correctly.
Also save a copy to eps -- result is OK -- and save a copy to sk1 and use standalone Uniconvertor to convert sk1 file to svg: shows the same problems.
And another bug: When exporting to wmf I get the error message "uniconvertor failed" and a zero size file, if the output filename is longer than 16 characters plus ".wmf". The exports to emf and to sk1 work regardless of the filename.
-- Wilfried Hennings
participants (5)
-
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
Wilfried -
~suv