Svg compliance has some real value in it, for instance the marker color issue, the bug for which is now 6 years old I believe! Fixing the flowtext issue would be a big one too. I'd probably rather see pages done as 'super groups' so that they all sit on top of each other so that you could copy/paste in place between them. Would also allow for a page master type layer at the bottom that was common for all.
Just my 2c
Cheers
John
Sent from my iPhone
On 29 Mar 2011, at 04:35, Jason Creighton <jcreigh@...400...> wrote:
On 03/28/2011 02:31 PM, Josh Andler wrote:
Hi Jason,
It's definitely something we'd like to see, however the question of if it's a viable (in terms of scope) GSoC project comes into play. Given that the proposed multipage from SVG 1.2 was dropped and it sounds like they make look into doing a simplified version for 2.0, it makes the question of data structure come into play. Also, there is the question of UI for it as well.
Given the above, what are your thoughts on how you would approach things?
Very roughly and very provisionally, I was thinking of something along these lines:
Pages would be spatially disjointed. Switching pages would be accomplished by an always-visible UI element, possibly in the statusbar at the bottom of the window. In addition, there would be a dockable UI element (not sure what you guys call them...like the layers UI or the fill and stroke UI) to manage pages. In that UI, you could add/delete/duplicate/reorder pages.
I'm tempted to just say that all the pages in a document would have to have the same dimensions. It seems like it would make things like printing/PDF export easier. OTOH, there's probably some use case for the other side, so I'm not sure.
I think that guides and layers should be per-page. It's tempting to want to make layers global, to simplify cases like copy+paste between pages of objects spanning multiple layers, but I think that solution would lead to some strange cases. For example, you might delete a layer, thinking you don't need it, only to realize that there were some objects in that layer on a different page that are now gone. So I think keeping things separate per-page is the sanest way to go.
Printing would work the way it does it almost all paginated content programs: Default to printing all the pages, offer an option in the print dialogue to do otherwise.
Exporting to paginated document types (PDF/PS/etc) would work in the obvious, straightforward way: Pages would be created in the exported document.
As far as storing the information in the SVG goes, since it appears there's no actual standard, I would propose storing the page information as some of metadata, like is currently done for layer information. The SVG would be saved in such a way that non-Inkscape viewers would only see the first page. Not ideal, of course, but I don't see a way around it.
One big-ish downside to all this is that if/when there's a "real" paginated SVG standard out there, Inkscape would have to deal with two different formats for pagination, which would be awkward. (If you load the old format, do you automatically save in the new format? But now an old version of Inkscape can't open it. etc...)
Is there anything else from http://wiki.inkscape.org/wiki/index.php/Google_Summer_Of_Code that looks appealing to you as well?
Well, as mentioned elsewhere in the thread, I'm open to working on SVG compliance issues.
Some of the projects look intriguing, for example, the importing of 3D scene files (because how would that even *work*?), but it's hard for me to imagine that such a feature would get much general usage.
Mostly I just want to work on something that's going to be generally useful/good for the project, as I think Inkscape is an absolutely fantastic program. The thing I want to avoid is some esoteric, gee-whiz feature that's seldom used. (Or even worse, never actually gets merged back to trunk.)
Jason
Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel