please test: svgslice as an extension
Hi all,
Now that 0.42 is done, I thought I'd send the extension version of svgslice for others to test and consider for inclusion.
It's pretty basic: just saves marked sections of the image into separate PNG "slices", and generates a basic XHTML file that lists the slices. Most notably, no equivalent layout is done in the XHTML file, so that it looks like the original SVG drawing. Problem is, there are many ways to do that in CSS, and the most obvious way (absolute positioning) is probably not much use to people. I suspect it would lead to bad web pages, or just get in the way of proper hand-crafted layout, and people who want to use a WYSIWYG CSS editor to move them around easily can still do so.
Note also, that the slices will be saved in Inkscape's current directory. If you load inkscape by double-clicking on an image in a project folder, and save the XHTML file in the same folder, then this is fine -- your startup directory will be that folder, and images will be right alongside the XHTML file.
But if you start inkscape from your home directory on the command line, or from just running it via a menu entry, and then load and save a file in another location, the PNG slices will end up in your home directory (at least on unix; windows might save then in C: or "C:\Program Files\Inkscape", or something like that.
At the moment, there's nothing I can do about that, since inkscape doesn't CD to the output directory before calling the extension, and doesn't seem to provide the extension with any idea of where it is actually saving stuff.
Personally, I'd like to see that issue fixed for 0.43.
But either way, it'll be good to hear if this works for others, if there are any bugs, etc. So please give it a test, and let me know :)
Installation ============ Save both attached files in your inkscape extensions directory. If that directory is somewhere other than /usr/share/inkscape/extensions, then you'll need to edit the paths in svgslice.inx to reflect that.
Obviously, this will have a different path on Windows. Maybe someone could edit the svgslice.inx file, and post it here for other windows users?
Usage =====
* Draw something.
* Create a layer called "slices".
* Draw rectangles in this layer representing the areas you want to slice (note: it helps if you make the rectangles semi-transparent)
* Optionally, name any/all slices by using the built-in XML editor to edit the "id" attributes of the rectangles.
* Hide the slices layer.
* Choose "Save as..." from the File menu.
* Select "XHTML file with PNG slices" as the file type to use.
* Enter a filename (e.g., "test.xhtml"), and save.
Result ====== * You should have the test.xhtml file on your disk, alongside the PNG slices for each area of the drawing that you made a rectangle for.
Lee Braiden wrote:
But if you start inkscape from your home directory on the command line, or from just running it via a menu entry, and then load and save a file in another location, the PNG slices will end up in your home directory (at least on unix; windows might save then in C: or "C:\Program Files\Inkscape", or something like that.
At the moment, there's nothing I can do about that, since inkscape doesn't CD to the output directory before calling the extension, and doesn't seem to provide the extension with any idea of where it is actually saving stuff.
Personally, I'd like to see that issue fixed for 0.43.
I'm not really for this at all. One of the big reasons is that it is going to be difficult to handle issues like filename conflicts. Inkscape currently handles this for extensions, but if you are writing files that are not specified by the file dialog, there is no way to help here. Plus, how would "nfs://user/myfiles" be handled as a path?
All in all, I really think outputting something like .chm is much better. It should be easy to implement also. Just generate all of the slices and the xhtml files in a temporary directory, the zip them up and output that.
--Ted
On Monday 29 August 2005 19:30, Ted Gould wrote:
Lee Braiden wrote:
Personally, I'd like to see that issue fixed for 0.43.
I'm not really for this at all. One of the big reasons is that it is going to be difficult to handle issues like filename conflicts. Inkscape currently handles this for extensions, but if you are writing files that are not specified by the file dialog, there is no way to help here. Plus, how would "nfs://user/myfiles" be handled as a path?
Yes, I'm aware of those issues; that's something that needs to be properly addressed by any solution, I think. But I stand by my point; I do feel that a solution is needed.
All in all, I really think outputting something like .chm is much better. It should be easy to implement also. Just generate all of the slices and the xhtml files in a temporary directory, the zip them up and output that.
Someone else might be interested in generating CHM files, but as far as I'm concerned, that's a totally different subject. I'm interested in slicing up SVG files to assist with standards-compliant web development, and perhaps in generating good standards-compliants XHTML webpages to go along with it. Microsoft's proprietary online help system is another matter entirely.
On Monday 29 August 2005 23:03, Lee Braiden wrote:
On Monday 29 August 2005 19:30, Ted Gould wrote:
I'm not really for this at all. One of the big reasons is that it is going to be difficult to handle issues like filename conflicts. Inkscape currently handles this for extensions, but if you are writing files that are not specified by the file dialog, there is no way to help here. Plus, how would "nfs://user/myfiles" be handled as a path?
Yes, I'm aware of those issues; that's something that needs to be properly addressed by any solution, I think. But I stand by my point; I do feel that a solution is needed.
Oh, I should mention that there is one way of doing this that I can think of without knowing the Inkscape code... If a temporary directory is created for the extension's save, and that is CD'd to, then anything saved in that directory by the extension could be transferred to the final save destination. There's no reason (which I can see) that this couldn't handle error feedback from things like filename conflicts over gnomevfs or other protocols.
Lee Braiden wrote:
Someone else might be interested in generating CHM files, but as far as I'm concerned, that's a totally different subject. I'm interested in slicing up SVG files to assist with standards-compliant web development, and perhaps in generating good standards-compliants XHTML webpages to go along with it. Microsoft's proprietary online help system is another matter entirely.
Sorry, I thought that chm files were just a ZIP file with HTML in it. I used a tool at a former company that referred to them as such. For those who are curious, here is more information:
http://en.wikipedia.org/wiki/Microsoft_Compressed_HTML_Help
I just don't think that we are prepared to handle directories of information being generated by an output extension. I think they should be put into a single file package, I don't care whether it is .zip, .tar.gz, .tar, .tar.bz2 or .rar. I just feel that'll be a much cleaner solution given the current implementation.
--Ted
On Monday 29 August 2005 23:34, Ted Gould wrote:
Lee Braiden wrote: I just don't think that we are prepared to handle directories of information being generated by an output extension. I think they should be put into a single file package, I don't care whether it is .zip, .tar.gz, .tar, .tar.bz2 or .rar. I just feel that'll be a much cleaner solution given the current implementation.
OK, you're entitled to your view, of course. I feel that's totally impractical for web developers who want to alt-tab between Inkscape and their other webpage development tools though. Might as well have a RAD tool that generates code when you move a button and add an event, but then zips it all up so your IDE can't access it easily.
If this is the official position, then I'll have to dump this idea, and go back to SVGSlice as an external tool rather than an extension. However, if that's the case, then I have to say, I wish that would have been made clear sooner. I was *asked* on this list to make the extension version.
Lee Braiden wrote:
OK, you're entitled to your view, of course. I feel that's totally impractical for web developers who want to alt-tab between Inkscape and their other webpage development tools though. Might as well have a RAD tool that generates code when you move a button and add an event, but then zips it all up so your IDE can't access it easily.
I entirely agree that it is not ideal, but I think that it works with the Inkscape architecture in the near future in a much more reasonable manner.
If this is the official position, then I'll have to dump this idea, and go back to SVGSlice as an external tool rather than an extension. However, if that's the case, then I have to say, I wish that would have been made clear sooner. I was *asked* on this list to make the extension version.
I'm sorry you feel that way. I hope that you'll considering adding a command line option in your utility to output the sliced html as a single file so that we can include it as an Inkscape extension. I think that, even given the limitations, it would be useful for many users.
I will always choose not overwriting a user's files without notice over a new feature.
--Ted
On Tuesday 30 August 2005 00:46, Ted Gould wrote:
I entirely agree that it is not ideal, but I think that it works with the Inkscape architecture in the near future in a much more reasonable manner.
As I understand it, the final plugin API (which would have been much better for this, obviously) is still to be developed, and the current status is that CDing to the right directory for extension output would only break another feature that isn't yet implemented.
I don't see why a better plugin API couldn't be prioritised over network output, considering that things like NFS can be done at the kernel layer, anyway. If that was done, a temporary extension output fix could be incorporated into the design of the final plugin API, the network output could be fixed, and nothing would have broken in-between.
I'm sorry you feel that way. I hope that you'll considering adding a command line option in your utility to output the sliced html as a single file so that we can include it as an Inkscape extension. I think that, even given the limitations, it would be useful for many users.
Well, the problem is that writing the many image slices is the main point; not generating (X)HTML, so that's not going to work.
I will always choose not overwriting a user's files without notice over a new feature.
Hmm. I've already proposed a low-impact solution that would NOT overwrite user's files, so from my point of view, this isn't a valid argument.
Don't feel like you have to justify your position; it's your app, and you're entitled to develop it your way, so I'm happy to leave it here if you are. On the other hand, though, I see plugins as one of the least capable subsystems in Inkscape right now, so I think it would help to reconsider this.
First off, I'm sorry I haven't had a chance to test the current version of SVGSlice.
The external script type extension system is simple and powerful. It has many applications but I think we are trying to stretch it beyond comfort. I'd hate to see it made any more complex. Simplicity and the ability to communicate with external apps in a generic way are its coolest features.
IMHO a convenient slicing feature in Inkscape will be appreciated by the silent majority. But it is completely useless to package the files as an archive. That just isn't part of the workflow.
I've said this before, but I think a file selector autogui widget would come in handy in exactly this situation. SVGSlice could be an Effect. The user would be prompted by autogui to select an output directory. After that Inkscape would be done and SVGSlice could interactively prompt the user as to whether or not to replace files.
Thoughts?
Aaron Spike
On Tuesday 30 August 2005 12:42, aaron@...749... wrote:
First off, I'm sorry I haven't had a chance to test the current version of SVGSlice.
Don't worry; we're all busy :)
I've said this before, but I think a file selector autogui widget would come in handy in exactly this situation. SVGSlice could be an Effect. The user would be prompted by autogui to select an output directory. After that Inkscape would be done and SVGSlice could interactively prompt the user as to whether or not to replace files.
Thoughts?
Thanks; it's always good to have other options. To me it fits perfectly as an extension, if it wasn't for that one small issue. I think if I did it as an Effect, people would say it's not really an effect (which would be true), and I'd still be looking at re-doing it once the new plugin/DOM system is ready.
I think I'll just release this separately for anyone who might find it useful, and then maybe look at the issue again once the DOM is ready, etc. :)
Lee Braiden wrote:
Thanks; it's always good to have other options. To me it fits perfectly as an extension, if it wasn't for that one small issue. I think if I did it as an Effect, people would say it's not really an effect (which would be true), and I'd still be looking at re-doing it once the new plugin/DOM system is ready.
Come on. What if I promise to flame anyone who mentions the fact that it really isn't an "Effect"? :) (The offer stands for the clipart browser too, but it looks like that has been resolved in another direction.)
Aaron Spike
On Mon, Aug 29, 2005 at 11:39:50PM +0100, Lee Braiden wrote:
On Monday 29 August 2005 23:34, Ted Gould wrote:
Lee Braiden wrote: I just don't think that we are prepared to handle directories of information being generated by an output extension. I think they should be put into a single file package, I don't care whether it is .zip, .tar.gz, .tar, .tar.bz2 or .rar. I just feel that'll be a much cleaner solution given the current implementation.
Hmm, I've not tried out svgslice but am familiar with the need for having multi-file output from extensions.
Ted, I see your point about the conceptual cleanness of having a single file output, however I'd encourage you to be open minded on this.
From a practical point of view it may be quite useful to have the output
be a directory of files.
(Similarly, I could imagine the usefulness of the converse - given a directory full of files, generate a single SVG file that summarizes everything.)
Anyway, in the spirit of "patch first, discuss later", perhaps you could have Lee add his code in and then you can focus on the specific implementational issues where you see there may be better ways of doing things. I think you two can come up with a pretty brilliant feature if you work together on it.
Bryce
Bryce Harrington wrote:
Hmm, I've not tried out svgslice but am familiar with the need for having multi-file output from extensions.
Ted, I see your point about the conceptual cleanness of having a single file output, however I'd encourage you to be open minded on this. From a practical point of view it may be quite useful to have the output be a directory of files.
I think you're saying "conceptual cleanness" to capture a large list of issues. It isn't just the simple issue of what to do with the files, it is how the application should work. Here are some examples:
Should the save dialog be a file browser or a directory browser? Or both? I can't think of a way to do this intuitively, or similar to other applications, where one can select either a directory or a file. They have different semantics of things like double clicking and how you'd specify creating a new directory.
We could make it different based on which output format is selected. Well yeah, but what if the user has it as "selected from extension"? Disable the directory ones? How does that work? Changing the file format changes how the filename chooser dialog works?
So, the user interface issues get figured out... what happens on conflicts? If all the files require overwriting, that's a pretty simple case. What about one? What if two, is one so important that all the others should be cleaned up if it isn't written? Should we only allow saving into clean directories?
How should this work as a script? If files aren't passed through the pipe, what is? Is it a zip file that has all the files in it, or a list of file names in some temporary storage area? But, since this is all different, it will probably require a new extension type. Not a huge deal, but also non-trivial.
Yes, none of this is unsolvable, but it is a significantly different use model than all of these constructs were designed for. There are also significant concerns here that haven't been widely addressed. I see no solution in the short term.
I would think that a final solution would involve a "Export to Directory..." type menu item. Where a dialog that is better suited for multi-file output would come up. The a special extension type can be designed to handle these issues. The special cases listed above can be handles in a consistent way. I don't currently have any plans to work on this. I have too much on my plate as it is.
Anyway, in the spirit of "patch first, discuss later", perhaps you could have Lee add his code in and then you can focus on the specific implementational issues where you see there may be better ways of doing things. I think you two can come up with a pretty brilliant feature if you work together on it.
I agree, I think that adding where it saves as a single compressed file is a good start. Figuring out how to do it so that it is more useful and works within Inkscape can come in the future.
My favorite idea so far is Aaron's. But, it seems other solutions will not be considered.
--Ted
On Tue, Aug 30, 2005 at 05:30:55PM -0700, Ted Gould wrote:
Should the save dialog be a file browser or a directory browser? Or both? I can't think of a way to do this intuitively, or similar to other applications, where one can select either a directory or a file. They have different semantics of things like double clicking and how you'd specify creating a new directory.
We could make it different based on which output format is selected. Well yeah, but what if the user has it as "selected from extension"? Disable the directory ones? How does that work? Changing the file format changes how the filename chooser dialog works?
So, the user interface issues get figured out... what happens on conflicts? If all the files require overwriting, that's a pretty simple case. What about one? What if two, is one so important that all the others should be cleaned up if it isn't written? Should we only allow saving into clean directories?
How should this work as a script? If files aren't passed through the pipe, what is? Is it a zip file that has all the files in it, or a list of file names in some temporary storage area? But, since this is all different, it will probably require a new extension type. Not a huge deal, but also non-trivial.
Yes, none of this is unsolvable, but it is a significantly different use model than all of these constructs were designed for. There are also significant concerns here that haven't been widely addressed. I see no solution in the short term.
I would think that a final solution would involve a "Export to Directory..." type menu item. Where a dialog that is better suited for multi-file output would come up. The a special extension type can be designed to handle these issues. The special cases listed above can be handles in a consistent way. I don't currently have any plans to work on this. I have too much on my plate as it is.
Okay, so what you're saying is that a) there are a lot of misc. technical issues to sort out, b) they're probably solveable, but c) you don't personally have the time to work on it.
It sounds to me that this is the classic situation where much good could be done by simply encouraging someone else to "send in a patch". By simply itemizing what the issues are, as you've done nicely above, then all you need is some suitably motivated developer (like Lee maybe?) who could start banging on solving the issues. Even if that person cannot do it, they may be able to make enough forward progress that someone else could.
I'm reminded about how we did not have OSX packages when Inkscape first started, and there were a whole host of technical issues hindering us, many of which weren't in our control. Hardly any developers had Windows systems, let alone a Mac. The first few people who attempted to do OSX packages did not have success and got quite frustrated. Yet each person that attempted it nudged the ball forward a little bit for the next guy, and today, while I don't know if we can call it solved, it's usable on OSX.
Anyway, in the spirit of "patch first, discuss later", perhaps you could have Lee add his code in and then you can focus on the specific implementational issues where you see there may be better ways of doing things. I think you two can come up with a pretty brilliant feature if you work together on it.
I agree, I think that adding where it saves as a single compressed file is a good start. Figuring out how to do it so that it is more useful and works within Inkscape can come in the future.
Now that you've itemized the issues, why not let Lee have a shot at coming up with his own approach for solving them? It sounds like the single compressed file approach would not be suitable for his needs, so if he can come up with a patch that addresses a fair number of the issues, it would get us fairly far along.
Bryce
participants (4)
-
unknown＠example.com -
Bryce Harrington -
Lee Braiden -
Ted Gould