I've got 2 SVG images which have the following size in Inkscape:
Image 1, the "large image:
width: 448 mm
height: 316 mm
Image 2, the same large image which I scaled in Insckape to the following size:
When I put this image in a DITA topic and generate a FrameMaker file from my ditamap (using DITA-FMx), I see that the size of the images becomes as follows:
Image 1 (large size):
width: 280 mm
height: 198 mm
width: 207.496 mm
height: 191.763 mm
In DITA, I haven't used any scaling attributes (@scale, @scalefit, @outputclass...).
When I import these graphics into a new FrameMaker file, the size is as follows
Image 1 (large size):
height: 396,001 mm
width: 207,496 mm
height: 191,763 mm
When I import the graphics at 90 dpi, they have approximately the same size as their original size in Inkscape.
Does anyone have any idea why the large image is scaled 50% in the FrameMaker file generated from the DITA topic?
Also, I see that, DIP is greyed out in the Object Properties dialog, so there seems to be no way to change the DPI setting afterwards (using a script, for example)?
I'm using FrameMaker 2017 with DITA-FMx 2.0.
I have issues with this as well. Currently putting a importing a very small SVG, but it comes in huge! And when I try to scale the image, only the fame resizes, the image stays the same size.
And what's the deal with asking about DPI?
I'm less and less impressed with FrameMaker. Seems to be stick in about 2005 in terms of support.
SVGs are tricky. It's not "just another image format" .. but really a little self-contained graphics environment. Unless you really understand what's going on inside of an SVG, you're likely to run into trouble using it in different programs. Because it's not a typical image format, it doesn't work the same way other graphic formats do, and programs that claim to support it may not always work properly (which is the case with FrameMaker and many other programs).
SVG is like HTML for vector graphics. It has markup/commands for drawing lines, circles, arcs, text, etc. It also can embed/include other images, either directly within the file or by referencing an external image file. The problem is that you can do the same thing many different ways, and it would seem that not all programs are designed to interpret all of the various ways the markup can be created. This is kind of like the way web browsers will render the same HTML/CSS in different ways (used to be more of a problem, but still is at times). Raster formats are "easy" to render .. it's just a stream of instructions. But SVG can bounce around and create all sorts of nested objects. Each object can have it's own scaling and other transformations. If the interpreting program isn't designed to handle a specific instruction, it'll be a mess.
You can open up an SVG in a text editor, and read the markup. In many cases, it's better to create the SVG by hand, than to use a program to create it. Many graphics programs don't even bother writing the markup and just fake the whole thing by stuffing a raster version of the image data into the SVG. While "valid" this is a bad technique and won't work right in all programs.
I was under the impression that FM 2017 had made great strides in SVG conformance. I haven't tested it so can't say. But I recommend keeping it simple. If you open up the SVG in a text editor and see a lot of "binary data", it's probably not going to work well. Read up on SVG and consider hand coding .. it's not rocket science, especially if you are reasonably familiar with HTML coding.
For sure, I think it depends what program you are using to create the SVG. An SVG built in Illustrator will behave differently than one built in Inkscape. When I first learned an SVG is really just and XML file I was floored. I was using Madcap Flare for a while and we had looked at using SVG for its vector output, however the SVG were created from SolidWorks models and in turn became huge files - much bigger than the same image saved out as JPEG.
Yes .. SVGs can be very efficient and small or they can be huge and bloated. An SVG of a CAD drawing will likely be on the large side. It's a great graphics format, when used appropriately. People get into trouble when they think of it as just another format .. you need to understand more about the format and take advantage of its benefits.