Hi all,

My two cents on this ongoing discussion.

1.) Export of non native file formats

Everything that is not native Inkscape should go to an export/import. I think Bernard's case gives a great rationale for doing it that way. Indeed it takes less brain effort to just export and import and keep the work file in InkSVG format. I'm pretty used to Inkscape, but I've had my moments of doubt. I can imagine that for people less knowledgeable will make the wrong decision here.

2.) Template directory of choice - Template extension .svgt

It would be a really nice thing if you could put your templates in a directory of choice at least, so it would be easier to keep a selection of templates you'd actually use in it. Or in case you want to make changes to existing templates copy them to a new directory and edit them there without fear of messing things up.

Using the export again, it would be easy to save a file as template in the directory of choice, rather than just save the file and mess up the original template. Otherwise, save the thing as a new file and force naming it with a blank name.

Using an extension like .svgt feels a bit over the top. Next we'd have .svgr (resource file) etc. Whereas it is all SVG content with a few extra namespaces. Having a more logical way of organising your files seems more to the point to me.

Cheers,

Jelle

On Thu, 03 Apr 2014 08:22:59 +0800, inkscape-devel-request@lists.sourceforge.net wrote:

Message: 8 Date: Thu, 3 Apr 2014 11:22:51 +1100 From: Bernard Gray <bernard.gray@...400...> Subject: Re: [Inkscape-devel] Export workflow, template format proposals (discussion) To: Martin Owens <doctormo@...400...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Message-ID: <CA+Br8tPvQHPu3NeSeR7R1hkJL5-75rQ3FykAW0Kf4tDZDwja+A@...401...> Content-Type: text/plain; charset=ISO-8859-1 On 2 April 2014 21:36, Martin Owens <doctormo@...400...> wrote:

...

On Wed, 2014-04-02 at 13:06 +1100, Bernard Gray wrote:

...

I'd be keen to hear people's thoughts, and I realise this may be better as two separate discussions. My programming skills are fairly atrophied these days, but I would definitely consider having a crack at patching something. Paying for the features either in the form of a project donation or by specifically hiring resources are also possibilities.

Hi Bernard,

I think the solution might be to think of inkscape as the template creator and renderer.

So one can run inkscape from a script or command line in order to turn any svg into a pdf. This is useful for keeping things in svg until the last part of the process and you can automate this. I've seen solutions that watch a directory for svg files and render pdf files automatically.

Hi Martin, Thanks for the reply - I imagine that scripting is a common (and for us at least) a fairly simple option to implement. In my users case though, this goes back to limiting the locations where they can store the files, and I'm trying to remove this restriction on them. It'll also cause us support issues if the service isn't running, or they move the files and it stops working etc. The least added maintenance/support we the IT team have to do, the better. Like it or not, you guys have done a great job of the GUI interface. It's very accessible, and users can go from novice to functioning in a matter of minutes. For this scenario specifically, I'd like to leverage this feature

...

The other option is to print to pdf. Not sure if it's the same for inkscape's renderer or not though.

Great idea - for the HR guys, they're running windows so I'll check to see what print dialogs/renderers we can get access to there and that might be an adequate workaround for now.

...

For data entry. i.e. fixed fields. We could do more work there for sure. We don't really have a way of specifiying parts of a document which are configurable and parts that aren't. I don't think SVG2 is going in that direction either (please surprise me with a correction Tav)

Don't worry about this bit - to create this feature I've just added a layer of non-editable elements, and locked that layer. Then all the editable elements go on a new, unlocked layer.

...

Overall I think the work might be done with smaller scripts. Although we'd certainly appreciate the investment in inkscape to improve the save and export design. In my designs, save would be for any file. It would default and prioritise svg/plain svg etc, but if you selected pdf or png it would open the export dialog setting that file. Making it a two entry flow rather than two single flows.

That's an interesting take on it. I was thinking that we could potentially leave both flows in (ie adding the file types to the Export menu, but not removing them from the Save menu). I guess it gets complicated here because inkscape has the ability to handle PDF file types directly (opening and saving), so ideally you'd want to be able to save back to that (and similar) file types directly where applicable. One of the reasons I proposed the Export to... option and keeping the two flows separate was to maintain consistency with the workflows of other similar tools. I just realised that my knowledge of other tools (adobe cs suite for example) is fairly limited, so I just went and had a chat to the designers next door to see what is actually done - Illustrator: No "Export to... PDF" option, only "Save As...-> PDF". This behaviour is the same as inkscape currently InDesign: Has "Export to... PDF" option, but no "Save As... -> PDF" So it's no clearer My proposal is actually to support both these workflows - add the File -> Export to... PDF menu option, but leave the "Save As... -> PDF" option intact. This gives the opportunity for a user to not have the source file changed from underneath them via a save operation *if they choose* and significantly reduces the risk of it happening inadvertently, but leaves the scenario where you can change the working file to a different format deliberately, *if you choose*. It can also open up the opportunity for exporting to other bitmap formats (like jpeg which I occasionally find myself having to take and extra step to convert to from time to time)

...

There's little reason to consider pdf options and png options to be somehow different.

The options for exporting aren't different per se, but the concepts of Exporting vs Saving *are* very different. That's the key issue I'm working to resolve.

...

Best Regards, Martin Owens

Any thoughts on the svgt(emplate) file proposal? I raised the idea with the designers, and they really liked it. Apparently they are constantly fixing "template" files that have been accidentally overwritten because someone forgot to take a copy first, or remember to use Save As for the first save.