Hi all,
As has been noted by Alexandre, the first public draft of SVG 2.0 has been released:
http://www.w3.org/TR/2012/WD-SVG2-20120828/
While this is a very early draft and will be unstable for some time, I don't think it is too early to make plans on how Inkscape will handle incorporating new SVG feature. SVG 2.0 will bring many things that will benefit Inkscape. Here are just a few:
Mesh Gradients New blend modes New ways to specify color (CSS3 Color) Named colors Markers inheriting stroke color Hash lines Variable stroke placement (inside/outside path) Fill over stroke 3D transforms
Before I make a proposal, I will review the status of the SVG in general. As many of you know, SVG as a standard almost died when Adobe bought Flash. (Adobe was the main driver behind SVG at the beginning.) The SVG Working Group (WG), which once had more members than the CSS WG, shrunk to just a handful of active participants. With SVG now being a core component of HTML5 and with SVG being added to IE 9 and the decision by Adobe to stop development work on Flash, interest in SVG has grown. New members have joined the WG over the past year. (The group is still smaller than the CSS WG which limits the speed that the SVG 2 specification is developed as well as what can be added.) In addition to renewed interest in SVG proper, there is interest in adapting many SVG features for more general use on the Web. Many parts of the SVG specification are being ripped out and made into stand-alone specifications shared with the CSS WG. These include Transforms, Blend modes, Filters, and Colors. These sections are maturing fast and experiencing rapid adoption by browser vendors. You can already use HSL colors (from CSS3 Colors) inside SVG in current versions of all major browsers. Transformations should be usable soon. In summary, SVG is moving forward and doing so rather quickly.
How should Inkscape handle new features?
First of all, as Josh has stated, we don't want a repeat of the flowtext fiasco where Inkscape implemented a feature that ended up not being added to the SVG specification. We should only enable stable features in our official releases. One indication of stability is the implementation of a new feature by one or more browser vendors without using a vendor specific prefix. HSL color is one example of this.
We should encourage new features in unstable releases. It is important to the SVG specification development that there are working examples, even if only partially implemented, as it demonstrates a user desire for the feature and it gives the WG a chance to test and experiment with it.
Second we should be backwards compatible with SVG 1.1 when feasible. By backwards compatible, I mean being able to read and write SVG 1.1 files. Some things are relatively simple to handle. HSL colors can be easily converted to RGB colors. Others like mesh gradients may require using a PNG.
What I propose, is that as new features become stable, we modify the internal Inkscape code to use them while at the same time adding an option to export to SVG 1.1. In many cases, this will have the side benefit of simplifying our code. For example, matching marker color to stroke color now requires some rather complex code to create new copies of a marker for each different colored path as well as monitor changes to stroke and fill color.
What do others think?
Tav
On Fri, Aug 31, 2012 at 1:27 PM, Tavmjong Bah wrote:
New blend modes
Speaking of which, is it still the consensus that we should not provide blending options on per-object basis? I know it's hell, because it's about attaching an SVG filter, so applying a new filter to it kicks blending out. Nevertheless...
We should encourage new features in unstable releases. It is important to the SVG specification development that there are working examples, even if only partially implemented, as it demonstrates a user desire for the feature and it gives the WG a chance to test and experiment with it.
Agreed
Second we should be backwards compatible with SVG 1.1 when feasible. By backwards compatible, I mean being able to read and write SVG 1.1 files. Some things are relatively simple to handle. HSL colors can be easily converted to RGB colors. Others like mesh gradients may require using a PNG.
What I propose, is that as new features become stable, we modify the internal Inkscape code to use them while at the same time adding an option to export to SVG 1.1. In many cases, this will have the side benefit of simplifying our code. For example, matching marker color to stroke color now requires some rather complex code to create new copies of a marker for each different colored path as well as monitor changes to stroke and fill color.
What do others think?
Agreed :)
Alexandre Prokoudine http://libregraphicsworld.org
Fri, 31 Aug 2012 13:55:17 +0400 Alexandre Prokoudine <alexandre.prokoudine@...400...> kirjoitti:
New blend modesSpeaking of which, is it still the consensus that we should not provide blending options on per-object basis? I know it's hell, because it's about attaching an SVG filter, so applying a new filter to it kicks blending out. Nevertheless...
With blending implemented as filters, there's also the double-counting background issue. IIRC that was the original reason why blending was changed from per-object setting to per-layer setting.
Hi all,
the SVG 2 draft could bring very interesting features. Native CMYK colors could be a huge boost for print work.
Le 31/08/12 11:55, Alexandre Prokoudine a écrit :
New blend modesSpeaking of which, is it still the consensus that we should not provide blending options on per-object basis? I know it's hell, because it's about attaching an SVG filter, so applying a new filter to it kicks blending out. Nevertheless...
Naive user comment, with no idea of the technical constraints :
* Blend modes "seem to behave" as if it is applied on a per-object basis : if I copy an object from a blended layer into a "normal" layer, the blending seems to be kept on the object (inline+filter?). It would seem more logical to me that the object inherit the "normal" blending mode of it's new parent layer.
* Slightly related : The layer panel could gain a lot of usability if it was possible to display hierarchically not only layers and sub-layers, but also groups and objects. File structure and applied filters/blending modes could be more understandable and discoverable IMHO. The Blender Outliner[1], might illustrate the idea. It helps to understand/display the file structure, and see the applied filters/modifiers in a glimpse.
Reading the list to understand the development process, and would love to contribute code one day if possible, please tell if simple commenting is inappropriate here!
Thanks for your great work !
Victor
[1] http://www.blender.org/development/release-logs/blender-235a/outliner/
On Fri, Aug 31, 2012 at 7:20 PM, Victor / tokiop wrote:
Hi all,
the SVG 2 draft could bring very interesting features. Native CMYK colors could be a huge boost for print work.
Not until you get Inkscape exporting color separated PDF files :)
Which won't happen until someone finally talks to Adrian about the API for color management in Cairo, which will be the first step towards the goal.
You can have correct CMYK values in Inkscape right now. This is not a problem at all. The problem is in exporting.
- Slightly related : The layer panel could gain a lot of usability if it
was possible to display hierarchically not only layers and sub-layers, but also groups and objects. File structure and applied filters/blending modes could be more understandable and discoverable IMHO. The Blender Outliner[1], might illustrate the idea. It helps to understand/display the file structure, and see the applied filters/modifiers in a glimpse.
Agreed :)
Alexandre Prokoudine http://libregraphicsworld.org
Le 31/08/12 17:45, Alexandre Prokoudine a écrit :
You can have correct CMYK values in Inkscape right now. This is not a problem at all. The problem is in exporting.
Straight CMYK-pdf export from inkscape would sure be very nice.
In the meanwhile using Scribus seems to be the preferred way to export print-quality CMYK pdfs; and is sometime required, if the svg is only part of a composition.
One of the pitfalls is the need to verify/convert the "RGB-from-svg" colors to CMYK ones, at every import/update of the svg graphics. I might be missing an obvious step here..
If the step is actually missing, wouldn't storing the raw CMYK color values in the svg from inkscape, and reading them back in Scribus, be an easier step before a full print export from inkscape ?
Inkscape and Scribus are very related for libre-print workflow, and a lot of features/planned features seem to overlap (pdf export, mutli-page, vector edition, vector rendering), each software having it's own (very strong) benefits. Svg 2.0 draft with CMYK support could opens an "official" link between the two.
How are the communities/devs related ? Are there any discussions to help inter-operability or develop overlapping features in common ?
Software inter-operability is a strength and big lock-in of the proprietary-workflow. Technically it should be less difficult to address in an open format and open source environment, but i guess it requires much social work/coordination too..
- Slightly related : The layer panel could gain a lot of usability if it
was possible to display hierarchically not only layers and sub-layers, but also groups and objects. File structure and applied filters/blending modes could be more understandable and discoverable IMHO. The Blender Outliner[1], might illustrate the idea. It helps to understand/display the file structure, and see the applied filters/modifiers in a glimpse.
Agreed:)
Cool ! I guess i should start diggin/diffing the code then ! No knowledge for now, but eager to learn !
Cheers,
Victor
On Fri, Aug 31, 2012 at 8:16 PM, Victor / tokiop wrote:
One of the pitfalls is the need to verify/convert the "RGB-from-svg" colors to CMYK ones, at every import/update of the svg graphics. I might be missing an obvious step here..
You are :)
http://libregraphicsworld.org/blog/entry/getting-cmyk-colors-from-inkscape-t...
If the step is actually missing, wouldn't storing the raw CMYK color values in the svg from inkscape, and reading them back in Scribus, be an easier step before a full print export from inkscape ?
It wouldn't. Uncalibrated workflow generally isn't safe. Even Corel DRAW matches CMYK values to a gamut defined by a certain ICC profile internally. Which is exactly what Inkscape can do for you. See the link above.
How are the communities/devs related ? Are there any discussions to help inter-operability or develop overlapping features in common ?
As far as I can tell, there is little communication between the two projects lately.
Alexandre Prokoudine http://libregraphicsworld.org
Le 31/08/12 20:13, Alexandre Prokoudine a écrit :
On Fri, Aug 31, 2012 at 8:16 PM, Victor / tokiop wrote:
One of the pitfalls is the need to verify/convert the "RGB-from-svg" colors to CMYK ones, at every import/update of the svg graphics. I might be missing an obvious step here..
You are:) http://libregraphicsworld.org/blog/entry/getting-cmyk-colors-from-inkscape-t...
Glad of it !! It's great, will test ASAP.. sorry for the noise !
How are the communities/devs related ? Are there any discussions to help inter-operability or develop overlapping features in common ?
As far as I can tell, there is little communication between the two projects lately.
Ok thanks !
Victor
On 31-08-12 20:24, Victor / tokiop wrote:
How are the communities/devs related ? Are there any discussions to help inter-operability or develop overlapping features in common ?
As far as I can tell, there is little communication between the two projects lately.
Ok thanks !
If you (or anyone else) wants to work on that, the Libre Graphics Meeting is usually a good place to meet people from Scribus, the GIMP and other graphics projects. Last LGM we actually had some (informal) discussions on the ways in which the different projects could cooperate and make it easier to support a combined workflow.
In my opinion, one of the most interesting strategies in that regard would be to try and adopt GEGL as a common "rendering engine". This would make sure that projects basically all have the same capabilities underneath. (For me personally the main blocker is currently that I cannot build it on Windows. There are cross-compiled binaries that we could probably use though, so it's not necessarily a blocker for Inkscape in general.)
Another thing that came up was that it would make a huge difference if everyone would automatically reload external dependencies when changed. For example, suppose you have an SVG with a bitmap inside that is simply linked to an external PNG or so. You could then be working on the PNG in the GIMP and each time you saved it would automatically update in Inkscape.
On Mon, Sep 3, 2012 at 12:08 PM, Jasper van de Gronde wrote:
Another thing that came up was that it would make a huge difference if everyone would automatically reload external dependencies when changed. For example, suppose you have an SVG with a bitmap inside that is simply linked to an external PNG or so. You could then be working on the PNG in the GIMP and each time you saved it would automatically update in Inkscape.
Actually, GEGL supports sharing buffers. So you don't even need to save/export per se :)
Alexandre Prokoudine http://libregraphicsworld.org
On 03/09/2012 10:08, Jasper van de Gronde wrote:
Another thing that came up was that it would make a huge difference if everyone would automatically reload external dependencies when changed. For example, suppose you have an SVG with a bitmap inside that is simply linked to an external PNG or so. You could then be working on the PNG in the GIMP and each time you saved it would automatically update in Inkscape.
Such a workflow is already supported by Inkscape: http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#Editing_bitmaps_in_an_external_editor If a linked bitmap image file changes on disk, it is automatically updated in Inkscape [1].
Note: JazzyNico added support for externally editing linked bitmap images (via context menu entry of a linked bitmap image) for the Windows port of Inkscape in trunk: https://bugs.launchpad.net/inkscape/+bug/262617
~suv
[1] (exception: the clones of such linked bitmap images currently are not updated without extra efforts: https://bugs.launchpad.net/inkscape/+bug/822468)
Le 03/09/12 10:08, Jasper van de Gronde a écrit :
If you (or anyone else) wants to work on that, the Libre Graphics Meeting is usually a good place to meet people from Scribus, the GIMP and other graphics projects. Last LGM we actually had some (informal) discussions on the ways in which the different projects could cooperate and make it easier to support a combined workflow.
Thanks for the pointer ! Will watch for it but will probably need much work to be of any use there.. love to listen to interesting talks anyway !
Another thing that came up was that it would make a huge difference if everyone would automatically reload external dependencies when changed. For example, suppose you have an SVG with a bitmap inside that is simply linked to an external PNG or so. You could then be working on the PNG in the GIMP and each time you saved it would automatically update in Inkscape.
I agree, and this feature in Inkscape is already very efficient and useful ! Such feature between Scribus and Inkscape would be great !
Victor
On 31-08-12 11:27, Tavmjong Bah wrote:
... What I propose, is that as new features become stable, we modify the internal Inkscape code to use them while at the same time adding an option to export to SVG 1.1. In many cases, this will have the side benefit of simplifying our code. For example, matching marker color to stroke color now requires some rather complex code to create new copies of a marker for each different colored path as well as monitor changes to stroke and fill color.
What do others think?
I think this might tie in nicely with the idea that came up recently for creating a kind of "test build" or (set of) option(s), which would enable all sorts of experimental features, to get more feedback.
On Fri, 2012-08-31 at 11:27 +0200, Tavmjong Bah wrote:
What I propose, is that as new features become stable, we modify the internal Inkscape code to use them while at the same time adding an option to export to SVG 1.1. In many cases, this will have the side benefit of simplifying our code. For example, matching marker color to stroke color now requires some rather complex code to create new copies of a marker for each different colored path as well as monitor changes to stroke and fill color.
What do others think?
I think that's a good idea. What I had started on a long time ago, and never finished (and it probably won't even merge today) was looking it from the perspective of profiles. I guess what I'm unsure of is "2.0 vs. 1.1" enough. Or are designers/developers of web stuff thinking more "I need to target Firefox X to Y and IE version so and so", etc. In the end that might end up dropping some features of 1.1 but adding others from 2.0. Or SVG Tiny, etc.
I realize that it makes the whole thing much more complex, but it seems like relying on the standards to version things might turn out to not be useful in the real world.
--Ted
participants (7)
-
Alexandre Prokoudine -
Jasper van de Gronde -
Niko Kiirala -
Tavmjong Bah -
Ted Gould -
Victor / tokiop -
~suv