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@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.
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
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 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 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> 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 <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
-- 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/