Last night I added a short blurb to http://wiki.inkscape.org/cgi-bin/wiki.pl?GettingExtensionsWorking about how I was able to make pdf output work on WinXP with ghostscript.
I've been thinking about what if any of that should go into cvs and how would we ever make an inx file cross platform in a situation like this. But it just occured to me that for in/output extensions this isn't necessary. An inx for each platform could coexist as long as they have appropriate dependency tests. Because they don't show up when the deps aren't met. So I guess I just need a proper test for windows.
thoughts?
Aaron Spike
On Fri, 2005-11-18 at 10:30 -0600, aaron@...749... wrote:
Last night I added a short blurb to http://wiki.inkscape.org/cgi-bin/wiki.pl?GettingExtensionsWorking about how I was able to make pdf output work on WinXP with ghostscript.
I've been thinking about what if any of that should go into cvs and how would we ever make an inx file cross platform in a situation like this. But it just occured to me that for in/output extensions this isn't necessary. An inx for each platform could coexist as long as they have appropriate dependency tests. Because they don't show up when the deps aren't met. So I guess I just need a proper test for windows.
Perhaps we should make an operator in the .inx files to check the platform. Then we could guarantee that the .inx file is only used on the one that is supported. Would that work?
--Ted
Ted Gould wrote:
On Fri, 2005-11-18 at 10:30 -0600, aaron@...749... wrote:
Last night I added a short blurb to http://wiki.inkscape.org/cgi-bin/wiki.pl?GettingExtensionsWorking about how I was able to make pdf output work on WinXP with ghostscript.
I've been thinking about what if any of that should go into cvs and how would we ever make an inx file cross platform in a situation like this. But it just occured to me that for in/output extensions this isn't necessary. An inx for each platform could coexist as long as they have appropriate dependency tests. Because they don't show up when the deps aren't met. So I guess I just need a proper test for windows.
Perhaps we should make an operator in the .inx files to check the platform. Then we could guarantee that the .inx file is only used on the one that is supported. Would that work?
Oh, that might help but I wasn't realy thinking about such a thing. The problem is how to test for or even find the executable on windows. Ghostscript is unlikely to be in the path. The default install location is %programfiles%\gs\gs8.51 which expands to c:"Program Files"\gs\gs8.51\ here on my laptop, but it could just as easily be on e:. Looking at the path you will notice another problem. The version is part of the path. At work I have gs 8.53, so a single test won't find both. I was hoping someone with more knowledge of windows could comment. No offense, Ted. But you don't know windows. And I use windows but it has always seemed like black magic to me.
Aaron Spike
A lot of programs get round this kind of issue by having a file dialog popup where you locate the executable in question, then save the path to the appropriate place. Could quite easily be a standalone, run this to setup pdf with GS type thing. Other option is that the installer may well be able to do this sort of task, I'm not sure.
Cheers
Sim
--- Aaron and Sarah Spike <spike@...749...> wrote:
Ted Gould wrote:
On Fri, 2005-11-18 at 10:30 -0600, aaron@...749... wrote:
Last night I added a short blurb to http://wiki.inkscape.org/cgi-bin/wiki.pl?GettingExtensionsWorking
about
how I was able to make pdf output work on WinXP with ghostscript.
I've been thinking about what if any of that should go into cvs and
how
would we ever make an inx file cross platform in a situation like
this.
But it just occured to me that for in/output extensions this isn't necessary. An inx for each platform could coexist as long as they
have
appropriate dependency tests. Because they don't show up when the
deps
aren't met. So I guess I just need a proper test for windows.
Perhaps we should make an operator in the .inx files to check the platform. Then we could guarantee that the .inx file is only used
on
the one that is supported. Would that work?
Oh, that might help but I wasn't realy thinking about such a thing. The problem is how to test for or even find the executable on windows. Ghostscript is unlikely to be in the path. The default install location is %programfiles%\gs\gs8.51 which expands to c:"Program Files"\gs\gs8.51\ here on my laptop, but it could just as easily be on e:. Looking at the path you will notice another problem. The version is part of the path. At work I have gs 8.53, so a single test won't find both. I was hoping someone with more knowledge of windows could comment. No offense, Ted. But you don't know windows. And I use windows but it has always seemed like black magic to me.
Aaron Spike
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
__________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
John Cliff schrieb:
A lot of programs get round this kind of issue by having a file dialog popup where you locate the executable in question, then save the path to the appropriate place. Could quite easily be a standalone, run this to setup pdf with GS type thing. Other option is that the installer may well be able to do this sort of task, I'm not sure.
Cheers
Sim
--- Aaron and Sarah Spike <spike@...749...> wrote:
... I like the idea to have everything working after the install. But I think an effects configuration dialog should do this job better and more transparent to the user.
Adib. ---
John Cliff wrote:
A lot of programs get round this kind of issue by having a file dialog popup where you locate the executable in question, then save the path to the appropriate place. Could quite easily be a standalone, run this to setup pdf with GS type thing. Other option is that the installer may well be able to do this sort of task, I'm not sure.
In addition some programs may have their path registered in the Windows registry at (HK(CU|LM)\Software\Microsoft\Windows\CurrentVersion\App Paths, in a key of their own or they simply append their path to the PATH environment variable (obviously these methods all depend on an installer of some sort and should therefor not be completely relied on).
On Sat, 2005-11-19 at 08:18 -0600, Aaron and Sarah Spike wrote:
No offense, Ted. But you don't know windows. And I use windows but it has always seemed like black magic to me.
Oh yes, Windows is black magic :)
I think we were thinking about different things. I was thinking about the case where there may be some tool available on Linux that wasn't on Windows, or vice versa. Perhaps we'd want to have two pdf_output.inx files depending on your platform, so they could use the 'ideal' tool on each.
--Ted
participants (6)
-
unknown＠example.com -
Aaron and Sarah Spike -
Adib Taraben -
Jasper van de Gronde -
John Cliff -
Ted Gould