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?

Is there anything else from http://wiki.inkscape.org/wiki/index.php/Google_Summer_Of_Code that looks appealing to you as well?

Cheers, Josh

On Mon, Mar 28, 2011 at 11:07 AM, Jason Creighton <jcreigh@...400...> 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.

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

On 03/28/2011 02:54 PM, Alexandre Prokoudine wrote:

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.

Hmm, do you think there's enough compliance issues for an entire GSoC?

Regarding animation, while that would be really cool to work on, it seems to me that there are a large number of difficult, unresolved UI design issues there, so I would be nervous taking on something like that, as UI design is not my strong point. (If my impression is incorrect, and there's actually a more-or-less finished design somewhere for how the animation would work, please point me towards it.)

Jason

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

On 2011-03-29 3:26, Josh Andler wrote:

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?

There are probably enough "random" SVG compliance issues to last you a summer, but two of the specific areas that could use some love are: - Markers (especially their orientation) - Support for operating in the linearRGB color space (this basically affects EVERY filter we render, so it's not unimportant to fix asap). There are probably a few more (Tavmjong or ~suv will probably have a few more suggestions), but if you want to have a closer look yourself, there is a rendering test suite... (The wiki has instructions on how to get it and use it.) I would recommend anyone working on our compliance to update this to reflect changes in the W3C test suite and to use it to gauge their progress (this would of course be a perfectly valid part of such a GSoC project). It would even better if you improved the rendering test suite and/or made it more accessible.

Also, although not strictly compliance, we do have a long standing issue with paths that needs a solution and could use some good thinking. Basically the problem is that in SVG the "last" segment of a closed path HAS to be a line segment, but that we do NOT want to show expose this to the user (at least not always). So technically we should always show nodes for this last (often zero-length) segment, but this feels very unnatural, so we try to avoid that at all costs. The straightforward fix is to pretend the segment isn't there if it's zero length, but this gets problematic real soon when transformations and/or relative coordinates come into play. (I've suggested to the W3C that they fix this in SVG 2, as they're redesigning the path syntax anyway, but that'll probably take a decade or so.) So, can you think of a better solution? (This project might not be sufficient on its own, but could very well be part of a larger GSoC project.)

On 03/29/2011 08:29 AM, Tavmjong Bah wrote:

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:

[snip]

Very cool, thank you. I will definitely spend some time digging through this.

Cheers,

Jason

On Tue, Mar 29, 2011 at 10:39 AM, Alexandre Prokoudine < alexandre.prokoudine@...400...> wrote:

On 3/29/11, Tavmjong Bah wrote:

...

• Text Underlines.

Thousands of web designers would kill for this to be fixed :)

I think most of our userbase would kill for it too. If this were to get some love, it would be a huge win.

Cheers, Josh

On Tue, 2011-03-29 at 21:39 +0400, Alexandre Prokoudine wrote:

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?

It is still being debated. They will probably be kept but in a separate module.

There are those who find SVG fonts invaluable and those who loath them. Use on the web is held up by the lack of support in Firefox and IE (IE chose what to support by taking a union of the things supported in the most popular browsers at the time they began working on SVG support).

Font use can be divided into two classes. The first being artistic use such as found on posters. Here SVG fonts are excellent as they can be manipulated in different ways while still maintaining the semantics of the text (important for search-ability and for accessibility). The second class of font use is the layout of large sections of text as in an article. In this case, one is more concerned about the legibility of the text and the finer details of typesetting including the ability to handle complex writing systems. SVG fonts aren't as good for this purpose (this is why, I think Firefox has resisted implementing them). For this class of use, some people want to rely on other font technologies (e.g. woff) or in letting browsers handle the text (e.g. embedding HTML in SVG). I think both types of font use should be supported but most of the advocates for keeping or replacing SVG fonts think it is an either/or situation. For the Inkscape community, I think SVG fonts would be a real asset.

Tav

* Filters: Use of linearRGB. Use of primitiveFilterUnits (also add GUI). GUI for feImage's preserveAspectRatio. feTile. Fill Paint/Stroke Paint inputs. Many minor issues. (A good GSOC project would be to focus on filters with the addition of speeding up rendering by parallel processing.)

Of course I second that !

ivan

Thu, 31 Mar 2011 10:04:43 -0600 Jason Creighton <jcreigh@...400...> kirjoitti:

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?

Seems correct, yes. Implementing the color-interpolation-filters would probably include extending src/display/nr-filter-slot.{cpp,h} which does somewhat similar bitmap conversions already (though for orientation, not colour spaces).

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).

Just a note so you'll know what to expect. It's totally not meant to say that your plan for GSOC needs to include fix for this problem.

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).

Allowing higher colour depth to filter would be definitely a must !

ivan