On 03/28/2011 02:31 PM, Josh Andler wrote:
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
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
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
appealing to you as well?
Well, as mentioned elsewhere in the thread, I'm open to working on SVG
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.)