Skip to main content
T
Trevor-Nicholls
Inspiring
August 4, 2019
Question

Image scaling revisited, Frame won't play nicely, why?

  • August 4, 2019
  • 1 reply
  • 2400 views

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.

This topic has been closed for replies.

1 reply

T
Trevor-NichollsAuthor
Inspiring
August 4, 2019

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"/>
</wrapper>

T
Trevor-NichollsAuthor
Inspiring
August 4, 2019

The read/write rules which apply to images are these:

and for completeness here's the fragment in the EDD which applies:

T
Trevor-NichollsAuthor
Inspiring
August 4, 2019

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.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices