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(a)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(a)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.
