Hi All, I'm a student considering applying to GSoC for Inkscape, and I'm wondering how you guys feel about multipage support as a project. I asked about this on the IRC channel and it was pointed out to me that multipage support was dropped from SVG 1.2, so the state of this in the SVG standard is kind of up in the air. Is the lack of an official standard a show-stopper? If not, is this even something you'd like to see worked on at this time? Or are there other, more pressing, features or issues that you'd prefer to see applications on? Thanks, Jason ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On 3/28/11, Jason Creighton wrote: > Hi All, > > I'm a student considering applying to GSoC for Inkscape, and I'm > wondering how you guys feel about multipage support as a project. > > I asked about this on the IRC channel and it was pointed out to me that > multipage support was dropped from SVG 1.2, so the state of this in the > SVG standard is kind of up in the air. SVG 1.2 was dropped itself in favour of 2.0. Please check http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap It does mention pagination, but the spec is nowhere close to being ready. Instead how about better SVG compliance? It's not that fancy, but still very important for the project. Or animation.

On Mon, Mar 28, 2011 at 6:18 PM, Jason Creighton <jcreigh@...400... <mailto:jcreigh@...400...>> wrote: On 03/28/2011 02:54 PM, Alexandre Prokoudine wrote: > > Instead how about better SVG compliance? It's not that fancy, but > still very important for the project. Or animation. Hmm, do you think there's enough compliance issues for an entire GSoC? Way more than one student can handle in one summer project. So, on that note, it's a GREAT area to choose from. Tavmjong, would you mind chiming in on some of the more "important" compliance issues that you think may be viable to be part of GSoC work?

Hi, There are certainly enough SVG compliance issues to fill a GSOC. As Jasper mentions Markers and linearRGB are two items but there are many more. Here is a quick list:

On 3/29/11, Tavmjong Bah wrote: > * Text > Underlines. Thousands of web designers would kill for this to be fixed :)

On 3/29/11, Tavmjong Bah wrote: > * SVG Fonts Wasn't there a plan to redo them in 2.0? Or am I mixing things up?

I just want to make sure I understand roughly what this one would entail. As I understand it, we're talking about supporting the linearRGB colorspace as described here: http://www.w3.org/TR/SVG/painting.html#RenderingProperties throughout the filter stack. If I read the standard correctly, the "color-interpolation-filters" property applies to filter primitives, which I think means that you could have one primitive using sRGB and another using linearRGB in the same filter. This would seem to require that each bitmap in the filtering chain gets tagged with what its colorspace is, with conversions being done as needed before each filter primitive is applied. Hopefully the common case would be either sRGB or linearRGB being used in the entire filter, but we'd have to support the general case. Is that basically right?

For good results even more work may be needed than it seems. As it stands, filter primitives operate on ordinary 8-bits-per-channel RGBA images. Converting such image from sRGB to linear, filtering and converting back to sRGB will lose quite a bit of colour information. This could result in things like banding. The fix would be to use higher colour depth for the intermediate images (there are other reasons to do this, too).