This was working as expected in FM8 from whence my application is migrating. In FM2019 certain images are being scaled without notification.
Our XML contains img elements which have a number of attributes: srcpath, height, width, dpi, optional caption. Because of the caption, when an XML document is opened in Frame a pre-processor stylesheet wraps images in a wrapper element which is given the caption, while the other attributes remain on the img element.
Our read-write rules file contains
is fm graphic element;
writer facet default specify size in pt;
attribute "src" is fm property file;
fm property import by reference or copy value is "ref";
It looks like any image which exceeds 792pt in width at any dpi is rescaled to 792pt wide, 300dpi, so those values appear to be significant. I haven't found a complementary rescaling because of excessive height, but perhaps none of our images are actually tall enough to trigger it.
Can anyone explain what is going on, please? And how I can stop this happening?
Hi Trevor, did you find a solution? We encounter a similar problem with rescaling graphics which was not present in FM 2015.
Although we work with sgml files. In FM2017 and FM2019, if we open one of the sgml files in FrameMaker some of our graphics get scaled down. We found out that if we skip the dpi attribute and use
"writer anchored frame specify size in cm;" in our read write rules when we create the sgml file that then the figures are not rescaled anymore.
The sgml file has then the impsize attribute set for the figure element containing the correct size of the figure.
The Adobe Manual "Developing Structured Applications with Adobe FrameMaker 2019", chapter "Changing how FrameMaker writes out the size of a graphic" says, when there is no specify size rule set, FramMaker will use the "dpi" attribute.
It seems that the "dpi" calculation in FrameMaker 2017 has changed.
I haven't got a solution yet, the problem is with Adobe support who seem to have accepted it is a bug.
It seems to me that there are two separate problems here: (1) the image scaling is triggered unnecessarily, and (2) when the image is scaled the width is changed but the height is not. I think your suggested rule change may address the first of these.