So, with 0.43 finally out, let's all return to development. The 0.44 will be a "long" "development" release, so you all have plenty of time to try your wildest ideas. (If you start right now, that is :)
I would like to list some things that I know are being worked on and that I would like to see finalized for 0.44. I'm not trying to push anyone, just making an overview of the projects I know and care about, in no particular order. Additions are welcome, as are comments - from the developers mentioned below as well as anyone else. Let's use this thread to get an idea of where we are and what we can expect in the future.
- GTKmmfication. Ralf Stephan seems to be making a good progress, so I really hope we'll see this coming to some kind of milestone soon, with most of the current code duplication eliminated. An update on the current status would be much appreciated.
- Rotation center retention (John Cliff) - a very useful simple patch that just needs to be rewritten correctly. I will then reuse this facility so that keyboard and Transform dialogs honor the center position as well.
- Path effects (ACSpike) - this basically means converting all the Python effects (and adding more) so they are completely live and applicable to any path or shape, without losing the editability of the original. We have a pretty good idea of what to do and how to do it. I'd really love to see this implemented, at least bascially, in 0.44.
- Memory debugging. No one has been doing this recently. Our memory intake is truly notorious, and I'm sure a lot can be done about that by a dedicated developer. The most natural person for this task is Mental, thanks to his libgc involvement, but patching leaks does not require much knowledge of the codebase (though it requires much special expertise), so volunteers are welcome.
- Text UI. I really have no excuses for not implementing the text toolbar. Except for, you guessed it, GTKmmfication being unfinished. For example, I want to subclass the Gtk::Spinbutton to make it easier to add a useful right-click menu for spinbuttons. I can do this now, but again, I'm not sure how much of this will have to be redone later.
- DOM (Bob Jamison). We have a Javascript subdir for ages, and I'm afraid it will start to bitrot (if not already) if not put to use. Bob, can you give an update on this?
- Layers dialog (Mental). Long overdue. Mental, is there anything specific we can do to help you start moving with that?
- Swatches panel in the main window (Jon Cruz). Really a must. A simple change, but one that will change the perception of Inkscape by new users drastically. Jon, what holds you back with this?
- Snapping. Lots of problems have accumulated in that area. User complaints are regular. Someone (probably me, though volunteers are welcome) just needs to lay out a plan and attack this methodically.
- style.cpp automation - Richard Hughes had some code for autogenerating style.cpp code from the CSS specification. I wonder what is the status of this?
- More connectors work (Michael) - specifically, I would love to see an option for connectors made of hor/vert segments only. This seems to be the most useful in practice. (And if we have Path Effects working, one of the first effects I'd like to see implemented is Round Corners. Any effect will be transparently applicable to connector lines.)
- Site redesign. We've got a design chosen, so what is the next step? Is anyone working on that?
- Windows "dialogs on top" patch for GTK from this bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1363297&gro... This issue sucks so big that we simply have no serious chances on Windows until it's resolved. Anyone knows the current status of the patch?
- Bug sorting and closing. We're really behind on that. Let's not (try to) clean this up before the release only. If everyone reviews, comments, and ideally closes a couple bugs right now, we will all have more room to breathe when 0.43 bugs start pouring in.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
And of course I forgot at least one thing:
- Mental volunteered to implement loadable keyboard profiles. Would be really nice to have in 0.44, to prevent more shortcuts wars :)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
How about adding a way to even turn off keyboard shortcuts for us mouse folks ? Maybe could just be a check box on the keyboard profile dialog. Nothing is more frustrating that to accidentially hit some keys or be off focus in a dialog and type a key and get unintentional things happening. It happened to me at least 3 times today using the text edit dialog.
bulia byak wrote:
And of course I forgot at least one thing:
- Mental volunteered to implement loadable keyboard profiles. Would be
really nice to have in 0.44, to prevent more shortcuts wars :)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id%16845&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, 2005-11-21 at 23:27 -0400, bulia byak wrote:
- Layers dialog (Mental). Long overdue. Mental, is there anything
specific we can do to help you start moving with that?
Not at this point, I don't think. It's mainly an issue of my finding time and getting back up to speed on the codebase.
For what it's worth, the layers dialog rewrite is also going to involve a much-needed rewrite of the quick layer selector.
-mental
- GTKmmfication. Ralf Stephan seems to be making a good progress,
so I really hope we'll see this coming to some kind of milestone soon, with most of the current code duplication eliminated. An update on the current status would be much appreciated.
The milestone would be a gtkmmified Document Preferences dialog, and the status is that extraction of widget behaviour into useful classes is nearly done, as well as rewrite of dialog layout. Those classes will (hopefully) be reusable by other dialogs.
Whether it all will be done in 0.44, with regular bugfixing, I dare not say, but you will soon see a first implementation for discussion within --new-gui. It's nice to have a test bed there.
ralf
- Windows "dialogs on top" patch for GTK from this bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1363297&gro...
Bug #1363297 - Dialogues on Top STILL not fixed 0.43 - has been closed as a duplicate of itself.
Bug #969321 - "Dialogs on top" does not work on Windows - looks like the correct bug (with patch) to link to. http://sourceforge.net/tracker/index.php?func=detail&aid=969321&grou...
This issue sucks so big that we simply have no serious chances on Windows until it's resolved. Anyone knows the current status of the patch?
I found the sparse discussion being spread over three months: http://mail.gnome.org/archives/gtk-devel-list/2005-September/thread.html#000... http://mail.gnome.org/archives/gtk-devel-list/2005-October/thread.html#00034 http://mail.gnome.org/archives/gtk-devel-list/2005-November/thread.html#0000...
bulia byak wrote:
- Site redesign. We've got a design chosen, so what is the next
step? Is anyone working on that?
Funny you brought that up. I just sent a message to the author of the chosen design yesterday. Once I get a response I will work with him on this to provide him with any information he needs and to help out in whatever way I can. I'll see what his schedule is like over the next month and a half to see when we can expect this. I would personally like to start the new year with the updated site, but if not at the new year, definitely for the release of 0.44.
-Josh
On Tue, 2005-11-22 at 07:28 -0700, Joshua A. Andler wrote:
bulia byak wrote:
- Site redesign. We've got a design chosen, so what is the next
step? Is anyone working on that?
Funny you brought that up. I just sent a message to the author of the chosen design yesterday. Once I get a response I will work with him on this to provide him with any information he needs and to help out in whatever way I can. I'll see what his schedule is like over the next month and a half to see when we can expect this. I would personally like to start the new year with the updated site, but if not at the new year, definitely for the release of 0.44.
Yes, it would be great to have the new site, about screen, etc, have some nice design that works together for the new year.
Jon
--- bulia byak <buliabyak@...400...> wrote:
- Rotation center retention (John Cliff) - a very useful simple
patch that just needs to be rewritten correctly. I will then reuse this facility so that keyboard and Transform dialogs honor the center position as well.
Rewrote most of it on Saturday inline with your comments, wrote the set/get bits for SPItem, purged the direct repr access, renamed the properties, Once I've switched it to relative to bbox and tested for a bit I'll send it over to you to take a look over.
Have some bigger things I'd like to play with, but I'll get the rotation centre stuff out the way before I see if I can get my head round the code involved for that :)
tis very nice to have 0.43 out the way tho. good work guys.
Sim
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
On Mon, 21 Nov 2005, bulia byak wrote:
Date: Mon, 21 Nov 2005 23:27:07 -0400 From: bulia byak <buliabyak@...400...> To: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] 0.44 plans
So, with 0.43 finally out, let's all return to development. The 0.44 will be a "long" "development" release, so you all have plenty of time to try your wildest ideas. (If you start right now, that is :)
- Rotation center retention (John Cliff) - a very useful simple
patch that just needs to be rewritten correctly. I will then reuse this facility so that keyboard and Transform dialogs honor the center position as well.
This will result in more non SVG markup wont it? :(
(When this was brought up before I believe someone thought it was something they would want to preserve across editing sessions but maybe that is overkill and just having the functionality for the current session would be enough?)
Given how following the SVG specification is stated as a primary goal it worries me when things are planned which seem likely to take inkscape further away from that. Sure any extra markup can safely be ignored but with both SVG and OpenDocument (and other existing schemes) providing extensive standards to choose from it seems like there might be better ways to do things than creating more markup which is useful only to Inkscape.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com
Alan Horkan wrote:
This will result in more non SVG markup wont it? :(
Given how following the SVG specification is stated as a primary goal it worries me when things are planned which seem likely to take inkscape further away from that. Sure any extra markup can safely be ignored but with both SVG and OpenDocument (and other existing schemes) providing extensive standards to choose from it seems like there might be better ways to do things than creating more markup which is useful only to Inkscape.
This is not a compliance issue. This is not a compliance issue.
Aaron Spike
On Tue, 22 Nov 2005 aaron@...749... wrote:
Date: Tue, 22 Nov 2005 20:38:44 -0600 From: aaron@...749... To: Alan Horkan <horkana@...44...>, Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: SVG compliance? [was Re: [Inkscape-devel] 0.44 plans]
Alan Horkan wrote:
This will result in more non SVG markup wont it? :(
Given how following the SVG specification is stated as a primary goal it worries me when things are planned which seem likely to take inkscape further away from that. Sure any extra markup can safely be ignored but with both SVG and OpenDocument (and other existing schemes) providing extensive standards to choose from it seems like there might be better ways to do things than creating more markup which is useful only to Inkscape.
This is not a compliance issue. This is not a compliance issue.
Describe it how you want but how is a more custom markup really a good thing? Is it not taking Inkscape further away from its core goals or should developers revise their stated goals? Are you really just continuing the Sodipodi mindset of using SVG as a means to an end? (That is fine too so long it is clearly stated.)
In response to mental my alternative was not to save the new centre points across sessions (I think the extra step might not really be necessary) avoiding the need for custom markup but still providing the desired functionality.
Also if I'm the only one who thinks creating lots of custom markup is a bad idea and no one is trying to avoid doing it then trying to suggest alternatives all the time will be like swimming upstream.
I had thought Inkscape would gradually use less and less custom markup and make it easier for other software to interoperate (not just view). If you really think it is a good idea to be adding more and more custom inkscape markup that isn't a problem. The issue for me is it doesn't match with perceptions of what I thought Inkscape was about and with the notion of more and more following standards.
Greater clarity of what the developers really have in mind is what I'm asking for. If I better understood what you were trying to do I'd be more likely to accept it than to keep challanging you to explain what seem like minor decisions but could have a larger long term impact.
Sincerely
Alan Horkan
"Inkscape's main goal is to create a powerful and convenient drawing tool fully compliant with XML, SVG, and CSS standards."
http://www.w3.org/TR/SVG/conform.html
http://www.w3.org/TR/REC-xml-names/#Conformance
Alan Horkan wrote:
On Tue, 22 Nov 2005 aaron@...749... wrote:
This is not a compliance issue. This is not a compliance issue.
Describe it how you want but how is a more custom markup really a good thing?
No, let's not just call it what we want. Let's describe it accurately and agree upon definitions for the words we use.
Define "fully conformant" please.
No custom markup is not a good thing. Certainly not if it isn't well documented and published.
Is it not taking Inkscape further away from its core goals or should developers revise their stated goals?
In many cases custom markup is bringing us closer to "powerful and convenient" and no further from "fully compliant".
Are you really just continuing the Sodipodi mindset of using SVG as a means to an end? (That is fine too so long it is clearly stated.)
Some developers most definately are. But they are diligently working within the bounds of the means.
In response to mental my alternative was not to save the new centre points across sessions (I think the extra step might not really be necessary) avoiding the need for custom markup but still providing the desired functionality.
http://inkscape.modevia.com/ap/JCB_demo_XVID.avi
Also if I'm the only one who thinks creating lots of custom markup is a bad idea and no one is trying to avoid doing it then trying to suggest alternatives all the time will be like swimming upstream.
You aren't alone. I agree with you. But you will be swimming up stream if you continualy condemn the inkscape namespace as non-conformant instead of suggesting alternatives.
I had thought Inkscape would gradually use less and less custom markup and make it easier for other software to interoperate (not just view). If you really think it is a good idea to be adding more and more custom inkscape markup that isn't a problem. The issue for me is it doesn't match with perceptions of what I thought Inkscape was about and with the notion of more and more following standards.
Greater clarity of what the developers really have in mind is what I'm asking for. If I better understood what you were trying to do I'd be more likely to accept it than to keep challanging you to explain what seem like minor decisions but could have a larger long term impact.
Please reread this final sentance and the previous paragraphs. Do you see how loaded your language is? This is a rather tame example of your writing. Alan, as a native speaker you surely must understand the force and implication of your words. Your choice of language is such that even though I agree with you I cannot take your side. This cannot be beneficial to your cause.
Aaron Spike
On Wed, 23 Nov 2005, Aaron and Sarah Spike wrote:
Date: Wed, 23 Nov 2005 07:11:43 -0600 From: Aaron and Sarah Spike <spike@...749...> To: Alan Horkan <horkana@...44...>, Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: SVG compliance? [was Re: [Inkscape-devel] 0.44 plans]
"Inkscape's main goal is to create a powerful and convenient drawing tool fully compliant with XML, SVG, and CSS standards."
complaince conformance ... these words are very loaded I'm sorry I didn't pick some other way to better express my concerns.
Alan Horkan wrote:
On Tue, 22 Nov 2005 aaron@...749... wrote:
This is not a compliance issue. This is not a compliance issue.
Describe it how you want but how is a more custom markup really a good thing?
No, let's not just call it what we want. Let's describe it accurately and agree upon definitions for the words we use.
I'd appreciate suggestions on how better to voice my concern about the use of more custom markup.
No custom markup is not a good thing. Certainly not if it isn't well documented and published.
In many cases custom markup is bringing us closer to "powerful and convenient" and no further from "fully compliant".
Custom markup can be ignored but makes it more difficult for other software to directly interoperate and benefit from extra markup and encourage healthy competition for Inkscape. It may also cause difficulties for users sharing files with people not also using the latest version of Inkscape. Given the sucess of Inkscape and slow turnaround of most distributions problems seem inevitable.
Are you really just continuing the Sodipodi mindset of using SVG as a means to an end? (That is fine too so long it is clearly stated.)
Some developers most definately are. But they are diligently working within the bounds of the means.
Well it helps to know there are developers who intend to expand on their use of the inkscape namespace because I had the apparently false impression people were interested in using less of it.
The option to export to Plain SVG balances things out a little but the general enthusiasm for the SVG standard and my own overenthusiasm had me thinking there would eventually be little or no difference between Inkscape SVG and Plain SVG but I take it from your comments that is unlikely to ever happen. It seems I just plain go the wrong idea.
(Meeting in person and talking to you all would be great, more reaons for me to make an effort to try and attend the Graphics Libre meeting this Springtime)
Also if I'm the only one who thinks creating lots of custom markup is a bad idea and no one is trying to avoid doing it then trying to suggest alternatives all the time will be like swimming upstream.
You aren't alone. I agree with you. But you will be swimming up stream if you continualy condemn the inkscape namespace as non-conformant instead of suggesting alternatives.
The other suggestion would be to use the OpenDocument Draw namespace to support (things like additional gradient types) until such time as the SVG includes more of what is needed. Would make XSLT transformations and other conversions a little simpler but seeking out existing standards and using them is more more than creating more items in the inkscape namespace but maybe it really isn't worth doing.
Greater clarity of what the developers really have in mind is what I'm asking for. If I better understood what you were trying to do I'd be more likely to accept it than to keep challenging you to explain what seem like minor decisions but could have a larger long term impact.
Please reread this final sentance and the previous paragraphs. Do you see how loaded your language is?
Sorry, I should have known better than to mention Sodipodi, never a good idea. I realise I could have chosen my words more carefully but as I fall behind the mailing list and have to read back mail for several days I tend to respond a little more hastily before the thread is completely gone. Normally I try to draft a mail and leave it a while before posting.
Mental said the "burden" was on me but I dont want to burden the developers or take on a burden I cannot realistically manage. If I know which way the current is flowing I can choose to follow it or get off or make minor adjustments without getting in the way of the bigger issues.
Given the fuss over the keybindings I cannot help feeling if I dont point out my concerns at the time it will be too late small for incremental changes. There are lots of little things which add up to bigger problems and each little issue has me seeing bigger problems (perhaps imagnined) that are harder to change the longer they remain.
and implication of your words. Your choice of language is such that even though I agree with you I cannot take your side. This cannot be beneficial to your cause.
I will try and choose my words more carefully
- Alan
Alan Horkan wrote:
On Wed, 23 Nov 2005, Aaron and Sarah Spike wrote:
I'd appreciate suggestions on how better to voice my concern about the use of more custom markup.
No custom markup is not a good thing. Certainly not if it isn't well documented and published.
I think we can start by documenting the problem. Since you and I both care about this, let's (you and I) work together to create some sort of schema docmument that defines the sodipodi and inkscape extensions.
In many cases custom markup is bringing us closer to "powerful and convenient" and no further from "fully compliant".
Custom markup can be ignored but makes it more difficult for other software to directly interoperate and benefit from extra markup and encourage healthy competition for Inkscape.
It might be better to say that custom markup MUST be ignored. I agree that there is an interoperation problem.
It may also cause difficulties for users sharing files with people not also using the latest version of Inkscape. Given the sucess of Inkscape and slow turnaround of most distributions problems seem inevitable.
Let's be very specific. The difficulties will be of the user interaction type, not the rendering type.
Some developers most definately are. But they are diligently working within the bounds of the means.
Well it helps to know there are developers who intend to expand on their use of the inkscape namespace because I had the apparently false impression people were interested in using less of it.
The option to export to Plain SVG balances things out a little but the general enthusiasm for the SVG standard and my own overenthusiasm had me thinking there would eventually be little or no difference between Inkscape SVG and Plain SVG but I take it from your comments that is unlikely to ever happen. It seems I just plain go the wrong idea.
SVG is a display language. The inkscape namespace preserves data used in creation and user interaction in the creator application. These are very different.
The other suggestion would be to use the OpenDocument Draw namespace to support (things like additional gradient types) until such time as the SVG includes more of what is needed. Would make XSLT transformations and other conversions a little simpler but seeking out existing standards and using them is more more than creating more items in the inkscape namespace but maybe it really isn't worth doing.
Supporting gradient types not supported in SVG would violate the unwritten rule "it must render the same everywhere".
Mental said the "burden" was on me but I dont want to burden the developers or take on a burden I cannot realistically manage. If I know which way the current is flowing I can choose to follow it or get off or make minor adjustments without getting in the way of the bigger issues.
I don't think it is a burden.
I will try and choose my words more carefully
Thank you very much.
Aaron Spike
--- Alan Horkan <horkana@...44...> wrote:
On Tue, 22 Nov 2005 aaron@...749... wrote:
Date: Tue, 22 Nov 2005 20:38:44 -0600 From: aaron@...749... To: Alan Horkan <horkana@...44...>, Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: SVG compliance? [was Re: [Inkscape-devel] 0.44 plans]
Alan Horkan wrote:
This will result in more non SVG markup wont it? :(
Given how following the SVG specification is stated as a primary
goal it
worries me when things are planned which seem likely to take
inkscape
further away from that. Sure any extra markup can safely be
ignored but
with both SVG and OpenDocument (and other existing schemes)
providing
extensive standards to choose from it seems like there might be
better
ways to do things than creating more markup which is useful only
to
Inkscape.
This is not a compliance issue. This is not a compliance issue.
Describe it how you want but how is a more custom markup really a good thing? Is it not taking Inkscape further away from its core goals or should developers revise their stated goals? Are you really just continuing the Sodipodi mindset of using SVG as a means to an end? (That is fine too so long it is clearly stated.)
I really dont see what your issue is with the custom mark up. That X in XML is there for a reason you know. If you want to loose the functionality it provides but have totally pure svg, never save as Inkscape SVG but always use plain SVG, and you'll have no nasty inkscape: attributes to worry about. As far as I'm aware we always create spec compliant SVG that should render correctly in any other implementation thats spec compliant. When it comes to it, if we offer you output that is pure SVG, wheres the issue with us also offering output thats SVG + custom namespace that gives you a better editing experience?
In response to mental my alternative was not to save the new centre points across sessions (I think the extra step might not really be necessary) avoiding the need for custom markup but still providing the desired functionality.
Except it wouldnt provide the desired functionality at all, which is to remember where i moved the rotation centres to, regardless of wheter i closed the file or not. The example vid i attached to the first post i made on this subject shows exactly the kind of thing where not preserving across sessions would negate the value of this feature.
Also if I'm the only one who thinks creating lots of custom markup is a bad idea and no one is trying to avoid doing it then trying to suggest alternatives all the time will be like swimming upstream.
I'm not going to go out of my way to look through other peoples custom markup to find something, but if you pointed me at something that did the sanme thing, I'd use it.
I had thought Inkscape would gradually use less and less custom markup and make it easier for other software to interoperate (not just view).
How am I making it harder? If I dont save the data, they cant use it. If i do their welcome to read the inkscape attribute too. I really dont see how having this in our namespace is an issue.
If you really think it is a good idea to be adding more and more custom inkscape markup that isn't a problem. The issue for me is it doesn't match with perceptions of what I thought Inkscape was about and with the notion of more and more following standards.
Exactly what standard is it not compliant with? or what standard provides the functionality? I'm not going to limit the capabilities of the software just cos you dont like having anouther namespace in use in your svg. (and again, feel free to save as plain svg)
Greater clarity of what the developers really have in mind is what I'm asking for. If I better understood what you were trying to do I'd be more likely to accept it than to keep challanging you to explain what seem like minor decisions but could have a larger long term impact.
Sincerely
Alan Horkan
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Quoting Alan Horkan <horkana@...44...>:
In response to mental my alternative was not to save the new centre points across sessions (I think the extra step might not really be necessary) avoiding the need for custom markup but still providing the desired functionality.
...when the desired functionality was explicitly identified as remembering the centre points across sessions?
Quoting Alan Horkan <horkana@...44...>:
The other suggestion would be to use the OpenDocument Draw namespace to support (things like additional gradient types) until such time as the SVG includes more of what is needed.
Please don't post any more on this particular topic until you can explain why your suggestion would directly violate the SVG standard.
Quoting Alan Horkan <horkana@...44...>:
If I better understood what you were trying to do I'd be more likely to accept it than to keep challanging you to explain what seem like minor decisions but could have a larger long term impact.
You do not give the appearance of making an effort to understand.
Repeatedly, you make sweeping criticisms based on faulty technical assumptions, couched in offensive ways, and when pressed for suggestions propose actions whose consequences you have obviously not bothered to understand or even consider.
Perhaps you're simply very impetuous, but this behavior often gives the appearance of trolling and is very tiresome.
I'm not going to killfile you as some others already have, but I'm not going to dignify future posts with a response except where you demonstrate an understanding of the technical issues involved.
As a positive example, I think your recent post regarding the "Horiz." and "Vert." labels was concise, relatively non-confrontational, and demonstrated an understanding of the relevent issues.
-mental
On Wed, 23 Nov 2005 mental@...3... wrote:
Date: Wed, 23 Nov 2005 13:35:53 -0500 From: mental@...3... To: Alan Horkan <horkana@...44...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: SVG compliance? [was Re: [Inkscape-devel] 0.44 plans]
Quoting Alan Horkan <horkana@...44...>:
In response to mental my alternative was not to save the new centre points across sessions (I think the extra step might not really be necessary) avoiding the need for custom markup but still providing the desired functionality.
...when the desired functionality was explicitly identified as remembering the centre points across sessions?
http://sourceforge.net/mailarchive/message.php?msg_id=13836020
"I've just commited some code that makes inkscape retain the centre of rotations location after you move it so that next time you come back to it the centre is where you put it."
No mention in this post of this being across saved sessions. I interpreted it as being within the same editing session and until readin futher was unsure if the proposed changed included saving across sessions. (Also not saving across sessions gives you a built in reset of the pivot point.)
Next mail by Peter Moulder http://sourceforge.net/mailarchive/message.php?msg_id=13847235 "I don't think this should extend even across different editing sessions:"
bulia would like it saved across sessions http://sourceforge.net/mailarchive/message.php?msg_id=13848609 David agrees http://sourceforge.net/mailarchive/message.php?msg_id=13887983
For what it is worth I rechecked OpenOffice Draw and it does allow you to change the centre of rotation but it does not save this information after you close the document. (In the Position and Size dialog there are options on if the centre or corner should be the default pivot point and input spinboxes allow the precise positioning of the pivot point.)
It seemed like storing the points might not be entirely necessary once the primary issue of remembering them across the current session was sorted and it didn't seem like it had been decided absolutely one way or the other.
Please don't post any more on this particular topic until you can explain why your suggestion would directly violate the SVG standard.
I didn't phrase it very well but perhaps from my other mail you got a better sense of my concerns.
It is easier to create more undocumented items within the inkscape namespace than trying to find and reuse an existing documented standard in use by other software (if it exists) but going back later and trying to figure out if better solutions exist will be difficult. If the use of the inkscape namespace was documented and kept up to date it would make it easier for all to identify when alternatives might be used. This will be useful when trying to identify if certain features are covered by newer SVG specifications. (The sodipodi namedView seems like it might contain information which could be expressed in SVG but it will take time to check and be sure.)
I'm not going to killfile you as some others already have,
I'm disappointed if people have decided to completely ignore my comments without first telling me my behaviour was so bad the felt it was necessary to go to that extreme. I realise some of my comments have been harsh but I am genuinely surprised anyone felt the need to completely block my comments.
but I'm not going to dignify future posts with a response except where you demonstrate an understanding of the technical issues involved.
Can't say fairer than that.
As a positive example, I think your recent post regarding the "Horiz." and "Vert." labels was concise, relatively non-confrontational, and demonstrated an understanding of the relevent issues.
Part of the problem is little issues like this make me see bigger Usability and Accessibility issues, which are trivial on their own and you might hardly notice them but trying to change details later might be considerably more difficult.
I will have to be more specific in future and not worry so much about the bigger picture.
- Alan
Quoting Alan Horkan <horkana@...44...>:
It seemed like storing the points might not be entirely necessary once the primary issue of remembering them across the current session was sorted and it didn't seem like it had been decided absolutely one way or the other.
Fair enough. I personally considered it settled, but you are probably right that it was not so evident.
If the use of the inkscape namespace was documented and kept up to date it would make it easier for all to identify when alternatives might be used.
That is a very good idea, and probably all you really needed to say.
There have been some efforts to document it before, but ... yeah. We've been too lax about it.
I realise some of my comments have been harsh
It wasn't so much the harshness as the volume (quantity) and low signal-to-noise ratio. Exhausting to deal with.
I will have to be more specific in future and not worry so much about the bigger picture.
Yes.
For my part I'll try to focus more on the high points of your posts.
-mental
Argh, my apologies. That last reply was intended to have been private.
-mental
On Wed, 2005-11-23 at 01:49 +0000, Alan Horkan wrote:
Sure any extra markup can safely be ignored but with both SVG and OpenDocument (and other existing schemes) providing extensive standards to choose from it seems like there might be better ways to do things than creating more markup which is useful only to Inkscape.
The burden is on you to identify a reasonable alternative candidate.
-mental
Hi,
I would like to see the Fill and Stroke dialog changed so that if no object is selected the dialog can be used to change the default drawing style. This would be of benefit when one first draws a background object and then wants to add additional objects on top of the background. In the current situation, the new objects are "invisible" until their style is changed. The new Status bar style indicators could also show the style that will be used to draw the new object.
Tav
On 11/23/05, Tavmjong Bah <tavmjong@...8...> wrote:
Hi,
I would like to see the Fill and Stroke dialog changed so that if noobject is selected the dialog can be used to change the default drawing style.
We don't have "default drawing style". We have "last set fill/stroke color" which most tools use by default (and all can use if you tell them to). This color is changed, naturally, when you set a color to anything by any means.
This would be of benefit when one first draws a background object and then wants to add additional objects on top of the background. In the current situation, the new objects are "invisible" until their style is changed.
Not really.
1. Draw a big rect. For example, suppose it's blue.
2. Draw a small rect on top. At first it's blue too. Now paint it red.
3. Draw more small rects. All of them will start red, without you doing anything special for that.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Wed, 2005-11-23 at 15:28 -0400, bulia byak wrote:
On 11/23/05, Tavmjong Bah <tavmjong@...8...> wrote:
Hi,
I would like to see the Fill and Stroke dialog changed so that if noobject is selected the dialog can be used to change the default drawing style.
We don't have "default drawing style". We have "last set fill/stroke color" which most tools use by default (and all can use if you tell them to). This color is changed, naturally, when you set a color to anything by any means.
OK, substitute "last set fill/stroke color" for "default drawing style".
But why can't the "last set fill/stroke color" be changed prior to use? If I select the Rectangle tool with no objects selected, why can't I preset the fill color and stroke color? It seems quite strange to me that the new Fill and Stroke color won't show the colors that will be used when drawing a new object (when no other object is selected). Having this visual cue could only help.
This would be of benefit when one first draws a background object and then wants to add additional objects on top of the background. In the current situation, the new objects are "invisible" until their style is changed.
Not really.
Draw a big rect. For example, suppose it's blue.
Draw a small rect on top. At first it's blue too. Now paint it red.
This is my point, the second rectangle is blue and you can't see it while drawing it. There is no visual feed back as to what you are doing. And accidentally unselect it and it is lost from view. The statistics are small but three out of three people I watched who where trying to learn to use Inkscape had exactly this problem (and were greatly confused by it)!
- Draw more small rects. All of them will start red, without you
doing anything special for that.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id%16865&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 11/23/05, Tavmjong Bah <tavmjong@...8...> wrote:
But why can't the "last set fill/stroke color" be changed prior to use?
In part, because of its name :) You can't become "the last president" until you are elected president at all :)
But in part, this is to keep things simple and logical. Compare two sequences of actions:
1. I draw a rect; I see that it's wrong color; I change the color.
2. I remember that I have a wrong "current color"; I change it; then I draw the rect.
Both sequences give the same end result and contain the same number of actions. However, 2 has the big disadvantage that I have to _remember_ (or at least check) what the current color is, and I need to figure out how to change that color as opposed to changing the color of an object. All this means extra unnecessary mental activity and learning new concepts. And if we agree to your proposal that "current color is changed by Fill&stroke when there's no selection", then 2 may actually take one action _more_ than 1: you'll have to deselect before you can change the current color.
Besides, the "No objects selected" in the Fill&stroke dialog is often a useful visual clue to the status of selection. If this dialog will be "always on" there will be no end of frustration when users will think they are acting on selection when in fact they are just changing the "current color". It will be a serious usability issue.
However, what you propose does make sense for another way of setting colors - for the Swatches palette, because that palette does not reflect the status of selection at all. And you know what, this functionality is already there! Open Swatches; make sure nothing is selected; click on any color. Now if you draw a rect, it will have that color.
Summarizing, you already have what you ask for in Swatches, but we cannot do the same in Fill&stroke because it will make it harder to use, not easier.
P.S. As a "usability hall of shame" footnote, in the same situation (clicking on a color swatch with nothing selected) Xara always displays a "do you want to set the color as default for new objects" dialog. This used to drive me mad.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Nov 23, 2005, at 11:28 AM, bulia byak wrote:
We don't have "default drawing style". We have "last set fill/stroke color" which most tools use by default (and all can use if you tell them to). This color is changed, naturally, when you set a color to anything by any means.
I think this is one area that we can improve things in. We need to get a good handle on nice workflow for stylesheets and such, though, before we go off to start changing things. I've had it in mind that some of what you mention can be improved as we beef up the CSS support and such.
On 11/23/05, Jon A. Cruz <jon@...18...> wrote:
I think this is one area that we can improve things in. We need to get a good handle on nice workflow for stylesheets and such, though, before we go off to start changing things. I've had it in mind that some of what you mention can be improved as we beef up the CSS support and such.
I don't think we need a "current style" for that. Saving named styles would much be more intuitive from objects.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 22 nov. 05, at 04:27, bulia byak wrote:
So, with 0.43 finally out, let's all return to development. The 0.44 will be a "long" "development" release, so you all have plenty of time to try your wildest ideas. (If you start right now, that is :)
I was about to report my "experience" in using Inkscape for the production of scientific illustrations. Now appears to be a good time. Sorry its a long email...
So first of all: it mostly works just great! Inkscape allowed me go completely open source in my scientific workflow (**see below) and produce more easily illustrations which look as good or even better that what I used to do with illustrator. But... everything can be better, isn't it? So here are my problems/suggestions/... I tried to put them in decreasing order of importance.
1/ The bigger problem is probably that few scientific softwares produce plots in SVG (damn, why is that?!). They all export EPS and the first problem is to get these EPS in Inkscape. At least on OS X, EPS import does not work because Inkscape cannot find pstoedit or ghostscript, though they are installed from fink. Where does inkscape takes the PATH from? With my fink tree added to the PATH in .bashrc or .profile in my home (.profile is the default) it does not work. With uberconverter on the way I hope all this will be solved in a not- so-far-away future.
2/ After some pstoedit command line stuff a second problem arises: all files converted this way are displayed fine in Inkscape but behave strangely: any new element is enormous, no dashes can be applied to existing strokes... This is all related to some strange transformation matrices. And some magic (from my point of view at least): copy-pasting all elements in a new document solves everything. Is there a reason why what is done when copying and pasting should not be done when opening the file?
Link to the RFE: http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=1119025 These two problems where really show stoppers and took most of my time dedicated to the illustrations. Basically, once I had correct SVG in Inkscape, all was quite easy. For additional information, I tried to update the wiki page about a possible XML repair service in Inkscape. http://wiki.inkscape.org/cgi-bin/wiki.pl?XML_Repair
3/ I found the Open/Save As/ menus not optimal. - Open: "All images" shows images (raster formats) but also vector documents. I would expect "All images" to be raster only... In addition, for a vector editor, I find it strange to have bitmaps listed here. They would be more suited only in the import menu IMHO. - Import-Export bitmap: Fine. - Save-Save As: This was discussed before but nothing happened: I think that "Save" should only save to formats where all data is kept. So eps, tex and others might be better suited under an "Export to vector" menu item. Even plain SVG maybe. In addition, from a workflow point of view, svg was my editable format and eps was my publishing format but I could only "save as" eps. So it was not possible to work on an svg document and export from time to time to my publishing format to see what it looks like integrated in my final layout. I had to work on a file which was said to be an eps (but wich was not), save from time to time and not forget to save to svg at the end. If something happens in between (power failure or whatever) I might loose changes that I thought I saved because they are not kept in the eps (transparency and all). IMHO, the "export to vector" is the way to go. This might lead to a little re-formating of the import menu too: why a single import menu and two export menus. Having Import bitmap, Import vector, Export bitmap, Export vector would seem logical and is good to educate people on the difference. If not, a "Save a copy" option would definitely be handy. RFE: http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=1282332
4/ Well real PDF export would be great, for nice keynote talks with beautiful transparency effects and all... Everybody knows. RFE: http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=864260
5/ Arrows are important and svg markers are great. They could be even better if they followed the style of the stroke they are applied to. Well this is already known but I mentioned it for the record. The possibility to design new custom markers would be useful. Currently the markers menu induces a lot of scrolling. Could it be displayed as a grid (I think at the difference between grid and list view in The Gimp)? Similarly, designing new dashes patterns and a more compact dashes menu would be useful. Finally, the ability to displace the "Mid Marker" along the path would be great. Bug about marker color: https://sourceforge.net/tracker/index.php? func=detail&aid=995815&group_id=93438&atid=604306 and many duplicate RFEs about coloring markers!!! http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=1361470 http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=1338697 http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=952769 http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=955240 http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=1144920 RFE about displacing mid marker: http://sourceforge.net/tracker/index.php? func=detail&aid=1365433&group_id=93438&atid=604309 RFE about marker and dashes menus: http://sourceforge.net/tracker/index.php? func=detail&aid=1365442&group_id=93438&atid=604309 RFE about designing new markers and dashes: http://sourceforge.net/tracker/?func=add&group_id=93438&atid=604309
6/ Text on path is good but, here again, the ability to displace the text along the path would make it much more valuable. RFE about displacing text on path: http://sourceforge.net/tracker/index.php? func=detail&aid=1365450&group_id=93438&atid=604309
7/ Node snapping is the way to go for precise work. Nevertheless, it would be handy to have an option to put stroke inside or outside a shape (which is currently only partially feasible by snapping bounding boxes). But apparently it sound difficult in SVG. Related to snapping, "smart guides" would be useful (even if the Align and Distribute dialog already does a good job). By smart guides I mean snapping aligning and snapping to the center of a neighboring object, or snapping at equal distance between two objects. This is likely to be CPU hungry tough. RFE about stroke inside/outside: http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=1038990 http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=1283673 http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=987784 RFE about smart guides: somehow: http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=903328 mine: http://sourceforge.net/tracker/index.php? func=detail&aid=1365461&group_id=93438&atid=604309
8/ "Font find and replace" would be a valuable addition to the Text and Font dialog. Sometimes you just get busted by a journal who wanted helvetica and times only and want to resubmit quickly to an other one who wants geneva and times new roman... RFE: http://sourceforge.net/tracker/index.php? func=detail&aid=1365463&group_id=93438&atid=604309
9/ Latex typesetting would be awesome (typesetting not graphical editing which seems impossible). I thought it could be done with a simple extension (as one feature request mention): calling latex on a text box, getting resulting ps, pstoedit it to svg and import the svg... but pstoedit traces the fonts and it looks terrible. I remember a linux vector editor which could typeset text boxes with pdflatex and include the pdf... but I cannot remember the name and can't find it (and it's not dia, sketch, karbon or sodipodi. xfig can do this but it was an other one). Could it be possible to do that in Inkscape? RFEs: http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=1210763 http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=1191893 (in the comments)
10/ The "Grid" effect is useful but why is it limited to a maximum of 10 pixels grid squares? (in addition the unit is not displayed in the effect's dialog).
I filled some feature requests for the features which were not already requested.
- Snapping. Lots of problems have accumulated in that area. User
complaints are regular. Someone (probably me, though volunteers are welcome) just needs to lay out a plan and attack this methodically.
I hoped that "put stroke inside" and "put stroke outside" while still snapping to nodes could be included in this plan but the comments in the RFEs seem definitive. Is it really impossible? even this a hack using inset and outset?
- More connectors work (Michael) - specifically, I would love to
see an option for connectors made of hor/vert segments only. This seems to be the most useful in practice. (And if we have Path Effects working, one of the first effects I'd like to see implemented is Round Corners. Any effect will be transparently applicable to connector lines.)
I hope this will develop well. A suggestion: if objects could be made avoidable/ignored from the left click menu it would be useful. As a side note, my personal favorite for this kind of work is Omnigraffle (but it does not even have the possibility to make objects avoidable!). Michael you probably know about it. If not, I think the older version (2.0) is available free of charge on their website. If Inkscape connectors could match the usability of Omnigraffle it would be... cool ;-)
** For those who still have time to loose after this long email, here is a (confidential because not already published) draft of my article: "Movement analysis routine and circular statistics using free software". All vector illustrations are made with Inkscape. With such a title it would have been a shame to use something else that free software to write and illustrate the article!!! http://jo.irisson.free.fr/dropbox/inkscape/draft.pdf
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
jiho wrote:
1/ The bigger problem is probably that few scientific softwares produce plots in SVG (damn, why is that?!). They all export EPS and the first problem is to get these EPS in Inkscape. At least on OS X, EPS import does not work because Inkscape cannot find pstoedit or ghostscript, though they are installed from fink. Where does inkscape takes the PATH from? With my fink tree added to the PATH in .bashrc or .profile in my home (.profile is the default) it does not work. With uberconverter on the way I hope all this will be solved in a not- so-far-away future.
2/ After some pstoedit command line stuff a second problem arises: all files converted this way are displayed fine in Inkscape but behave strangely: any new element is enormous, no dashes can be applied to existing strokes... This is all related to some strange transformation matrices. And some magic (from my point of view at least): copy-pasting all elements in a new document solves everything. Is there a reason why what is done when copying and pasting should not be done when opening the file?
I was looking at pdf output on windows a few days ago. I'd be happy to offer any assistance I can with the Mac. I don't have a Mac here, but I might be able to find a friend with a Mac around.
Aaron Spike
On Nov 24, 2005, at 3:22 AM, jiho wrote:
6/ Text on path is good but, here again, the ability to displace the text along the path would make it much more valuable. RFE about displacing text on path: http://sourceforge.net/tracker/index.php? func=detail&aid=1365450&group_id=93438&atid=604309
That's been in there for a while.
Just look at the startOffset attribute of the textPath element.
On 24 nov. 05, at 19:14, Jon A. Cruz wrote:
On Nov 24, 2005, at 3:22 AM, jiho wrote:
6/ Text on path is good but, here again, the ability to displace the text along the path would make it much more valuable. RFE about displacing text on path: http://sourceforge.net/tracker/index.php? func=detail&aid=1365450&group_id=93438&atid=604309
That's been in there for a while.
Just look at the startOffset attribute of the textPath element.
Thanks for the reply. I'll reformulate my request then: I would find it useful to have an interface for this. The easiest way is probably a slider in the text dialog, setting the percentage of this startOffset. The more useful way would be a key+drag combination of the text element (alt+drag?) to move it along the path with some feedback in the toolbar about the percentage. Should I fill a new RFE or can the previous one be re-opened and the subject changed?
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
jiho wrote:
On 24 nov. 05, at 19:14, Jon A. Cruz wrote:
On Nov 24, 2005, at 3:22 AM, jiho wrote:
6/ Text on path is good but, here again, the ability to displace the text along the path would make it much more valuable. RFE about displacing text on path: http://sourceforge.net/tracker/index.php? func=detail&aid=1365450&group_id=93438&atid=604309
That's been in there for a while.
Just look at the startOffset attribute of the textPath element.
Thanks for the reply. I'll reformulate my request then: I would find it useful to have an interface for this. The easiest way is probably a slider in the text dialog, setting the percentage of this startOffset. The more useful way would be a key+drag combination of the text element (alt+drag?) to move it along the path with some feedback in the toolbar about the percentage. Should I fill a new RFE or can the previous one be re-opened and the subject changed?
I would recommend that upon editing of the path to which the text is attached, that the startOffset be recalculated so that the text begins at the point in the path that is nearest to its previous position. I played with text on path for about 10 minutes last week and already felt like I had to work against the current behavior.
Aaron Spike
I would recommend that upon editing of the path to which the text is attached, that the startOffset be recalculated so that the text begins at the point in the path that is nearest to its previous position. I played with text on path for about 10 minutes last week and already felt like I had to work against the current behavior.
startOffset is a normal SVG 'length' attribute, so it accepts px/mm/em/etc values as well as percentages. Would this do what you need?
For the UI, personally I'd favour having a knot at the startOffset point, a bit like the ones used for manipulating spiral objects, which could just be dragged around.
Richard.
On Thu, Nov 24, 2005 at 12:22:54PM +0100, jiho wrote:
I was about to report my "experience" in using Inkscape for the production of scientific illustrations. Now appears to be a good time. Sorry its a long email...
Hi Jiho!
So first of all: it mostly works just great! Inkscape allowed me go completely open source in my scientific workflow (**see below) and
Very cool, I love seeing how Inkscape has grown from being "just" an art tool for making icons, to doing full portrait illustrations, posters, presentations, paint patterns for aircraft, and now even becoming useful to scientists. :-)
produce more easily illustrations which look as good or even better that what I used to do with illustrator. But... everything can be better, isn't it? So here are my problems/suggestions/... I tried to put them in decreasing order of importance.
1/ The bigger problem is probably that few scientific softwares produce plots in SVG (damn, why is that?!). They all export EPS and
This is probably because SVG is a fairly new standard, and not widely adopted yet. You could probably make a long term impact here quite easily by taking an afternoon and writing to each of these companies with a request to support SVG in a future version of their software.
the first problem is to get these EPS in Inkscape. At least on OS X, EPS import does not work because Inkscape cannot find pstoedit or ghostscript, though they are installed from fink. Where does inkscape takes the PATH from? With my fink tree added to the PATH in .bashrc or .profile in my home (.profile is the default) it does not work. With uberconverter on the way I hope all this will be solved in a not- so-far-away future.
The path stuff in Inkscape is a bit limited; it works sufficiently on linux but I'd have been surprised if it worked out of the box on OSX. I think it still doesn't work reliably on Windows.
If you'd like to dig into this problem, here are a couple starting points.
First, there is a directory where config files for the extensions are located. On Linux this is in /usr/share/inkscape/extensions. These don't include path info but you may find it illuminating to review their settings and so forth.
Second, the paths are set in the src/path-prefix.h file. There is a section for ENABLE_OSX_APP_LOCATIONS. If I were you, my first step would be to verify that this define is actually set correctly on your machine. If it is, then also doublecheck that the paths match up to what you have on your system.
Third, there is a little bit of path manipulation going on in src/main.cpp in the main() routine. See line 610 for instance, where the current homedir is set for WIN32. I don't see any OSX specific hacks there though.
2/ After some pstoedit command line stuff a second problem arises: all files converted this way are displayed fine in Inkscape but behave strangely: any new element is enormous, no dashes can be applied to existing strokes... This is all related to some strange transformation matrices. And some magic (from my point of view at least): copy-pasting all elements in a new document solves everything. Is there a reason why what is done when copying and pasting should not be done when opening the file?
You might browse through the XML editor or the SVG source for the original doc and see what parameters didn't get carried along in the cut-and-paste. Possibly the conversion process tweaked that parameter, leading to those problems.
The best solution would be to figure out which tool is introducing the breakage and fixing it, but if you can identify what parameter is getting mis-set, an easy workaround would be to write a little sed script to reset that to something sane, and include that in your conversion procedure.
3/ I found the Open/Save As/ menus not optimal.
[Interesting suggestions, I don't have any comments to add]
4/ Well real PDF export would be great, for nice keynote talks with beautiful transparency effects and all... Everybody knows. RFE: http://sourceforge.net/tracker/? group_id=93438&atid=604309&func=detail&aid=864260
Yes, this has been requested over and over and over... The hurdle we have to get across is to find a programmer to do the work of implementing it. We even have a few fairly good design ideas of how to achieve this, next we just need to see some folks with an interest in working on it.
I personally don't have much need for this feature, but I'd be willing to help get things started, if someone else would be able to take the lead on the actual development work. I know roughly what would need to be done to get the work organized, and would be more than happy to share the info.
5/ Arrows are important and svg markers are great. They could be even better if they followed the style of the stroke they are applied to.
Yes, this is something I am personally interested in working on. I've dug into the code and know exactly what needs to be coded; I just haven't had a good solid stretch of freetime to work on it. (The test harness has been a higher priority.) Again, if someone else would like to get involved in doing some C++ coding deep in Inkscape's guts, I'd be more than happy to share my notes and help get you started. If no one else does, I'll get to this eventually, but be patient as it may be a while...
6/ Text on path is good but, here again, the ability to displace the text along the path would make it much more valuable.
7/ Node snapping is the way to go for precise work. Nevertheless, it would be handy to have an option to put stroke inside or outside a shape (which is currently only partially feasible by snapping bounding boxes). But apparently it sound difficult in SVG.
Yeah I'd find that useful myself, good idea.
8/ "Font find and replace" would be a valuable addition to the Text and Font dialog. Sometimes you just get busted by a journal who wanted helvetica and times only and want to resubmit quickly to an other one who wants geneva and times new roman... RFE: http://sourceforge.net/tracker/index.php? func=detail&aid=1365463&group_id=93438&atid=604309
9/ Latex typesetting would be awesome (typesetting not graphical editing which seems impossible).
Yup.
10/ The "Grid" effect is useful but why is it limited to a maximum of 10 pixels grid squares? (in addition the unit is not displayed in the effect's dialog).
Are you sure? Can't this be controlled via File > Document Preferences > Grid ?
I'm always fiddling with the grid settings...
(Fwiw, I think the default grid settings are lame, and should be set to something more immediately useful. I'm sure this'd be an easy thing to change, I've just been too lazy to try to figure out what the best defaults would be.)
** For those who still have time to loose after this long email, here is a (confidential because not already published) draft of my article: "Movement analysis routine and circular statistics using free software". All vector illustrations are made with Inkscape. With such a title it would have been a shame to use something else that free software to write and illustrate the article!!! http://jo.irisson.free.fr/dropbox/inkscape/draft.pdf
Nice!
Bryce
On 24 nov. 05, at 19:34, Bryce Harrington wrote:
On Thu, Nov 24, 2005 at 12:22:54PM +0100, jiho wrote:
[snip]
1/ The bigger problem is probably that few scientific softwares produce plots in SVG (damn, why is that?!). They all export EPS and
This is probably because SVG is a fairly new standard, and not widely adopted yet. You could probably make a long term impact here quite easily by taking an afternoon and writing to each of these companies with a request to support SVG in a future version of their software.
All the one I use are open source projects so they all have nice mailing lists and request feature facilities. This request is already done. But unfortunately they evolve a "little" slower than Inkscape ;-)
the first problem is to get these EPS in Inkscape. At least on OS X, EPS import does not work because Inkscape cannot find pstoedit or ghostscript, though they are installed from fink. Where does inkscape takes the PATH from? With my fink tree added to the PATH in .bashrc or .profile in my home (.profile is the default) it does not work. With uberconverter on the way I hope all this will be solved in a not- so-far-away future.
The path stuff in Inkscape is a bit limited; it works sufficiently on linux but I'd have been surprised if it worked out of the box on OSX. I think it still doesn't work reliably on Windows.
If you'd like to dig into this problem, here are a couple starting points.
First, there is a directory where config files for the extensions are located. On Linux this is in /usr/share/inkscape/extensions. These don't include path info but you may find it illuminating to review their settings and so forth.
Second, the paths are set in the src/path-prefix.h file. There is a section for ENABLE_OSX_APP_LOCATIONS. If I were you, my first step would be to verify that this define is actually set correctly on your machine. If it is, then also doublecheck that the paths match up to what you have on your system.
Third, there is a little bit of path manipulation going on in src/main.cpp in the main() routine. See line 610 for instance, where the current homedir is set for WIN32. I don't see any OSX specific hacks there though.
I'll try to look at those. Thanks for the starting points.
2/ After some pstoedit command line stuff a second problem arises: all files converted this way are displayed fine in Inkscape but behave strangely: any new element is enormous, no dashes can be applied to existing strokes... This is all related to some strange transformation matrices. And some magic (from my point of view at least): copy-pasting all elements in a new document solves everything. Is there a reason why what is done when copying and pasting should not be done when opening the file?
You might browse through the XML editor or the SVG source for the original doc and see what parameters didn't get carried along in the cut-and-paste. Possibly the conversion process tweaked that parameter, leading to those problems.
I posted a diff between the faulty and the copy-pasted file (which behaves correctly). It's in the wiki page: http://wiki.inkscape.org/cgi-bin/wiki.pl?XML_Repair and there are a lot of changes between the two files. Many are attributes additions (inkscape:r_cx and cy) but there are a few transform which changed as in there:
< transform="translate(82.415,255.15) scale(1,-1) scale(1) " < style="font-family:'Helvetica',sans-serif;font-size: 9.4488;stroke:none;fill:black;" < id="text522">0</text> ---
transform="matrix(1,0,0,-1,82.415,255.15)" style="font-size:9.44880009px;fill:#000000;stroke:none;font-
family:"Helvetica", sans-serif"
id="text522" inkscape:r_cx="true" inkscape:r_cy="true">0</text>
in addition there is a scale parameter at the beginning of the file which looks weird and is not preserved by copy-paste in the new document:
< transform="translate(-0.03125,1.1875) scale(1,-1) scale (0.0017361) " < xml:space="preserve" < style="stroke:black;stroke-linecap:butt;stroke- linejoin:miter;stroke-miterlimit:10.433;stroke-dasharray:none;stroke- dashoffset:0;stroke-opacity:1;fill:none;fill-rule:even-odd;fill- opacity:1;font-style:normal;font-variant:normal;font- weight:normal;font-stretch:normal;font-size-adjust:none;letter- spacing:normal;word-spacing:normal;text-anchor:start;" < id="g10"> ---
inkscape:label="Layer 1" inkscape:groupmode="layer" id="layer1"> <rect x="-346.13388" y="258.07648" width="720" height="720" style="fill:#ffffff;stroke:none" id="rect8" inkscape:r_cx="true" inkscape:r_cy="true" /> <g transform="matrix(1.249992,0,0,-1.249992,-368.6339,1113.076)" xml:space="preserve" style="font-style:normal;font-variant:normal;font-
weight:normal;font-stretch:normal;letter-spacing:normal;word- spacing:normal;text-anchor:start;fill:none;fill-opacity: 1;stroke:#000000;stroke-linecap:butt;stroke-linejoin:miter;stroke- miterlimit:10.43299961;stroke-dasharray:none;stroke-dashoffset: 0;stroke-opacity:1"
id="g10" inkscape:r_cx="true" inkscape:r_cy="true">
could it be that?
The best solution would be to figure out which tool is introducing the breakage and fixing it, but if you can identify what parameter is getting mis-set, an easy workaround would be to write a little sed script to reset that to something sane, and include that in your conversion procedure.
In addition my point is not to find a way to sort it for my particular use (I'm quite happy with the copy paste even if it's an additional step) but I think that, as Inkscape is apparently capable of handling this, it should be done when first opening the file.
[snip again]
10/ The "Grid" effect is useful but why is it limited to a maximum of 10 pixels grid squares? (in addition the unit is not displayed in the effect's dialog).
Are you sure? Can't this be controlled via File > Document Preferences > Grid ?
I was talking about the Grid effect under Effects > Grid. not the alignement grid.
I'm always fiddling with the grid settings...
(Fwiw, I think the default grid settings are lame, and should be set to something more immediately useful. I'm sure this'd be an easy thing to change, I've just been too lazy to try to figure out what the best defaults would be.)
1px/1px is indeed a bit small. But I imagine that if inkscape started as a tool to design icons as you mentioned it has a nice historical value ;-) I guess that there is no perfect default. I would just suggest to base it on the default unit for the document. If your default unit is cm it's probably because you will do some printed work and your document will be quite large. On the contrary, if your unit is pixels it's because you are interested in some web or icon design. So basically doing 1/1 "default unit of the document" would be a not-so- bad rule of thumb for the default. Or maybe try to compute something a little more complicated based on the size of the document?
** For those who still have time to loose after this long email, here is a (confidential because not already published) draft of my article: "Movement analysis routine and circular statistics using free software". All vector illustrations are made with Inkscape. With such a title it would have been a shame to use something else that free software to write and illustrate the article!!! http://jo.irisson.free.fr/dropbox/inkscape/draft.pdf
Nice!
Thanks ;-)
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
jiho wrote:
I posted a diff between the faulty and the copy-pasted file (which behaves correctly). It's in the wiki page: http://wiki.inkscape.org/cgi-bin/wiki.pl?XML_Repair and there are a lot of changes between the two files. Many are attributes additions (inkscape:r_cx and cy) but there are a few transform which changed as in there:
Does anyone else think we could benefit from a button that optimises (removes) the transforms on a selection? I suppose someone could even code an effect to do this easily.
Aaron Spike
On 11/24/05, aaron@...749... <aaron@...749...> wrote:
Does anyone else think we could benefit from a button that optimises (removes) the transforms on a selection? I suppose someone could even code an effect to do this easily.
- switch to Optimize transforms in prefs
- nudge the object up and down with arrow keys
- done
Yes, this is clumsy, but it works. Is this really needed in practice often enough to warrant a button of its own?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 11/24/05, aaron@...749... <aaron@...749...> wrote:
Does anyone else think we could benefit from a button that optimises (removes) the transforms on a selection? I suppose someone could even code an effect to do this easily.
switch to Optimize transforms in prefs
nudge the object up and down with arrow keys
done
Yes, this is clumsy, but it works. Is this really needed in practice often enough to warrant a button of its own?
This is what I always do but I think I had the mistaken idea that it had to be done with the node tool. Thanks.
Aaron
On Thu, Nov 24, 2005 at 08:10:26PM +0100, jiho wrote:
2/ After some pstoedit command line stuff a second problem arises: all files converted this way are displayed fine in Inkscape but behave strangely: any new element is enormous, no dashes can be
I posted a diff between the faulty and the copy-pasted file (which behaves correctly). Many are attributes additions (inkscape:r_cx and cy) but there are a few transform which changed as in there:
< transform="translate(82.415,255.15) scale(1,-1) scale(1) " < style="font-family:'Helvetica',sans-serif;font-size: 9.4488;stroke:none;fill:black;"
< id="text522">0</text>
transform="matrix(1,0,0,-1,82.415,255.15)" style="font-size:9.44880009px;fill:#000000;stroke:none;font-
family:"Helvetica", sans-serif"
id="text522" inkscape:r_cx="true" inkscape:r_cy="true">0</text>
in addition there is a scale parameter at the beginning of the file which looks weird and is not preserved by copy-paste in the new document:
< transform="translate(-0.03125,1.1875) scale(1,-1) scale (0.0017361) "
This looks like the most interesting bit.
< xml:space="preserve" < style="stroke:black;stroke-linecap:butt;stroke- linejoin:miter;stroke-miterlimit:10.433;stroke-dasharray:none;stroke- dashoffset:0;stroke-opacity:1;fill:none;fill-rule:even-odd;fill- opacity:1;font-style:normal;font-variant:normal;font- weight:normal;font-stretch:normal;font-size-adjust:none;letter- spacing:normal;word-spacing:normal;text-anchor:start;"
< id="g10">
inkscape:label="Layer 1" inkscape:groupmode="layer" id="layer1"> <rect x="-346.13388" y="258.07648" width="720" height="720" style="fill:#ffffff;stroke:none" id="rect8" inkscape:r_cx="true" inkscape:r_cy="true" /> <g transform="matrix(1.249992,0,0,-1.249992,-368.6339,1113.076)"
The above line also looks interesting
xml:space="preserve" style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;letter-spacing:normal;word- spacing:normal;text-anchor:start;fill:none;fill-opacity: 1;stroke:#000000;stroke-linecap:butt;stroke-linejoin:miter;stroke- miterlimit:10.43299961;stroke-dasharray:none;stroke-dashoffset: 0;stroke-opacity:1"
id="g10" inkscape:r_cx="true" inkscape:r_cy="true">could it be that?
Yeah could be; next, experiment around with manually doing some of these changes and narrow in on which one is breaking.
In addition my point is not to find a way to sort it for my particular use (I'm quite happy with the copy paste even if it's an additional step) but I think that, as Inkscape is apparently capable of handling this, it should be done when first opening the file.
Well, probably not... It's probably a bug in the converter, so *that's* what should be fixed... In any case, narrow in on where the problem is being caused, and that should give a better indication where the fix should be applied.
Bryce
Coming from a science background, I couldn't agree more.
5/ Arrows are important and svg markers are great. They could be even better if they followed the style of the stroke they are applied to.
Yes, this is something I am personally interested in working on. I've dug into the code and know exactly what needs to be coded; I just haven't had a good solid stretch of freetime to work on it. (The test harness has been a higher priority.) Again, if someone else would like to get involved in doing some C++ coding deep in Inkscape's guts, I'd be more than happy to share my notes and help get you started. If no one else does, I'll get to this eventually, but be patient as it may be a while...
Bryce, I might be interested in implementing this. I've looked a bit at the code but would probably need some help to understand it fully. Can you outline what you think needs to be done? How would the use of style sheets effect this? And SVG 1.2 shadowInherit?
Another change would be to allow scaling the marker size relative to (or independently of?) the stroke width. This should be relatively easy to add if one can get the color to match since in both cases it appears to me that a copy of the marker must be stored in the def section. This would allow the elimination of the three different sizes for each marker type.
As a side note, there appears to be a problem with the current marker code. In looking at what needs to be done I copied the example code from:
http://www.w3.org/TR/SVG/painting.html#Markers
There are two versions, one using markers and one not, simulating what how the marker is drawn. Inkscape renders the two differently. The marker version is wrong according to the picture on the website. FireFox 1.5 renders them both the same. Doing a little research it appears that Inkscape does not use the viewBox attribute.
Tav
On Fri, Nov 25, 2005 at 10:54:06AM +0100, Tavmjong Bah wrote:
Coming from a science background, I couldn't agree more.
5/ Arrows are important and svg markers are great. They could be even better if they followed the style of the stroke they are applied to.
Yes, this is something I am personally interested in working on. I've dug into the code and know exactly what needs to be coded; I just haven't had a good solid stretch of freetime to work on it. (The test harness has been a higher priority.) Again, if someone else would like to get involved in doing some C++ coding deep in Inkscape's guts, I'd be more than happy to share my notes and help get you started. If no one else does, I'll get to this eventually, but be patient as it may be a while...
Bryce, I might be interested in implementing this. I've looked a bit at the code but would probably need some help to understand it fully. Can you outline what you think needs to be done? How would the use of style sheets effect this? And SVG 1.2 shadowInherit?
Sure, here's an outline of the steps I'd thought to take:
2. Cleanup * Improve documentation of marker code * Fix bug 1298718 - marker changes in xml editor don't immediately affect drawin * Fix bug 980157 - marker menus don't update on the change in document markers * FIXME in stock-items.cpp for sp_marker_load_from_svg * Remove all the marker_status stuff * Rename sp-marker.* to marker.*
3. Color Inheritance * Ensure that currentStroke, currentFill, and shadowInherit are in style-test.cpp, attributes-test.cpp and attributes.cpp * Ensure the following is parsed without generating errors: <marker shadowInherit="onUse" fill="currentStroke" id="something" ... /> * Find where markers are initially applied to a line - sp_copy_stuff_used_by_item (s/stuff/defs/?) - Add a check for the current line color - Add a marker ref pointing to the geom of the desired marker - Apply the correct style to the marker * Test on http://inkscape.org/wiki_uploads/xlink_marker.svg) * Implement option on the Stroke Style dialog for preventing marker from inheriting line style * Add shadowInherit property to sp-marker.h * Add support for shadowInherit, with values: - onDefine - like current behavior - onUse - what we want - dynamic - not sure... - none - don't know this one either * set default shadowInherit as follows: - for images, default is 'none' - for feImage, default is 'dynamic' - for pattern and marker, default is 'onDefine' * Add support for currentFill/currentStroke * Ensure when selecting a new marker, it re-colors appropriately
I've also got some tasks outlined for future work including 4. Make marker size settable, 5. Make xlink:href work on markers, 6. Marker selection UI, 7. Marker snapping/connecting improvement, and 8. On canvas marker editing, but I think the color style is the highest priority.
Another change would be to allow scaling the marker size relative to (or independently of?) the stroke width. This should be relatively easy to add if one can get the color to match since in both cases it appears to me that a copy of the marker must be stored in the def section. This would allow the elimination of the three different sizes for each marker type.
Right, see RFE 942486 for details. I think the UI for doing this would be the challenging part, but agree it's necessary if we want to allow a wider variety of markers, as having non-scalable markers is, er... not scalable.
As a side note, there appears to be a problem with the current marker code. In looking at what needs to be done I copied the example code from:
http://www.w3.org/TR/SVG/painting.html#Markers
There are two versions, one using markers and one not, simulating what how the marker is drawn. Inkscape renders the two differently. The marker version is wrong according to the picture on the website. FireFox 1.5 renders them both the same. Doing a little research it appears that Inkscape does not use the viewBox attribute.
Hmm, can you enter a bug on this one, if we don't already have one in the tracker? This sounds fairly important.
Bryce
jiho <jo.irisson@...400...> writes:
9/ Latex typesetting would be awesome (typesetting not graphical editing which seems impossible).
I know it's not answering your requirement, but let me mention that someone reported using the Latin Modern fonts (http://www.tug.org/tex-archive/fonts/lm/fonts/type1/public/lm/) in Inkscape to match the Computer Modern font he was using for the main text (where the drawings were imported).
I thought it could be done with a simple extension (as one feature request mention): calling latex on a text box, getting resulting ps, pstoedit it to svg and import the svg... but pstoedit traces the fonts and it looks terrible. I remember a linux vector editor which could typeset text boxes with pdflatex and include the pdf... but I cannot remember the name and can't find it (and it's not dia, sketch, karbon or sodipodi. xfig can do this but it was an other one).
Hmm, possibly metagraf? http://w3.mecanica.upm.es/metapost/metagraf.php
Cheers, Colin
On 24 nov. 05, at 22:59, Colin Marquardt wrote:
jiho <jo.irisson@...400...> writes:
9/ Latex typesetting would be awesome (typesetting not graphical editing which seems impossible).
I know it's not answering your requirement, but let me mention that someone reported using the Latin Modern fonts (http://www.tug.org/tex-archive/fonts/lm/fonts/type1/public/lm/) in Inkscape to match the Computer Modern font he was using for the main text (where the drawings were imported).
In fact I already have latex fonts (both serif, sans serif and symbols) available in ttf format. The problem is really to typeset equations/formulas rather than using consistent fonts (which is important indeed but which can be achieved without the need of latex itself).
I thought it could be done with a simple extension (as one feature request mention): calling latex on a text box, getting resulting ps, pstoedit it to svg and import the svg... but pstoedit traces the fonts and it looks terrible. I remember a linux vector editor which could typeset text boxes with pdflatex and include the pdf... but I cannot remember the name and can't find it (and it's not dia, sketch, karbon or sodipodi. xfig can do this but it was an other one).
Hmm, possibly metagraf? http://w3.mecanica.upm.es/metapost/ metagraf.php
nope. The software I cannot remember was up few years ago. It might well be a dead project by now... (It was in Mandrake 7 or 8).
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
On Thu, 2005-11-24 at 12:22 +0100, jiho wrote:
10/ The "Grid" effect is useful but why is it limited to a maximum of 10 pixels grid squares? (in addition the unit is not displayed in the effect's dialog).
I'm flexible on these, I just guessed for what reasonable settings should be. You can change them in:
/src/extensions/internal/grid.cpp
in the XML towards the bottom. If you find some you like, post 'em.
--Ted
On 28 nov. 05, at 07:37, Ted Gould wrote:
On Thu, 2005-11-24 at 12:22 +0100, jiho wrote:
10/ The "Grid" effect is useful but why is it limited to a maximum of 10 pixels grid squares? (in addition the unit is not displayed in the effect's dialog).
I'm flexible on these, I just guessed for what reasonable settings should be. You can change them in:
/src/extensions/internal/grid.cpp
in the XML towards the bottom. If you find some you like, post 'em.
Thanks for the pointer. My request is in fact a bit more than changing the limit ;-) Indeed I can probably find a good default for me but it won't be good for some others. What would be really great would be to be able to supply xspacing and yspacing in pixels or cm or pts... the default would depend on inkscape's document default unit. In addition, the upper limits should be defined by the height and width of the object selected. The lower limit being internal. I don't know if all this is difficult or not. I see there is already some code to get the bbox of the selection around line 60. I guess the rest is adding some conversion routines from cm, pts, m etc. to px in Grid::prefs_effect and adding some drop down menu in the dialog. I don't know how to get the default from inkscape documents preferences.
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
On Thu, 2005-11-24 at 12:22 +0100, jiho wrote:
3/ I found the Open/Save As/ menus not optimal.
I've always thought we should move towards:
-- Save
Save the current document with the current file name. Don't prompt if the file already exists.
-- Save As...
Choose a file name for the document, and save it as that name. Change the default name to be the one chosen here.
-- Save Copy...
Save the current document under a name given in the dialog. Do not change the default name for the document.
-- Export Bitmap...
Export the document to a bitmap. No effect on the current name.
-- Export Vector...
Export to a vectored format. Different from "Export Bitmap" in the settings that it will allow. I'd like to see this allow for things like "only in the drawing region" or "selected items" like the export bitmap feature.
-- Export Directory...
This is a place for special extensions like the webpage one. I think that it really needs to be it's own menu item because the interface is unique enough in choosing a directory and it will change the user's expectations of what will come next (i.e. more than one file name conflict).
--Ted
On Sun, 27 Nov 2005, Ted Gould wrote:
Date: Sun, 27 Nov 2005 22:44:38 -0800 From: Ted Gould <ted@...11...> To: jiho <jo.irisson@...400...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: [inkscape-devel] Re: save choices
On Thu, 2005-11-24 at 12:22 +0100, jiho wrote:
3/ I found the Open/Save As/ menus not optimal.
I've always thought we should move towards:
...
[Long list of high level menu items]
Although the logical seperation proposed is nice in some ways the downside is further overcrowding of the File menu. Also it means the drop down Type menu in the Save dialog (Inkscape SVG, Plain SVG, etc) would be remarkably empty and sparsely populated. More balance seems better.
I would suggest far less seperation (I'm unsure even if no seperation at all is such a bad idea and wouldn't rule it out). Inkscape could at aleast use Save and Save As for the Vector formats which should be lossless (at least in theory and I expect it would be the long term goal to correct any loss) namemly SVG, SVGZ, INKJAR, EPS, PS, PDF, DXF and others. (Also I think this is more like what others are doing.)
There is more to it than that but I did say I'd try and be more succint and that is the main thing I wanted to say.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On Mon, 2005-11-28 at 16:28 +0000, Alan Horkan wrote:
Although the logical seperation proposed is nice in some ways the downside is further overcrowding of the File menu. Also it means the drop down Type menu in the Save dialog (Inkscape SVG, Plain SVG, etc) would be remarkably empty and sparsely populated. More balance seems better.
I would suggest far less seperation (I'm unsure even if no seperation at all is such a bad idea and wouldn't rule it out). Inkscape could at aleast use Save and Save As for the Vector formats which should be lossless (at least in theory and I expect it would be the long term goal to correct any loss) namemly SVG, SVGZ, INKJAR, EPS, PS, PDF, DXF and others. (Also I think this is more like what others are doing.)
Yes...
I think pretty much the way it should break down is Save As for everything sufficiently vectory, and then the current Export bitmap option for any raster formats. Simple's good.
We might also eventually want an option for saving vector excerpts of the current file, too (like only the objects in the current selection and the gradients etc they depend on) but that's pretty much it.
-mental
MenTaLguY wrote:
On Mon, 2005-11-28 at 16:28 +0000, Alan Horkan wrote: ... I think pretty much the way it should break down is Save As for everything sufficiently vectory, and then the current Export bitmap option for any raster formats. Simple's good.
Simple interfaces are usually good, but too simply isn't. I'd definitely appreciate a Save Copy and/or Export (Vector) menu item too. I save the files I work on as Inkscape SVG, but when I want to distribute them for example I like to export them as plain SVG, this is currently possible but messes up things like the last directory I saved, the current filename, etc. It's workable, but clumsy.
Whether or not Export (Vector) and Save Copy should be separate is a different matter as far as I'm concerned and I don't feel strongly either way.
We might also eventually want an option for saving vector excerpts of the current file, too (like only the objects in the current selection and the gradients etc they depend on) but that's pretty much it.
That would definitely be useful, but not as a separate menu item if you ask me.
On 28 nov. 05, at 17:28, Alan Horkan wrote: On Sun, 27 Nov 2005, Ted Gould wrote:
Date: Sun, 27 Nov 2005 22:44:38 -0800 From: Ted Gould <ted@...11...> To: jiho <jo.irisson@...400...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: [inkscape-devel] Re: save choices
On Thu, 2005-11-24 at 12:22 +0100, jiho wrote:
3/ I found the Open/Save As/ menus not optimal.
I've always thought we should move towards:
...
[Long list of high level menu items]
Although the logical seperation proposed is nice in some ways the downside is further overcrowding of the File menu. Also it means the drop down Type menu in the Save dialog (Inkscape SVG, Plain SVG, etc) would be remarkably empty and sparsely populated. More balance seems better.
I would suggest far less seperation (I'm unsure even if no seperation at all is such a bad idea and wouldn't rule it out). Inkscape could at aleast use Save and Save As for the Vector formats which should be lossless (at least in theory and I expect it would be the long term goal to correct any loss) namemly SVG, SVGZ, INKJAR, EPS, PS, PDF, DXF and others. (Also I think this is more like what others are doing.)
The point of the export menu is that these formats are not lossless: - all of them loose at least inkscape specific preferences (grid, metadata and such) - some of them (EPS and PS for example) loose more than that: transparency is not preserved for example. so gradients using transparency (the default gradient in inkscape) will not work.
There is more to it than that but I did say I'd try and be more succint and that is the main thing I wanted to say.
Maybe a middle ground could be found: Open opens all vector documents (using input extensions if needed) and bitmap files. I don't bitmaps in here because it's confusing for the vector/bitmap difference but I can understand that from a user point of view it will be difficult to understand that he has to open an empty document and import the bitmap afterwards... though that's what illustrator does if I remember well. maybe insights on how others do will be interesting. Save saves current document with current name as Inkscape SVG/SVGZ (depending on current document). ask for a name only if the document is new. Save As saves as Inkscape SVG/SVGZ asking for a new name. The newly created document becomes the new one Import imports bitmap or vector files into current document. Export opens a tabbed window which allows bitmap export in one tab and vector export in the other. when the functionality will be present for vector export. the two tabs could share the "selection", "drawing", "page" and such buttons.
what about this?
JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/
I forgot two more items in my list:
- Aaron Spike was going to look into implementing node deletion in such a way as to preserve the existing shape as much as possible.
- We really need to make Extensions on by default in 0.44. It's been "experimental" too long. Anyone knows what is left to do for this?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Thu, Nov 24, 2005 at 11:59:35PM -0400, bulia byak wrote:
I forgot two more items in my list:
- Aaron Spike was going to look into implementing node deletion in
such a way as to preserve the existing shape as much as possible.
- We really need to make Extensions on by default in 0.44. It's been
"experimental" too long. Anyone knows what is left to do for this?
Agreed. Possibly some documentation is needed? You could look on the roadmap, I think the extension tasks were fairly well outlined there at one point.
Bryce
bulia byak wrote:
- Aaron Spike was going to look into implementing node deletion in
such a way as to preserve the existing shape as much as possible.
I started looking at this again today. It is probably quite simple to do.
I think node deletion starts here in nodepath.cpp at sp_node_selected_delete() http://www.inkscape.org/doc/doxygen/html/nodepath_8cpp.php#9f24fd43835361f84...
A function for evaluating bezier curves already exists in bezier-utils.cpp called bezier_pt() http://www.inkscape.org/doc/doxygen/html/bezier-utils_8cpp.php#10c13db1a5d67...
and the curve fitting function sp_bezier_fit_cubic() lives right in that same file http://www.inkscape.org/doc/doxygen/html/bezier-utils_8cpp.php#b8df2b5569532...
Like I said, it is probably very simple to hook this all up, I just can't bring myself to do any coding today.
Aaron Spike
On Thu, 2005-11-24 at 23:59 -0400, bulia byak wrote:
- We really need to make Extensions on by default in 0.44. It's been
"experimental" too long. Anyone knows what is left to do for this?
"Effects" :)
I think that there are really two gating items:
- Getting the menu to look better. I know how I'm going to do this, it won't take long. I just need to do it.
- Making the .inx files translatable. I'm not sure exactly how to do this, but I'm convinced it is possible with the tools we're using... but it is just going to take some frustration with the manuals. I will get to this, but I'd be very happy if someone else decided to take it on :)
--Ted
On 11/28/05, Ted Gould <ted@...11...> wrote:
On Thu, 2005-11-24 at 23:59 -0400, bulia byak wrote:
- We really need to make Extensions on by default in 0.44. It's been
"experimental" too long. Anyone knows what is left to do for this?
"Effects" :)
I think that there are really two gating items:
In addition to these, what about enabling them on Windows? I would very much prefer to avoid adding more platform-specific features (though this may be acceptable if we have no choice).
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Mon, 2005-11-28 at 03:07 -0400, bulia byak wrote:
On 11/28/05, Ted Gould <ted@...11...> wrote:
On Thu, 2005-11-24 at 23:59 -0400, bulia byak wrote:
- We really need to make Extensions on by default in 0.44. It's been
"experimental" too long. Anyone knows what is left to do for this?
"Effects" :)
I think that there are really two gating items:
In addition to these, what about enabling them on Windows? I would very much prefer to avoid adding more platform-specific features (though this may be acceptable if we have no choice).
Besides the issue of whether we ship Python with the Inkscape binary, I think that they do work on Windows. Anyone using Effects on Windows?
--Ted
participants (20)
-
unknown＠example.com -
Aaron and Sarah Spike -
aaron＠...749... -
Alan Horkan -
Bryce Harrington -
bulia byak -
Colin Marquardt -
Jasper van de Gronde -
jiho -
John Cliff -
John Taber -
Jon A. Cruz -
Jon Phillips -
Joshua A. Andler -
MenTaLguY -
Ralf Stephan -
Richard Hughes -
Tavmjong Bah -
Ted Gould -
Ulf Erikson