[oXygen-user] Integrating an SVG editor with oXygen

[Eliot Kimber]

The SVG domain for the proposal is pretty trivial. Your choices would be:

1. Use the domain as currently proposed. This would mean that if nothing
changes between now and finalization, you're done. If the proposal is
rejected entirely, the domain still works and is usable, you'd just have to
change the indications of ownership (and if the TC for some unlikely reason
rejected it, I'd add it to D4P).

2. Copy the 1.3 domain and rename the tags so there's no chance of
collision. This means you might want to update your documents in the future
to reflect the now-standardized tagnames, but the change would probably only
be to tagnames and your shell document types.

As part of the proposal I've already implemented simple Toolkit plugins for
HTML and PDF generation (which just means copying the SVG to the HTML or FO
output, for the most part).

Cheers,

E.

On 6/24/13 6:04 PM, "Bob Beims" <rwbc70 at freescale.com> 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 at 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 at 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 at practice-innovation.de
> <mailto:markus.wiedenmaier at practice-innovation.de>
>  
> 
> 
> 
> On 6/24/13 2:23 AM, "Eliot Kimber" <ekimber at 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

-- 
Eliot Kimber
Senior Solutions Architect, RSI Content Solutions
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.rsicms.com
www.rsuitecms.com
Book: DITA For Practitioners, from XML Press,
http://xmlpress.net/publications/dita/practitioners-1/