We can’t export the graphic floor map to PDF from TRIRIGA. The system is “hanging” and not exporting. This is only happening with some drawings and only occurs when using Layer 0 from the Xref file ( xrefdwg | 0 ). If all other layers are off and a layer zero from any Xref is displayed on the graphics section, even if empty, the export will fail to complete.
The export graphic was throwing a malformed XML exception. The root cause was that there was a “1 = 1” element that got pulled in from the layout of an attached Xref onto layer 0 on that Xref. It turns out that, for any text element that contains any equals sign, the process of sending the SVG from the client to server using a Dojo API to post via a hidden input element, resulted in extra double quotes getting sent, and causing the SVG XML to be malformed.
We resolved this by pre-processing the SVG sent to the server to remove these extra double quotes, before sending it to the SVG converter. Moving forward, the export graphic will now successfully export a graphics section that includes text that contains any equals sign. Text that contains both double quotes and equals in it, will get the double quotes removed for technical reasons.
[Admin: To see other related posts, use the Xref tag or SVG tag.]
In Space Assessment, when creating a new assessment, I want to be able to save the floor plan on <triplat-graphic> as a PDF. Is it possible to do so?
There is no TRIRIGA UX feature to export a floor plan to PDF at the moment. One possible way of doing this is to create a page containing only the floor plan and use the browser (for example, Chrome) to export the page to PDF…
When reviewing the Associations tab, the lines connecting the associated objects were not solid or intact. There were broken lines in the SVG view of the Associations tab on a workflow. The lines connecting the objects were sometimes not fully intact.
The rendering of native scalable vector graphics (SVG) is handled on the client side in the client’s web browser. Different browsers render the native SVG files in different ways, which can result in the same SVG file looking different depending on the browser chosen.
If you review the same SVG file in different browsers that support native SVG rendering, you can see visual differences in how some SVG files are rendered. To resolve the problem, change to a different browser, if possible, that renders native SVG in a way that better meets your requirements. Otherwise, open a support ticket with the browser support organization.
[Admin: The same article is also posted in the Watson IoT Support blog.]
Why am I getting the error message “Current browser does not support native SVG” when running IBM TRIRIGA Platform 3.4.2 or later? After upgrading to IBM TRIRIGA 3.4.2 or later, I see this behavior when using Microsoft IE11:
- 1. Associations tab from records. The following error message is issued: “Current browser does not support native SVG.”
- 2. State Transitions. The following error message is issued: “Current browser does not support native SVG.”
Why does this happen?
Your Microsoft IE11 browser needs to be working fine with HTML5 so that inbuilt SVG rendering can work properly… The issue may happen with the following scenarios:
- SC01) You are running IE11 with Compatibility View on. Deactivate it, restart IE11, and try again.
- SC02) You are running with IE11 and its Enterprise Mode active. This will cause the IBM TRIRIGA Workflow Builder to fail when rendering some screens. Deactivate the IE11 Enterprise Mode, restart IE11, and try again. For more information on Microsoft IE Enterprise Mode, see this Microsoft TechNet page: What is Enterprise Mode?
[Admin: This post is related to the 12.10.15 post and 12.04.15 post about browsers that support native SVG.]
On some drawings, when users export the image to PDF from the Floor > Graphics tab, all or some of the labels are not shown in the PDF. The drawing is fine in CAD, and the Graphic section is fine. But the issue is only seen when exporting to PDF or PNG. The issue happens only with some drawings, and happens only with IE. It works fine with Firefox and Chrome.
As a temporary fix, use an alternate browser. This is a limitation with Internet Explorer (and Edge). A bug has been reported here. We cannot do anything to fix it on our end, but there are some workarounds: (a) use another browser to export, and (b) move the drawings closer to the origin coordinates and republish it. The text elements need to be inside of +/- 214749 to avoid this issue.
What is TRIRIGA looking at to determine that there is no native SVG present?
Starting with 3.4.2, TRIRIGA supports browsers that have native SVG support. So we basically just put an <object type=”image/svg+xml” …> and fill out the rest whenever we want to render SVG. If for some reason the browser does not support native SVG, then we have text behind it that will show the message “Current browser does not support native SVG”. All the browsers listed in our support matrix should support native SVG. If you are seeing this message, you might want to double check our support matrix and, for IE in particular, verify what rendering mode IE is using. In particular, we do not support compatibility mode in IE in 3.4.2 and later.
[Admin: This post is related to the 12.04.15 post about supporting native SVG.]
We’re in the process of upgrading our TRIRIGA platform to 126.96.36.199. We’ve done a Sandbox and a Development environment, which went fine. We had issues with workflows not displaying when we had the front end server not set correctly in those environments, but that was corrected.
When we upgraded out Test environment, we now get “Current browser does not support native SVG”. We’re using the same IE11 browsers we’ve been using for the other environments and they still work fine. We’ve tried different settings for front end server, but it changes nothing. I don’t believe that’s the issue because when that setting is wrong, we didn’t get anything to display. Now we get the native SVG error. Our Test environment is different from the other 2 in that we have an F5 server for load balancing and Apache runs on 2 physical boxes as opposed to running on the process server like it does in Dev. Any ideas on what could cause this problem?