Hello Inkscape Developer!
I attached a patch for Inkscape to allow it to export both linear and radial gradients subject to all transformations I could think of. I had some problems with GhostView rendering some radial gradients when the focus of the gradient is outside the actual object it fills. But I think it is a bug in GhostScript and not my understanding of PostScript. The only thing I am unsure is whether it is a good idea to change "%!PS-Adobe-2.0" to "%!PS-Adobe-3.0" since PostScript gradients are a Level 3 feature (perhaps some programs can't handle postscript level 3.
first time Inkscape hacker,
-Michael Forbes
------------------------------------------------------------ Student System Operator binx.mbhs.edu BEN Manager http://ben.mbhs.edu BNC Internet Division http://bnc.mbhs.edu MBHS Webmaster http://www.mbhs.edu BlazerNet President http://blazernet.mbhs.edu Computer Team Co-President http://computerteam.mbhs.edu MBLUG President http://mblug.mbhs.edu ------------------------------------------------------------
On Tue, 1 Mar 2005 18:35:26 -0500 (EST), Michael Forbes <miforbes@...734...> wrote:
I attached a patch for Inkscape to allow it to export both linear and radial gradients subject to all transformations I could think of.
Very cool, thanks! I'll test it.
Of course its usefulness is limited by the fact that it still loses transparency (both in individual gradient stops and on entire objects), but as I understand this is a limitation of PS3 which we cannot do anything about. Still, even without transparency, PS3 gradient export is a good thing to have.
I had some problems with GhostView rendering some radial gradients when the focus of the gradient is outside the actual object it fills. But I think it is a bug in GhostScript and not my understanding of PostScript.
Have you tried that with distiller + acrobat?
The only thing I am unsure is whether it is a good idea to change "%!PS-Adobe-2.0" to "%!PS-Adobe-3.0" since PostScript gradients are a Level 3 feature (perhaps some programs can't handle postscript level 3.
Ideally this should be user-settable. We have a simple options dialog that goes up when you save as EPS. I think what we need to do is to make this dialog come up for all PS output operations (print via PS, save as PS/EPS/EPSI, and perhaps also save as AI because I think it's done via PS too) and add a choice of PS level there.
On Tue, 1 Mar 2005, bulia byak wrote:
On Tue, 1 Mar 2005 18:35:26 -0500 (EST), Michael Forbes <miforbes@...734...> wrote:
I attached a patch for Inkscape to allow it to export both linear and radial gradients subject to all transformations I could think of.
Very cool, thanks! I'll test it.
Of course its usefulness is limited by the fact that it still loses transparency (both in individual gradient stops and on entire objects), but as I understand this is a limitation of PS3 which we cannot do anything about. Still, even without transparency, PS3 gradient export is a good thing to have.
Unless there is a way to embed PDF in PS, I don't see a way around this.
I had some problems with GhostView rendering some radial gradients when the focus of the gradient is outside the actual object it fills. But I think it is a bug in GhostScript and not my understanding of PostScript.
Have you tried that with distiller + acrobat?
I don't think Linux has distiller, but I will try to test it out when I can.
The only thing I am unsure is whether it is a good idea to change "%!PS-Adobe-2.0" to "%!PS-Adobe-3.0" since PostScript gradients are a Level 3 feature (perhaps some programs can't handle postscript level 3.
Ideally this should be user-settable. We have a simple options dialog that goes up when you save as EPS. I think what we need to do is to make this dialog come up for all PS output operations (print via PS, save as PS/EPS/EPSI, and perhaps also save as AI because I think it's done via PS too) and add a choice of PS level there.
Ah.
-Michael Forbes
------------------------------------------------------------ Student System Operator binx.mbhs.edu BEN Manager http://ben.mbhs.edu BNC Internet Division http://bnc.mbhs.edu MBHS Webmaster http://www.mbhs.edu BlazerNet President http://blazernet.mbhs.edu Computer Team Co-President http://computerteam.mbhs.edu MBLUG President http://mblug.mbhs.edu ------------------------------------------------------------
On Wednesday 02 March 2005 03:27, Michael Forbes wrote:
On Tue, 1 Mar 2005, bulia byak wrote:
On Tue, 1 Mar 2005 18:35:26 -0500 (EST), Michael Forbes
<miforbes@...734...> wrote:
I attached a patch for Inkscape to allow it to export both linear and radial gradients subject to all transformations I could think of.
Very cool, thanks! I'll test it.
Of course its usefulness is limited by the fact that it still loses transparency (both in individual gradient stops and on entire objects), but as I understand this is a limitation of PS3 which we cannot do anything about. Still, even without transparency, PS3 gradient export is a good thing to have.
Unless there is a way to embed PDF in PS, I don't see a way around this.
I had some problems with GhostView rendering some radial gradients when the focus of the gradient is outside the actual object it fills. But I think it is a bug in GhostScript and not my understanding of PostScript.
Have you tried that with distiller + acrobat?
I don't think Linux has distiller, but I will try to test it out when I can.
The only thing I am unsure is whether it is a good idea to change "%!PS-Adobe-2.0" to "%!PS-Adobe-3.0" since PostScript gradients are a Level 3 feature (perhaps some programs can't handle postscript level 3.
Ideally this should be user-settable. We have a simple options dialog that goes up when you save as EPS. I think what we need to do is to make this dialog come up for all PS output operations (print via PS, save as PS/EPS/EPSI, and perhaps also save as AI because I think it's done via PS too) and add a choice of PS level there.
Ah.
You will face issues setting PS3 only as many printers cant handle PS3 and may just die even seeing that value, though they should only stop printing when they come across a purely PS3 operator. You wont get transparencies in PS unless you develop a flattener - something we want to develop for Scribus 1.3 too.
Try viewing your PS files under GSview, which only works with AFPL GS. If you want to got with purely PS3 code, then you can support PS2 export or direct printing with something like ps2ps.
Craig Scribus
On Tue, 2005-03-01 at 21:27, Michael Forbes wrote:
Unless there is a way to embed PDF in PS, I don't see a way around this.
IIRC some PS viewers do understand the transparency operators introduced in PDF, but I don't know how that capability would be required.
It might actually be worthwhile to include a little stub code that defines the PDF transparency operators (as noops) if they are not already present...
That way anybody that supported the PDF extensions would get transparency, but everyone else gets something that's no worse than what we have right now.
I wonder if it might not be worthwhile to write our PostScript to the "highest common denominator", then provide stub procedures so it gracefully degrades with less featureful interpreters?
-mental
On Wed, 2005-03-02 at 20:04 -0500, MenTaLguY wrote:
I wonder if it might not be worthwhile to write our PostScript to the "highest common denominator", then provide stub procedures so it gracefully degrades with less featureful interpreters?
OK, so not that I've actually managed to do anything useful at all in Inkscape development (yet), but perhaps I can come with a suggestion anyways: I have a feeling that if you actually want to move to a Cairo- based rendering solution it might not really be all that worthwhile to bother with advanced PostScript export at the moment. The PDF backend of Cairo can be expected to improve (currently it shows promise but doesn't really work for any advanced stuff as far as I can tell - it does already do transparency though, at least for flat colors!) and should probably be the preferred hardcopy output method. That way rendering to the screen, to an exported bitmap, and printing are all done with the same (Cairo) operations, minimizing the possibility of getting different results for different output formats.
Of course, the Cairo PostScript output is pretty much junk (as far as I know it still just shovels a huge bitmap onto each page) but there's talk about fixing that. Quality PDF generation might be higher priority though, since PDF 1.4 actually supports the stuff that you want to do, such as transparency... Also, won't the exotic interpreters that deal with transparency in PS also deal with PDF? I think e.g. some printers do.
Oh, by the way, if you do output PDF 1.4 you can then feed it to Ghostscript (using the pdf2ps utility) and watch it degrade more or less gracefully as is gets turned into PS. That's "PostScript" output while concentrating on PDF. ;)
Of course, I don't want to disparage anyone from doing cool stuff, I just have a sense that if anyone wants to put any major work into improving the export functionality, that work would probably be most efficiently spent on improving Cairo. That way all kinds of applications would stand to gain, as an added bonus.
Cheers, Per
Quoting Per Bjornsson <perbj@...604...>:
The PDF backend of Cairo can be expected to improve (currently it shows promise but doesn't really work for any advanced stuff as far as I can tell - it does already do transparency though, at least for flat colors!) and should probably be the preferred hardcopy output method.
Cairo's PDF/PS backends will be most appropriate for printing, but I don't think Cairo-generated Postscript or PDF would always be desirable for our "export" functionality.
The reason is that Cairo writes PDF/Postscript shapes tesselated into trapezoids, rather than as paths with fills and strokes (at least this is planned; I don't know whether that is the reality yet). This is highly desirable for printing because it ensures consistent rendering regardless of the renderer used by the Postscript interpreter (there are corner cases that most commercially available Postscript implementations don't get right).
However, many designers also rely on EPS/PDF output as a "poor man's" interchange format as well. We at least want to provide an option for Postscript/PDF output that preserves as much of the structure of the document as possible, to enable meaningful import in other tools.
It'd be nice to separate the two roles somehow, since in the more common cases where editing isn't needed (e.g. for just sticking in a page layout), the Cairo exported EPS/PDF is probably going to be preferable.
-mental
On Thu, 3 Mar 2005 09:51:16 -0500, mental@...3... <mental@...3...> wrote:
The reason is that Cairo writes PDF/Postscript shapes tesselated into trapezoids, rather than as paths with fills and strokes (at least this is planned; I don't know whether that is the reality yet).
It's a bummer. However I think that generally, it would be much more preferable if Cairo had the option to ouput non-tesselated Postscript as well, which we could use. It's the best approach from many viewpoints: first, Cairo already has the curve representation that it could pass on to PS; second, doing that would allow much more programs to get PS with curves; and third, both kinds of PS have a lot in common, so it would be very inefficient to reimplement the entire PS output for the sake of preserving curves.
Mental, if you agree, maybe we should contact Cairo people about this issue?
Quoting bulia byak <buliabyak@...400...>:
Mental, if you agree, maybe we should contact Cairo people about this issue?
I was involved in the original thread on the Cairo mailing list regarding this. Cairo backends don't have enough visibility into the front-end calls to reconstruct all the information you might like in a "for-editing" EPS file (there are more considerations than just path data).
On the other hand, the front-end Cairo API is very close to the Postscript model, to the point where you could relatively easily have the same code driving both Cairo and a postscript writer through an abstraction layer.
IMO, I think that would be the better approach. Cairo is very deliberately designed for rendering/printing, not format conversion.
-mental
Cairo's PDF/PS backends will be most appropriate for printing, but I don't think Cairo-generated Postscript or PDF would always be desirable for our "export" functionality.
/
However, many designers also rely on EPS/PDF output as a "poor man's" interchange format as well. We at least want to provide an option for Postscript/PDF output that preserves as much of the structure of the document as possible, to enable meaningful import in other tools.
It'd be nice to separate the two roles somehow, since in the more common cases where editing isn't needed (e.g. for just sticking in a page layout), the Cairo exported EPS/PDF is probably going to be preferable.
Just for reference, that's actually how Illustrator handles PDF exports (and probably for the same reason). At least in AI 10, when you save as PDF, in the 'save options' dialog it has a checkbox that is to "keep Illustrator editing capabilities". So, a checkbox in a 'save options' or export dialog would seem to make sense. On a side note, it also has a radio button for which version of Reader you want it to be compatible with, that maybe we could have for which version of PDF you want.
-Josh
Quoting bulia byak <buliabyak@...400...>:
Very cool, thanks! I'll test it.
Eek, sorry, I didn't mean to step on your toes... :/ It seems to work ok though (but please give it a good workout, I just gave it a cursory run-through and checked the code).
Ideally this should be user-settable. We have a simple options dialog that goes up when you save as EPS. I think what we need to do is to make this dialog come up for all PS output operations (print via PS, save as PS/EPS/EPSI, and perhaps also save as AI because I think it's done via PS too) and add a choice of PS level there.
AI prior to ... version 7 or 9 I think ... uses EPS; later versions of the AI format are PDF-based (that's one reason our AI import script only works for older versions).
Something we need to think about is how (in general) we will want to handle different "profiles" in the user interface. We have already talked about SVG Tiny versus SVG Basic and 1.0/1.1/1.2 etc, but now I realize we have similar considerations for Postscript too.
Any thoughts on this?
-mental
On Tue, 2005-03-01 at 18:35, Michael Forbes wrote:
Hello Inkscape Developer!
I attached a patch for Inkscape to allow it to export both linear and radial gradients subject to all transformations I could think of. I had some problems with GhostView rendering some radial gradients when the focus of the gradient is outside the actual object it fills. But I think it is a bug in GhostScript and not my understanding of PostScript. The only thing I am unsure is whether it is a good idea to change "%!PS-Adobe-2.0" to "%!PS-Adobe-3.0" since PostScript gradients are a Level 3 feature (perhaps some programs can't handle postscript level 3.
first time Inkscape hacker,
-Michael Forbes
Looks good, Michael! I've applied your patch.
Do you think it is possible to implement gradients for strokes also?
-mental
On Tue, 1 Mar 2005, MenTaLguY wrote:
On Tue, 2005-03-01 at 18:35, Michael Forbes wrote:
Looks good, Michael! I've applied your patch.
Do you think it is possible to implement gradients for strokes also?
-mental
I tried looking at some of the PostScript code to do this, but it does not seem well supported by either ESP or GPL GhostScript, so I don't think it is all too useful.
-Forbes
Hi Michael,
a user reported a problem with your gradient export: objects that are on top of an object with gradient are clipped by that object's edge. His proposed patch is below, but he says he's created it without much knowledge of Postscript. Could you please review this and maybe change something or propose another solution?
--- extension/internal/ps.cpp 2 Mar 2005 02:31:31 -0000 1.56 +++ extension/internal/ps.cpp 18 Mar 2005 18:22:27 -0000 @@ -683,6 +683,7 @@ if (g->gradientTransform_set) { os << "grestore\n"; } + os << "initclip\n"; } } else { if (style->fill.type == SP_PAINT_TYPE_COLOR) { @@ -699,6 +700,7 @@ if (g->gradientTransform_set) { os << "grestore\n"; } + os << "initclip\n"; } } fprintf(_stream, "%s", os.str().c_str());
--- extension/internal/ps.cpp 2 Mar 2005 02:31:31 -0000 1.56 +++ extension/internal/ps.cpp 18 Mar 2005 18:22:27 -0000 @@ -683,6 +683,7 @@ if (g->gradientTransform_set) { os << "grestore\n"; }
os << "initclip\n"; } } else { if (style->fill.type == SP_PAINT_TYPE_COLOR) {@@ -699,6 +700,7 @@ if (g->gradientTransform_set) { os << "grestore\n"; }
os << "initclip\n"; } } fprintf(_stream, "%s", os.str().c_str());
Probably a better solution is to simply make the gsave/grestore unconditional. initclip completely resets the clipping state, which is bad if we want to implement SVG clipping properly later.
-mental
I like the gsave/grestore option, as initclip may mess with clipping from earlier in the file, perhaps. Something like this:
--- ps.cpp 2 Mar 2005 02:31:31 -0000 1.56 +++ ps.cpp 18 Mar 2005 19:07:53 -0000 @@ -664,6 +664,8 @@ if (style->fill.type == SP_PAINT_TYPE_COLOR || SP_IS_GRADIENT (SP_STYLE_FILL_SERVER (style))) { Inkscape::SVGOStringStream os;
+ os << "gsave\n"; + print_fill_style(os, style);
print_bpath(os, bpath->path); @@ -701,6 +703,9 @@ } } } + + os << "grestore\n"; + fprintf(_stream, "%s", os.str().c_str()); }
Also, I am trying to make it so the units in the ellipse properties dialog (from a right click) is displayed in the default units of the document. I see a function to get the default units of a document, but I am unclear on how to get the current document. Any ideas?
-Michael Forbes
------------------------------------------------------------ Student System Operator binx.mbhs.edu BEN Manager http://ben.mbhs.edu BNC Internet Division http://bnc.mbhs.edu MBHS Webmaster http://www.mbhs.edu BlazerNet President http://blazernet.mbhs.edu Computer Team Co-President http://computerteam.mbhs.edu MBLUG President http://mblug.mbhs.edu ------------------------------------------------------------
On Fri, 18 Mar 2005 mental@...3... wrote:
--- extension/internal/ps.cpp 2 Mar 2005 02:31:31 -0000 1.56 +++ extension/internal/ps.cpp 18 Mar 2005 18:22:27 -0000 @@ -683,6 +683,7 @@ if (g->gradientTransform_set) { os << "grestore\n"; }
os << "initclip\n"; } } else { if (style->fill.type == SP_PAINT_TYPE_COLOR) {@@ -699,6 +700,7 @@ if (g->gradientTransform_set) { os << "grestore\n"; }
os << "initclip\n"; } } fprintf(_stream, "%s", os.str().c_str());Probably a better solution is to simply make the gsave/grestore unconditional. initclip completely resets the clipping state, which is bad if we want to implement SVG clipping properly later.
-mental
On Fri, 18 Mar 2005 14:11:34 -0500 (EST), Michael Forbes <miforbes@...734...> wrote:
I like the gsave/grestore option, as initclip may mess with clipping from earlier in the file, perhaps. Something like this:
Tested & applied, thanks
Also, I am trying to make it so the units in the ellipse properties dialog (from a right click) is displayed in the default units of the document. I see a function to get the default units of a document, but I am unclear on how to get the current document. Any ideas?
Actually we're planning to remove those "properties" dialogs. They have too many problems and just add cruft. All controls on shapes must be in the corresponding tool's control panels (e.g. switch to the ellipse tool, select an ellipse and edit its parameters in the panel above the canvas). These panels don't yet have all the parameters that would be nice to have, so instead you could work on adding the missing ones (e.g. the center and radii of an ellipse). Look up in the Rectangle panel how to add units there. It's all in toolbox.cpp.
As for your question, to look up current document _from a dialog_ use SP_DT_DOCUMENT(SP_ACTIVE_DESKTOP). From a fixed per-window panel, use that panel's desktop (passed to it upon initialization) instead of SP_ACTIVE_DESKTOP.
Also, I am trying to make it so the units in the ellipse properties dialog (from a right click) is displayed in the default units of the document. I see a function to get the default units of a document, but I am unclear on how to get the current document. Any ideas?
As a matter of general principle, the question you want to ask is not "what is the current document", but "what document does this object belong to"?
SP_OBJECT_DOCUMENT(object) (from memory... it's something like that anyway) should answer that question for you.
The reason is that (especially as we introduce scripting of Inkscape itself) the document a particular command operates upon will not necessarily be the current document.
-mental
On Fri, 18 Mar 2005 14:40:26 -0500, mental@...3... wrote:
SP_OBJECT_DOCUMENT(object)
Oh yes, when you have an object already, use that. When you just start doing something from a dialog and have yet to find an object to apply to, SP_DT_DOCUMENT(SP_ACTIVE_DESKTOP) is what you need.
However al this does not apply to the "properties" dialogs which are unable to apply to different objects anyway (i.e. you can't select something different and edit it in the same dialog; you'll need to open a new one). This is one of the reasons why we plan to trash them eventually.
The only thing I am unsure is whether it is a good idea to change "%!PS-Adobe-2.0" to "%!PS-Adobe-3.0" since PostScript gradients are a Level 3 feature (perhaps some programs can't handle postscript level 3.
I went ahead and did that for now; if it causes problems we can revisit doing it dynamically or something.
-mental
participants (7)
-
unknown＠example.com -
bulia byak -
Craig Bradney -
Joshua A. Andler -
MenTaLguY -
Michael Forbes -
Per Bjornsson