Re: [Inkscape-devel] [Inkscape-user] Filters Not Saved with PNG
Chris Lilley wrote:
On Saturday, January 16, 2010, 10:32:16 PM, knowone wrote: ... k> How can I save the file as PNG with the drop shadow intact?
Make sure you are exporting as PNG. Do not 'Save As' Cairo PNG.
(I came across this a couple of days ago, and the symptom was that blur filters were not being applied. Also, the pixel dimensions of the two methods differ, if the graphic bleeds over the edge of the 'page').
Can someone tell me why we have a non-vector format in the save as list? One that seems redundant and apparently with less functionality than the normal export. Is this for testing purposes?
On Tue, 2010-01-19 at 11:00 +0100, Jasper van de Gronde wrote:
Chris Lilley wrote:
On Saturday, January 16, 2010, 10:32:16 PM, knowone wrote: ... k> How can I save the file as PNG with the drop shadow intact?
Make sure you are exporting as PNG. Do not 'Save As' Cairo PNG.
(I came across this a couple of days ago, and the symptom was that blur filters were not being applied. Also, the pixel dimensions of the two methods differ, if the graphic bleeds over the edge of the 'page').
Can someone tell me why we have a non-vector format in the save as list? One that seems redundant and apparently with less functionality than the normal export. Is this for testing purposes?
Yes, it was for testing the Cairo output. It was part of the GSoC project to do PDF output, and was easy enough to add, so we left it in for testing Cairo rendering. Now, is anyone using it for anything now? Bulia? I'd imagine at this point it's cruft.
--Ted
On Tue, Jan 19, 2010 at 11:39 AM, Ted Gould <ted@...11...> wrote:
Yes, it was for testing the Cairo output. It was part of the GSoC project to do PDF output, and was easy enough to add, so we left it in for testing Cairo rendering. Now, is anyone using it for anything now? Bulia? I'd imagine at this point it's cruft.
It still can be useful for testing our cairo interfaces, because it uses basically the same renderer as PS or PDF exporter, but of course it must be hidden in the user-visible list. Is that possible? If not then it should be removed.
On Tue, 2010-01-19 at 12:48 -0400, bulia byak wrote:
On Tue, Jan 19, 2010 at 11:39 AM, Ted Gould <ted@...11...> wrote:
Yes, it was for testing the Cairo output. It was part of the GSoC project to do PDF output, and was easy enough to add, so we left it in for testing Cairo rendering. Now, is anyone using it for anything now? Bulia? I'd imagine at this point it's cruft.
It still can be useful for testing our cairo interfaces, because it uses basically the same renderer as PS or PDF exporter, but of course it must be hidden in the user-visible list. Is that possible? If not then it should be removed.
How would people use it then? From the command line? We could disable and reenable it for releases, but that seems kinda bad in that we'd then have developers and users using different builds.
--Ted
On Thu, 2010-01-21 at 22:53 -0600, Ted Gould wrote:
On Tue, 2010-01-19 at 12:48 -0400, bulia byak wrote:
On Tue, Jan 19, 2010 at 11:39 AM, Ted Gould <ted@...11...> wrote:
Yes, it was for testing the Cairo output. It was part of the GSoC project to do PDF output, and was easy enough to add, so we left it in for testing Cairo rendering. Now, is anyone using it for anything now? Bulia? I'd imagine at this point it's cruft.
It still can be useful for testing our cairo interfaces, because it uses basically the same renderer as PS or PDF exporter, but of course it must be hidden in the user-visible list. Is that possible? If not then it should be removed.
How would people use it then? From the command line? We could disable and reenable it for releases, but that seems kinda bad in that we'd then have developers and users using different builds.
Developers and users are almost always using different builds by default. But I think most developers also keep the last official release installed too for testing purposes.
Either way, as I understand it, if you open (rather than import) a PNG file, draw on top of it or modify it, and hit "Save" it will save via Cairo and not our export method.
Cheers, Josh
On Fri, Jan 22, 2010 at 1:08 AM, Joshua A. Andler <scislac@...400...> wrote:
Either way, as I understand it, if you open (rather than import) a PNG file, draw on top of it or modify it, and hit "Save" it will save via Cairo and not our export method.
Instead it must simply refuse to save as PNG, offering a Save As dialog to save as SVG.
On Fri, 2010-01-22 at 01:40 -0400, bulia byak wrote:
On Fri, Jan 22, 2010 at 1:08 AM, Joshua A. Andler <scislac@...400...> wrote:
Either way, as I understand it, if you open (rather than import) a PNG file, draw on top of it or modify it, and hit "Save" it will save via Cairo and not our export method.
Instead it must simply refuse to save as PNG, offering a Save As dialog to save as SVG.
Are you in any way against GIMP's new behavior for 2.7/8? Basically, Save/Save As would only offer SVG options (probably only Inkscape SVG variants) and everything else must be performed via an Export operation since there is editing data losss (not like our current one, but basically a different type of "Save As" dialog which would then chain into the png, pdf, eps, jpg, tif, etc special dialogs when those exist).
I guess, do we append a correct the file extension to .svg with a warning or refuse to save with the reason given within a pop-up dialog?
For the record, I haven't tried to defy GIMP with their new handling, so I'm unsure of what they do atm (I assume it is appending a workable extension to the file). I will report back results if no one states ideas for what they think the proper handling would be otherwise.
Cheers, Josh
2010/1/22 Joshua A. Andler <scislac@...400...>:
Basically, Save/Save As would only offer SVG options (probably only Inkscape SVG variants) and everything else must be performed via an Export operation since there is editing data losss (not like our current one, but basically a different type of "Save As" dialog which would then chain into the png, pdf, eps, jpg, tif, etc special dialogs when those exist).
I think it should work this way. It would also remove the need for the "save as Inkscape SVG" popup. Export Bitmap could be renamed to Render, if it created confusion with Export.
Regards, Krzysztof
On Thu, Jan 21, 2010 at 9:59 PM, Joshua A. Andler <scislac@...400...> wrote:
Are you in any way against GIMP's new behavior for 2.7/8? Basically, Save/Save As would only offer SVG options (probably only Inkscape SVG variants) and everything else must be performed via an Export operation since there is editing data losss (not like our current one, but basically a different type of "Save As" dialog which would then chain into the png, pdf, eps, jpg, tif, etc special dialogs when those exist).
For those who are interested, the GIMP folks have a full specification for their new file-handling behavior:
http://gui.gimp.org/index.php/Save_%2B_export_specification
As I understand it, a professional user interface designer wrote the specification at the request of the GIMP developers. The specification could apply to Inkscape just as easily, since the two programs have similar uses and target audiences.
-William
2010/1/24 William Swanson <swansontec@...400...>:
For those who are interested, the GIMP folks have a full specification for their new file-handling behavior:
http://gui.gimp.org/index.php/Save_%2B_export_specification
As I understand it, a professional user interface designer wrote the specification at the request of the GIMP developers. The specification could apply to Inkscape just as easily, since the two programs have similar uses and target audiences.
-William
Looks like the gist of the document is similar to what I proposed when a "Publish" option was discussed about a year ago (precisely, 24-02-09, the thread was called "Export, Publish and Save As"): - "Save" dialog would only save to Inkscape SVG or Compressed Inkscape SVG - "Export" dialog would save to all other formats
However, GIMP's specification also contains a lot of useful and important details, like the rules for determining where the dialogs should open.
Regards, Krzysztof
2010/1/23 Krzysztof Kosiński <tweenk.pl@...400...>:
Looks like the gist of the document is similar to what I proposed when a "Publish" option was discussed about a year ago (precisely, 24-02-09, the thread was called "Export, Publish and Save As"):
- "Save" dialog would only save to Inkscape SVG or Compressed Inkscape SVG
- "Export" dialog would save to all other formats
I personally have no problem with the current behavior, but I think we will keep getting complaints about this, so perhaps it's best to adopt GIMP's approach by now. At least we will be able to blame them for the result :)
Are there any objections to the GIMP approach?
On Jan 24, 2010, at 2:21 PM, bulia byak wrote:
2010/1/23 Krzysztof Kosiński <tweenk.pl@...400...>:
Looks like the gist of the document is similar to what I proposed when a "Publish" option was discussed about a year ago (precisely, 24-02-09, the thread was called "Export, Publish and Save As"):
- "Save" dialog would only save to Inkscape SVG or Compressed Inkscape SVG
- "Export" dialog would save to all other formats
I personally have no problem with the current behavior, but I think we will keep getting complaints about this, so perhaps it's best to adopt GIMP's approach by now. At least we will be able to blame them for the result :)
Are there any objections to the GIMP approach?
I'd have to look for the specifics but in general what we should do includes:
* "Save" stores the current document that had previously been opened, in it's native format.
* "Save as" is the same as "Save" except it allows one to specify a new name (and thus will happen to warn if the same name is chose, etc.)
* "Export" saves data in some non-native format, but leaves the existing document marked as "dirty" and thus still in need of save.
* "Save" should only operate on "native" formats that preserve full editing abilities. Inkscape SVG and compressed Inkscape SVG are the first of these. Additionally any "SVG Complete" type formats (such as .svg+folder, or XOP packaged) might also qualify to go under "Save".
* The document 'dirty' flag only gets cleared by a successful "Save" or "Save As".
* "Save a copy as..." is the same as "Save As..." but does not replace the current name nor resets the dirty flag.
On Fri, 2010-01-22 at 01:40 -0400, bulia byak wrote:
On Fri, Jan 22, 2010 at 1:08 AM, Joshua A. Andler <scislac@...400...> wrote:
Either way, as I understand it, if you open (rather than import) a PNG file, draw on top of it or modify it, and hit "Save" it will save via Cairo and not our export method.
Instead it must simply refuse to save as PNG, offering a Save As dialog to save as SVG.
Should we genericize this in that, if we open with any format that suggests a save format that would cause data loss we default to SVG? Or is this a special case?
--Ted
*bump*
On 19/1/10 17:48, bulia byak wrote:
On Tue, Jan 19, 2010 at 11:39 AM, Ted Gould <ted@...11...> wrote:
On Tue, 2010-01-19 at 11:00 +0100, Jasper van de Gronde wrote:
Chris Lilley wrote:
On Saturday, January 16, 2010, 10:32:16 PM, knowone wrote:
How can I save the file as PNG with the drop shadow intact?
Make sure you are exporting as PNG. Do not 'Save As' Cairo PNG.
(I came across this a couple of days ago, and the symptom was that blur filters were not being applied. Also, the pixel dimensions of the two methods differ, if the graphic bleeds over the edge of the 'page').
Can someone tell me why we have a non-vector format in the save as list?
One that seems redundant and apparently with less functionality than the normal export. Is this for testing purposes?
Yes, it was for testing the Cairo output. It was part of the GSoC project to do PDF output, and was easy enough to add, so we left it in for testing Cairo rendering. Now, is anyone using it for anything now? Bulia? I'd imagine at this point it's cruft.
It still can be useful for testing our cairo interfaces, because it uses basically the same renderer as PS or PDF exporter, but of course it must be hidden in the user-visible list. Is that possible? If not then it should be removed.
This has turned into a FAQ - related questions come up weekly if not daily somewhere in a user forum, in #inkscape or in the 'Answers' sections of launchpad: how to save a bitmap in Inkscape with a transparent background, or why filter effects or patterns are not visible or incorrect in exported PNG files. Yesterday it was filed as bug too:
Bug #669267 “Saving file in PNG format creates incorrect file.”: https://bugs.launchpad.net/inkscape/+bug/669267
Any chance this can be addresses for 0.48.1? "Cairo PNG" should not be listed as file format in the 'Save/Save as/Save a copy' dialog in release versions.
~suv
On Mon, 2010-11-01 at 03:45 +0100, ~suv wrote:
*bump*
On 19/1/10 17:48, bulia byak wrote:
On Tue, Jan 19, 2010 at 11:39 AM, Ted Gould <ted@...11...> wrote:
On Tue, 2010-01-19 at 11:00 +0100, Jasper van de Gronde wrote:
Chris Lilley wrote:
On Saturday, January 16, 2010, 10:32:16 PM, knowone wrote:
How can I save the file as PNG with the drop shadow intact?
Make sure you are exporting as PNG. Do not 'Save As' Cairo PNG.
(I came across this a couple of days ago, and the symptom was that blur filters were not being applied. Also, the pixel dimensions of the two methods differ, if the graphic bleeds over the edge of the 'page').
Can someone tell me why we have a non-vector format in the save as list?
One that seems redundant and apparently with less functionality than the normal export. Is this for testing purposes?
Yes, it was for testing the Cairo output. It was part of the GSoC project to do PDF output, and was easy enough to add, so we left it in for testing Cairo rendering. Now, is anyone using it for anything now? Bulia? I'd imagine at this point it's cruft.
It still can be useful for testing our cairo interfaces, because it uses basically the same renderer as PS or PDF exporter, but of course it must be hidden in the user-visible list. Is that possible? If not then it should be removed.
This has turned into a FAQ - related questions come up weekly if not daily somewhere in a user forum, in #inkscape or in the 'Answers' sections of launchpad: how to save a bitmap in Inkscape with a transparent background, or why filter effects or patterns are not visible or incorrect in exported PNG files. Yesterday it was filed as bug too:
Bug #669267 “Saving file in PNG format creates incorrect file.”: https://bugs.launchpad.net/inkscape/+bug/669267
Any chance this can be addresses for 0.48.1? "Cairo PNG" should not be listed as file format in the 'Save/Save as/Save a copy' dialog in release versions.
I agree this change should be made. It should be as simple as commenting out:
Internal::CairoRendererOutput::init(); (line 157 in init.cpp).
If nobody objects, I will do this.
Tav
On 2/11/10 12:33, Tavmjong Bah wrote:
On Mon, 2010-11-01 at 03:45 +0100, ~suv wrote:
This has turned into a FAQ - related questions come up weekly if not daily somewhere in a user forum, in #inkscape or in the 'Answers' sections of launchpad: how to save a bitmap in Inkscape with a transparent background, or why filter effects or patterns are not visible or incorrect in exported PNG files. Yesterday it was filed as bug too:
Bug #669267 “Saving file in PNG format creates incorrect file.”: https://bugs.launchpad.net/inkscape/+bug/669267
Any chance this can be addresses for 0.48.1? "Cairo PNG" should not be listed as file format in the 'Save/Save as/Save a copy' dialog in release versions.
I agree this change should be made. It should be as simple as commenting out:
Internal::CairoRendererOutput::init(); (line 157 in init.cpp).
If nobody objects, I will do this.
I just did a quick test, because I was curious about a possible side-effect for bug #404826:
from a comment in bug #669267:
<quote> Related issue: The internal output extension 'org.inkscape.output.png.cairo' seems to get used (instead of 'sp_export_png_file()'?) when pasting the clipboard contents from Inkscape into e.g. a raster image editor like GIMP: the pasted images always have a white solid background and show the same rendering errors (e.g. with patterns) or missing filter effects as when saving an SVG drawing as "Cairo PNG".
Bug #404826 “copy an object from inkscape to system clipboard doesn't keep transparency” https://bugs.launchpad.net/inkscape/+bug/404826 </quote>
... and indeed, at least with Inkscape 0.48+devel r9870 on OS X 10.5.8, using X11/Xquartz 2.4.0 and GIMP 2.6.11, after above edit (disabling CairoRendererOutput) copy&paste from Inkscape to GIMP as raster image is pasted without solid white background, and with correctly rendered patterns and filter effects.
Definitely cool :)
Can others confirm that disabling "Cairo PNG" does fix bug #404826?
~suv
participants (9)
-
bulia byak -
Jasper van de Gronde -
Jon Cruz -
Joshua A. Andler -
Krzysztof Kosiński -
Tavmjong Bah -
Ted Gould -
William Swanson -
~suv