Diagram image export - Margins mess up positioning

[mitch99]

Hi, I tried to find a solution here, but came up blank, so hopefully I'm just not thinking about it the right way.

I use the automation interface to export diagram images, which I use in a webbapp to show these images together with some mouseover notes picked up from the diagram objects.

To do this I need the position of each diagram object, so the mouseover will trigger when hovering over the right object/position. But when using the diagram object position values retreived from the automation interface the diagram objects won't align well with their counterparts in the image.

An obvious conclusion is that the added margins of the diagram image export (header, border etc..) isn't accounted for, which could be handled if they were the same on every exported diagram.

Unfortunately they seem to be different and I can't find a pattern to compensate for. So any help is appreciated!

Cheers,
Michael

[qwerty]

I might be wrong, but AFAIR the exported image crops to the bounds of the visible elements. No idea how this is calculated by EA.


q.

[johann]

we did that once in the past (generating a HTML image map with clickable diagram objects).

If I remember correctly: The information you need is located in the XMI export of the package that contains the diagram:

For every element in a diagram there is a tag that looks like:

Code: [Select]

<element geometry="Left=91;Top=507;Right=259;Bottom=591;imgL=25;imgT=502;imgR=193;imgB=586;" subject="EAID...

For locating the diagram object do not use properties (Left,Top) (Right,Bottom) of the attribute geometry. Use (imgL,imgT) and (imgR,imgB) instead.

The bad news: This seems to be the only location where this information is stored  
We were not able to locate it in the database. Maybe you can find an API function that does the job!?

[qwerty]

I'm not aware of any such API function. Maybe an export of the package as HTML would be an alternative. You could the check the output according to johann's instruction.

q.

[mitch99]

Thank you for all your creative suggestions! I tried to investigate them a bit further today:

Qwerty: I tried to handle the cropping by moving the leftmost diagram object to the left edge of the drawing area and the same thing with the top object, but still the margins are different for the exported images.

As for the html-export, the diagram image is cropped differently from the "normal" export and has no borders and title built in. From the html-files you can get the proper coordinates to go with these images. The problem though, is that it's a little tricky to the the EA-identity of everything from the html export, since names are just a sequence starting from the one with first exported object. Although in every detail html page you can find the guid of the object, but in my case when you export a part of the the library and some diagram objects are not physically located under the same package no details html page will be generated for them (and therefore no guid/id to get hold of..)

Johann: Maybe it's a version issue or different types of diagrams, but my Archimate 2.0 XMI-exports doesn't contain these values unfortunately:

Code: [Select]

<UML:DiagramElement style="DUID=C1757C54;UCRect=1;HideIcon=0;" seqno="1" subject="EAID_D3F48851_0823_4025_A6CC_EF94737CE2AD" geometry="[highlight]Left=89;Top=200;Right=179;Bottom=270[/highlight];"/>

Still work to do

[qwerty]

It's probably a good idea to ask for a new feature: ExportImageWith Coordinates which will export an image and additionally return the object coordinates along with the GUIDs. Whether Sparx will consider this is another question.

q.

[johann]

I had a closer look at the export: it should be any of the UML 2.x (XMI 2.x) formats, e.g. UML 2.1 (XMI 2.1)!

You must select the option "Export Diagrams" AND the option "Generate Diagram Images" (choose PNG format). Then the information is in the <xmi:Extension> section.

[mitch99]

Johann: Thanks for the extra details, I was doing XMI 1.1 exports as it's the default, which didn't generate the same xml. This seems to be the only doable way at the moment to get the data I'm interested in.

Qwerty: Yes that would definitely be a good thing, perhaps I should start with a bug report as the coordinate data you get about the diagram objects and the generated diagram image don't match?

One thing I noticed is that each kind of export (html, save diagram as image, xmi-export) generates a different diagram image, interesting...

