Hi Bob, Here there are a couple of additional approaches to supporting a new .vsd image type: In Java one can add support for a new image type thorough the Java Advanced Imaging (JAI) API. If such support is added as a library in the oXygen lib folder then oXygen should automatically recognize that new image type. In your case, an option will be to add .vsd support though JAI that basically converts the diagram to svg and uses that further - or at least looks for an .svg file with the same name as the .vsd file and a newer timestamp and uses that instead, otherwise it can give an error that the SVG is not present or is out of date (older than the diagram). Out API allows also setting an URI resolver so you should be able to use also this to redirect the requests for .vsd files to .svg files. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 6/24/13 7:04 PM, Beims Bob-RWBC70 wrote:

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 <mailto: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 https://www.dropbox.com/sh/o7ezf0s5pu2gbir/5tnFEX0YSK

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 http://www.oxygenxml.com

From: practice innovation <info@practice-innovation.de <mailto: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

*//*

*/p/**/ractice 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 <mailto: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

_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user