clipping and filters, import and export for formats other than SVG?
SVG supports both clipping and filters. Some other formats do as well, for instance, EMF+, (although the supported filters do not match very well between SVG and EMF+).
I can see how one would convert those features from other graphics formats to SVG during import (more or less).
However, for output to another file type I do not see where either the clipping or filters would be passed, perhaps buried in style?
I thought that maybe the clipping was applied upstream somehow, so that the driver level would just draw what was left, but could not test the idea because it seems that clipping has some problems in Trunk right now.
For instance, I found this SVG example on the web:
http://svg-whiz.com/svg/clipRect.svg
and while it loaded into Inkscape (linux or Windows) without throwing a warning or error, and the contents show up in the XML editor, nothing is visible on the screen. That example works in 0.48.4, but not r12721.
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 2013-10-28 21:38 +0200, mathog wrote:
I thought that maybe the clipping was applied upstream somehow, so that the driver level would just draw what was left, but could not test the idea because it seems that clipping has some problems in Trunk right now.
For instance, I found this SVG example on the web:
http://svg-whiz.com/svg/clipRect.svg
and while it loaded into Inkscape (linux or Windows) without throwing a warning or error, and the contents show up in the XML editor, nothing is visible on the screen. That example works in 0.48.4, but not r12721.
Zoom to drawing content (keyboard shortcut '4') to view the content.
This SVG file has width=height=100% and no viewBox attribute:
<svg width='100%' height='100%' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'>
which results in a miniscule (1x1 px) document page size with current trunk (rev >= 12554). Other than that, the drawing content and the clipped objects displays correctly AFAICT.
Regards, V
2013/10/29 su_v <suv-sf@...58...>:
This SVG file has width=height=100% and no viewBox attribute:
<svg width='100%' height='100%' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink'>
which results in a miniscule (1x1 px) document page size with current trunk (rev >= 12554). Other than that, the drawing content and the clipped objects displays correctly AFAICT.
Does anyone know what are we supposed to do in this case? I don't think it's even valid SVG.
Regards, Krzysztof
On Wed, 2013-10-30 at 17:36 +0100, Krzysztof Kosiński wrote:
Does anyone know what are we supposed to do in this case? I don't think it's even valid SVG.
According to the svg 1.1 spec:
The length definition type must specify what the '%' is relative to:
http://www.w3.org/TR/SVG/types.html#DataTypeLength (see percentage further down and the css percentage definition)
http://www.w3.org/TR/SVG/struct.html#SVGElementHeightAttribute
So this says basically that it's relative to the space it's being used in as a fragment.
I'd take our workspace at 1:1 and use that. Otherwise it's not really a useful value since the svg isn't being used as a fragment.
Or at least that's my understanding of what it's saying.
Martin,
2013/10/30 Martin Owens <doctormo@...400...>:
I'd take our workspace at 1:1 and use that. Otherwise it's not really a useful value since the svg isn't being used as a fragment.
I don't know what do you mean by "workspace". We have the concept of page size, but it just corresponds to the size specified on the SVG element.
Perhaps we should pick some totally arbitrary default values in this case, such as 640x480px.
Regards, Krzysztof
On Wed, 2013-10-30 at 19:51 +0100, Krzysztof Kosiński wrote:
I don't know what do you mean by "workspace". We have the concept of page size, but it just corresponds to the size specified on the SVG element.
Workspace is the visible area without scrolling from chrome to chrome inside which drawings can be made.
The space where work can take place.
It's not arbitrary, but it would change from machine to machine. It depends what the contents of the document are, but we should assume that the document is designed to deal with a stretched page size.
Martin,
2013/10/28 mathog <mathog@...1176...>:
SVG supports both clipping and filters. Some other formats do as well, for instance, EMF+, (although the supported filters do not match very well between SVG and EMF+).
I can see how one would convert those features from other graphics formats to SVG during import (more or less).
However, for output to another file type I do not see where either the clipping or filters would be passed, perhaps buried in style?
I thought that maybe the clipping was applied upstream somehow, so that the driver level would just draw what was left, but could not test the idea because it seems that clipping has some problems in Trunk right now.
I think the API used to implement WMF/EMF export does not support clipping at all.
There are in fact 4 distinct ways to implement an output extension in Inkscape:
1. Use the interactive, bitmap-oriented Cairo renderer (the show() / hide() functions, and the objects in src/display) - this is used for canvas, PNG export, icon previews. 2. Use the offline, vector-oriented Cairo renderer (src/extension/internal/cairo-*) - this is used for PDF / PS export. 3. Use the print functions on SPObjects via print.h - this is used by WMF / EMF export and one more output extension, but I don't remember which one. 4. Directly access the SP tree to extract the relevant information.
Approaches 1 and 2 support clipping, 4 supports it if you implement it, while 3 does not support it at all; there is no print function on clipping paths or masks.
The 100% proper way to support WMF / EMF export would be to create a Cairo backend for this, but that's rather hard and requires working closely with upstream - Cairo doesn't support user backends.
Regards, Krzysztof
On 30-Oct-2013 09:45, Krzysztof Kosiński wrote:
There are in fact 4 distinct ways to implement an output extension in Inkscape:
- Use the interactive, bitmap-oriented Cairo renderer (the show() /
hide() functions, and the objects in src/display) - this is used for canvas, PNG export, icon previews. 2. Use the offline, vector-oriented Cairo renderer (src/extension/internal/cairo-*) - this is used for PDF / PS export. 3. Use the print functions on SPObjects via print.h - this is used by WMF / EMF export and one more output extension, but I don't remember which one. 4. Directly access the SP tree to extract the relevant information.
Approaches 1 and 2 support clipping, 4 supports it if you implement it, while 3 does not support it at all; there is no print function on clipping paths or masks.
I just tried printing a drawing with clipping to a postscript printer. As you said it would be, all clipping is lost.
Is this not a bug? I don't think end users would expect that. It makes Inkscape a "WYSIWYG (except clipping)" program!
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On Wed, Oct 30, 2013 at 1:03 PM, mathog <mathog@...1176...> wrote:
I just tried printing a drawing with clipping to a postscript printer. As you said it would be, all clipping is lost.
Yeah, Inkscape REALLY sucks when it comes to printing. My process has always been to save as a PDF and print from a PDF reader because the experience with Inkscape is just awful.
Is this not a bug? I don't think end users would expect that. It makes Inkscape a "WYSIWYG (except clipping)" program!
As mentioned above, it's worse than just the clipping, you can probably find a ton of bugs in our tracker related to printing.
Cheers, Josh
On Wed, 2013-10-30 at 13:14 -0700, Josh Andler wrote:
As mentioned above, it's worse than just the clipping, you can probably find a ton of bugs in our tracker related to printing.
Should we disable printing? It would make sure that people export as pdf and can see what they'd be getting. Is there any advantage over a pdf print to direct inkscape printing?
Martin,
On 30-Oct-2013 13:37, Martin Owens wrote:
On Wed, 2013-10-30 at 13:14 -0700, Josh Andler wrote:
As mentioned above, it's worse than just the clipping, you can probably find a ton of bugs in our tracker related to printing.
Should we disable printing? It would make sure that people export as pdf and can see what they'd be getting. Is there any advantage over a pdf print to direct inkscape printing?
If it is broken we should fix the printing. Users generally expect that they can print whatever they see before them on the work surface of a program.
Can somebody give a brief description of the print subsystem? I can't think of a reason why clipping wouldn't work, as it generates (ultimately) postscript output for postscript printers, and postscript does support clipping. Transparency is another kettle of fish. Presumably any sort of transparency on a vector object is going to force a conversion to a bitmap and that, rather than the original vector objects, is sent to the printer.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
participants (5)
-
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
mathog -
su_v