My current setup is:
1) Query the sparxDB for any diagrams (actually returning the package guid) that have changed since last export.
2) Export XMIs for each package containing changed diagrams
3) Parse the XMIs to get the offset for each diagram.
4) Show it nicely on a Asp.net website.

A bit more work than expected at first

[Geert Bellekens]

Mitch,

Someone from Siemens recently published a free add-in to export a diagram to SVG.
http://community.sparxsystems.com/community-resources/706-svg-diagram-export-add-in
As the SVG format is vector graphics, you should be able to read it and then figure you the position of the most topleft element. From that position, and the general dimensions, you should be able to calculate a conversion factor to apply to each of your diagramobjects coördinates.

And as a plus, you get a far better image (scalable) with a much smaller size.

Geert

[mitch99]

Geert, thanks for the suggestion! Some other things got in the way, but so far I've downloaded the add-in and tried i manually. First i thought the diagrams would look rather strange since I read that "Unfortunately, structure and grouping of the diagram contents is not preserved." in the description of the add-in, but they came out as good as they look in the IDE, and quite small in regards of the size of the files as you said.

The next step was looking at the source files for the svg-diagrams, which I found rather hard to make any good sense of, in terms of getting the position data. It's probably due to my limited experience with the svg-format, but both the coordinate system and the structure of the xml elements didn't make much sense to me. I will have another go at it though.

Another thing is if you can call a add-in (eg. the svg export) via the automation interface? I guess you can, but I haven't found any hints of it in the automation reference manual or by some light googling.

Cheers

[Geert Bellekens]

Mitch,

I haven't done it myself yet, but it shouldn't be too hard.
You just have to mimic whatever EA is doing when it calls a function in an add-in.

So you'll have to create (or get a hold of) an instance of their add-in class. (SVGExport.EAPlugin)
That class should be registered in COM, so somewhere in the windows libraries there must be a function to create an object based from a COM registration.

Then on this object you will be able to call EA_MenuClick() just like EA does when you choose the option to export the diagram to SVG.

I've done something similar in my add-in tester tool https://github.com/GeertBellekens/Enterprise-Architect-Add-in-Framework/tree/master/EAAddinTester with the difference that this tool can only test add-ins that inherit my own add-in base class.

But in that tool I also play the role of EA in order to test my add-ins without them being loaded into EA (allowing me to compile the code without having to shut down EA).

Geert

[Geert Bellekens]

I've just done a quick test with regards to the SVG format, and I found it rather readable.

I quickly saw where it draws boxes, and what the position of those boxes is.

The full specification of SVG is available here: http://www.w3.org/TR/SVG/

Geert

[johann]

Mitch,

Accidentally, I am the author of the SVG Export Add-In (together with my intern). Let me say a few words.

In theory, Geert's idea is great and definitely the right way to go. If you can identify the SVG DOM element (rectangle or group) that constitutes your diagram object in the browser you are almost done - attach a Javascript click handler to it, and that's it!

But our SVG export can't offer that! This is what we tried to express with the release note  "Unfortunately, structure and grouping of the diagram contents is not preserved." !

As you have observed yourself, the contents of the diagram is preserved by the export (this was the major goal we wanted to achieve with this Add-In). We were able to do so, because we fetched very low level diagram information from EA, that is produced during the diagram printing process. At this low level you can't "see" or distinguish (for instance) class boxes with compartments and class members. All what exists there are lines and rectangles and bezier curves and text strings.

We would have loved to preserve the structure information for the SVG export, but the information was not tangible.

Sorry if this disappointed you
Johann

[mitch99]

I think my lesson learnt is that EA is not so straight forward in some situations, but on the other hand I'm impressed by it's flexibility, considering all the different methods suggested for solving this task.

Johann, thanks for clarifying things about the svg export, then it's not just my lack of knowledge of the svg-format... My initial thought after reading the add-in description was that you meant that the visual structure wasn't preserved, but as said, now I get it.

If things with EA were different, I agree with you both that svg would be the obvious way to do it, maybe in the next version

Cheers