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
Sent from my iPhone
On 29 Mar 2011, at 04:35, Jason Creighton <jcreigh@...> 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
> 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.)
> 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