I've posted on this before but never arrived at a satisfactory outcome, so I'm going to have another go, filling in a lot more detail this time. It will take several posts to work systematically through my example so please hold off responding until it's complete.
In our application we have thousands of images, some at low resolution like 72ppi or 96ppi, some at higher resolutions like 192ppi, 200ppi or 300ppi. The content of our application is displayed in a variety of formats, only one of which is a printed page (or PDF equivalent of a printed page). In some formas we want to display the images in their native size and resolution, while in PDF we want to be able to scale the images to an appropriate size. We do NOT want to have to create multiple copies of every single image in separate formats for PDF, browser, e-reader etc.
The way our application handles images worked in FrameMaker v8, and our current FrameMaker 2019 implementation has inherited the methods that were used then. But they don't work the same. A "satisfactory outcome" for this thread could be one of two possibilities: recognition that Frame 2019 is flawed and a test case with Adobe that they accept as a bug, or an explanation of how Frame 2019 has changed and how I should modify our process to work with it.
Our XML schema allows for three types of image: floating images which have text flowing left or right, icons which are embedded within a line of text, and (standard) images which appear alone. I'm going to concentrate on this last type because it's the only one that is affected by scaling.
Our image element has a mix of attributes, some correspond to FrameMaker graphic properties and some do not. An image reference might appear in an XML document like so:
<img src="path/to/image" caption="caption" version="version" height="height" width="width" dpi="dpi" pdfscale="scale" />
The only mandatory attribute is 'src'.
As part of the load XML process we run a pre-process XSL which takes image elements and rewrites them as a wrapper/image pair. The graphic properties remain with the image, while the others are put into the wrapper element; the previous line in an XML document would, on load to FrameMaker, arrive as this:
<wrapper caption="caption" version="version" pdfscale="scale">
<img src="path/to/image" height="height" width="width" dpi="dpi"/>
The read/write rules which apply to images are these:
and for completeness here's the fragment in the EDD which applies:
Just to repeat: we have no problem with most images; images which are smaller than the margins of a standard printed page. The problem purely affects images which are too big to be printed without scaling in one or two dimensions.
For the purposes of this thread, I am working with a trivial XML document which contains a reference to a single image (wideimage.png) which is too wide to fit on the page.
Here's the document:
and here's the image:
Wideimage.png is 1017px wide and 296px high, and it has a resolution of 96ppi. That means that natively it is 26.91cm wide, which is about 66% wider than the print area of our standard A4 page.
I'd better point out that this initial document has not yet been loaded into FrameMaker; Frame always saves the image size and resolution when it writes out the XML document. I'm using it as a starting point with nothing but the image source specified.
So we load the test document into Frame. It displays the image exactly as we want to see it - scaled to the width of the page:
Checking the properties for the graphical object, we can see that it has been resized to 16.087cm wide. Although the source image resolution was 96ppi, the properties report an "unknown" dpi, and also state that the image has been scaled at 44.83%. I'm not sure where that last percentage comes from.
When we save the document, the image element has its attributes filled in, and this is where it starts to go wrong:
456pt is 6.33in or 16.087cm so the size is correct. But the image is not 300dpi, it is 96dpi. This means that when we load the saved image back into Frame, the image no longer appears correctly:
The graphic properties reveal that the image now occupies a quarter of the available area: 8.611cm x 2.506cm, scaling 24%.
The last thing I want to do is test what FrameMaker does with a few different image properties. When given the source image alone, the appearance is correct but the document is saved with an erroneous dpi so that subsequent loads of the document do not display correctly. We are looking for some combination of image properties that will (a) load the document with the correct display, and (b) save the document with the same properties so that we can round-trip without breaking the image appearance.
A. Let's try just specifying the dpi without a size:
The dpi seems to be ignored; the image appears scaled down to the page width and the object properties show the same scaling and dpi as before (44.84% and "unknown").
When the XML document is saved the result is the same as the original document:
i.e. the loaded 96dpi has been saved as 300dpi.
B. Let's try specifying the size without dpi. If we choose the correct scaled size for our properties, we won't know if the size is being ignored or not because the result would be the same. So we'll choose a size which is 90% of the scaled size:
If the size attributes are read and applied, the image should appear centered and slightly reduced in size. But something bizarre happens:
I note that the area occupied by the image has been reduced to 410.4pt x 119.4pt. But the image that is displayed in this area has been scaled to 456pt x 132.7pt, then truncated on the right and at the bottom to fit into the reduced size. This is confirmed by the object properties which show that the image size is 16.087cm x 4.682cm, with 44.83% scaling. I cannot believe that this is correct behavior.
Proceeding, when the XML file is saved, the image element records the same size as the input document, with the addition of dpi=300:
The erroneous dpi means that if this saved XML file is reloaded into Frame, once again the image is shrunk too much and displayed in only a quarter of the available area:
C. Finally, let's specify both size and dpi:
We saw earlier that the input file's dpi attribute appeared to be ignored; so it is here, which means that this outcome is exactly the same as B, both in what appears in the document view:
and what is written back to XML on save:
OK, that's the end of the example.
As I hope is now clear it is impossible to specify image properties in such a way as to cause FrameMaker to display the image correctly AND save the same properties back to the XML at the end of editing.
There are also at least two actions taken by FrameMaker which I consider to be incorrect: (1) unconditionally ignoring the input DPI and always writing 300dpi into the saved XML, and (2) scaling a wide image to the width of the page and then truncating it to fit a smaller specified size.
Can anyone help me with these issues?
Hi Trevor, let us look into this and get back. Thanks,
Hi Amitoj, thanks for responding here.
I have emailed you our test case.