George, Markus, Eliot;

Thanks for the input! I'm trying to re-connect the threads and respond to all three of you at once.


George;

I've downloaded the recording and will pass it along to our developers.


Markus;

Your crop action looks like a great start. 

As for our use case, we're attempting to provide a "unified" was to create/edit DITA text, SVG images and MathML equation editing through the oXygen user interface. This is to support those users who come from a desktop publishing tool background and are "bothered" by needing to open multiple tools to edit different object types and then inserting links from DITA topics to point to images and equations.

So I want to associate SVGs with Inkscape (or perhaps some other tool) and MathML with MathFlow so that when users want to create an image or equation they simply select the appropriate action from the Insert menu and the proper tool is created and appropriate markup added to the DITA file. Alternatively, if they double-click on an already-rendered equation or image, the appropriate editor will launch.

One of the enhancements we'll need to make to the inline method you're using (and which the default equation editor in oXygen uses) is to create an external file that is then linked from the containing DITA topic. One of the workflow requirements for this is for those particular image types which use a non-SVG file format for advanced edibility, but export SVG for rendering. For example, consider this use case:
  1. a user wants to create a swim lane chart using Visio and render the chart in a DITA-sourced publication
  2. since Visio's native file format is a proprietary binary (.vsd) it can't be embedded (easily) within a DITA topic; nor can it be rendered via non-proprietary processing
  3. since Visio can export SVG, a "rendered" version of the chart can be easily created and embedded (or linked from) a DITA topic
  4. so in this case, I'd like to create an Insert > Visio Diagram menu option in oXygen that would 
    1. launch Visio and once the user is done creating their swim lane chart
    2. both the .vsd and .svg files would be stored on the user's local file system (or in a CCMS)
    3. a link to the .svg would be added to the DITA topic
  5. if the rendered SVG is double-clicked later, Visio would be launched in order to edit the .vsd and then upon close both the .vsd and .svg would be updated


Eliot;

The enhancement for DITA 1.3 sounds very promising, assuming it is adopted by the TC. In the meantime, would you recommend creating a local specialization to provide such functionality? It could be tricky to create those specializations in such a way as to not collide with the future DITA 1.3 behavior.


Regards,
Bob


On 6/22/13 12:46 AM, Beims Bob-RWBC70 wrote:

Has anyone tried to integrate an SVG editor (for example, Inkscape) into
the oXygen UI such that the Insert > Insert Image dialog that pops up has
an option to create a new image rather than referencing an existing one?
If so, would you mind sharing the challenges, successes, failures along
the way?

Regards,
Bob Beims

Applications Engineer, Staff Principal
Information Development Systems & Methodologies

On 6/22/13 1:25 AM, "George Cristian Bina" <george@oxygenxml.com> wrote:

Hi Bob,

Markus Wiedenmaier created a custom action to annotate an image in a
DITA document using an external image editor, Inkscape was the one I
tested this action with.
Basically you trigger the action on an image and that action takes the
image inside Inkspace where you can add different annotations or perform
different transformation on the image, like crop for example. The result
SVG from Inskape replaces then the actual image in the DITA document.
This is a nice way of adding annotations or changes to an image while
keeping the original image unchanged.
You can find a demo of this in a recording from our users meetup from
Prague this year

While this is not exactly the action you want, it is close and a little
more complex, so creating a new image though an external editor is also
possible and probably Markus can easily change his action to do that.

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger


From: practice innovation <info@practice-innovation.de>
Organization: practice innovation
Date: Sunday, June 23, 2013 9:56 AM

Hi Bob,

 

I saw George already answered to your question this early morning.

 

With the extension George mentioned you are able to edit embedded SVG images too.

So if you add an empty SVG-Element to your content and execute that function, you are able to create a new SVG image.

That’s not nice at the moment, but it’s not a hard work enhancing this functionality that way.

This functionality works with any SVG editor (Inkscape and Adobe Illustrator are used in my projects) and it works with any XML flavor which supports embedded SVG (not DITA only).

SVG images are always embedded to your XML content file and aren’t referenced to file system.

 

Our first thinking of implementing this extension was a reuse of existing images in different contexts. You want to create one single image, enhance it and use it in different manners. As this SVG is embedded we don’t think about any reuse.

Perhaps in DITA it could make sense to enhance the reuse potential by using conref functionality, but this of course depends on the requirements, concepts and processes.

 

I’m not sure about your use case(s). Could you provide more information, please.

 

Best Regards

Markus Wiedenmaier

 

practice innovation
DE-78259 Mühlhausen – Ehingen

Email: mailto:markus.wiedenmaier@practice-innovation.de

 

On 6/24/13 2:23 AM, "Eliot Kimber" <ekimber@rsicms.com> wrote:

For DITA 1.3 we are planning to include a built-in SVG domain. The proposal
is currently at stage 3 (meaning the proposed specification changes are
under review by TC members).

The proposed design provides a specialization of <foreign> named
<svg_container>. <svg_container> may then contain <svg:svg> or <svgref>,
which is a reference to <svg> elements held in non-DITA documents.

For reuse you have two options with this design:

1. Use normal conref for <svg_container>

2. Use <svgref> to use SVG markup directly from non-DITA documents.

Cheers,

Eliot