Copy link to clipboard
Copied
If you create a graphic in Visio and export it to SVG and then import the SVG image into FrameMaker, you are still getting displaced objects in the graphic if you use either Visio stencils or group the image. I thought they'd fixed this, but apparently not.
Edited to add: In the attached images, the "room" is a Visio stencil. As you can see, the back wall is displaced in the image as imported into FrameMaker. None of the other components are grouped.
New bug is here: https://tracker.adobe.com/#/view/FRMAKER-9089
Copy link to clipboard
Copied
How does it look like in the PDF output? What you see in FM is a rendered "preview" of the SVG as a pixel image. When published to PDF, the actual SVG is used. How does it look like there?
Copy link to clipboard
Copied
Drat, I thought I said. It looks the same in the PDF file as it does in FrameMaker.
I'm actually surprised the bed didn't get messed up, also
Copy link to clipboard
Copied
Do you have Adobe Illustrator? If so, try to open the SVG from Visio there. How does it look like in Adobe Illustrator? If it is okay there, save it as a new SVG (under a new file name). This should clean up the SVG from Visio a little bit. Then try to import it again into FM.
Also, feel invited to send the SVG to Adobe Technical Communication Support Team for some testing. (You can put me on CC - would love to have a look as well!)
Copy link to clipboard
Copied
This is a long-standing bug, from at least FM2017. As I recall, I had asked if this was being addressed in a number of the 2020 beta-meetings and was told it was. Unfortunately, I didn't have time to test it or I would have reported this earlier. I have already had multiple discussions with TCS support about it.
Edited to add: I have also sent them an origional Visio file that produced SVGs that are rendered correctly in any browser but did not render correctly in FM or in PDFs as well as the output SVGs.
Yes, I have Illustrator, but I have never really used it. I just now tried opening the SVG file in Illustrator and it looks even worse. Even if it looked perfect, though, I don't want to have to go through a second program to get a usable output.
Either Adobe is not interpreting the output from Microsoft's Visio-output SVG files correctly, or Microsoft is screwing up its SVG output. Which actually wouldn't surprise me one bit.
The below is a screen capture of the SVG opened in Illustrator.
Either way, it looks as if I'll be having to keep using PDF files instead of SVG files for graphics. It makes the final documents larger, which annoys me, but with storage and bandwidth no longer major issues for the users of my output, I'll have to put up with it.
Copy link to clipboard
Copied
If the PDFs of the art look OK, you could use Illustrator to convert them to SVG.
They might even be batched with an AI Action. I used to do this (to EPS) in days of yore when PDF import into FM wasn't stable.
Copy link to clipboard
Copied
Sure. But that means I have to:
Right now, I:
The only thing I know how to do in Illustrator is open it and save from it. I don't even know what an AI action is, and since doing that adds a fourth program to my process and 2 extra steps, I think I'll stick to what I'm doing. Not that I don't appreciate the suggestion, I do; but all it gets me is a smaller PDF document file, and using the Optimize option once I've done all the other post-processing things I have to do in Acrobat is far easier for me.
Edited to add: and, dang it all, it shouldn't be NECESSARY. SVG is supposed to be an open standard. There is no excuse for this to be happening, and it irritates me that something that should work well is actually working badly.
Copy link to clipboard
Copied
AI (Adobe Illustrator) Action, basically a macro you record, step thru & save.
A question worth poking into is why the PDFs are so large. The top suspects might be:
0. embedded app data (like the compatibility settings in Photoshop)
1. embedded {raster] thumbnail/preview image
2. embedded fonts
3. curves being converted to bazillions of short line segments
#0 is completely unnecessary with rational object stewardship
#1 is completely unnecessary in the final FM document
#2 likewise, if font(s) otherwise used in the FM doc.
I'd expect generating/preserving/stripping the #0-2 stuff to be AI save/export options.
#3 might be an open-time option.
Copy link to clipboard
Copied
Lin, can you attach the SVG as well to the JIRA ticket.
thanks
Amitoj Singh
Copy link to clipboard
Copied
Done. I tried to attach the Visio file also, but it wouldn't let me do that.