🚀 go-pugleaf

Hi Bruce...

Are your images actually distorted or just cropped? By default anchored frames have the "cropped" setting enabled, which will keep images from extending beyond the text column width. To disable cropping, add the following rule to your image element rule in the read/write rules file ..

fm property cropped value is "0";

This and other DITA/FM tips are available here ..

 <http://kb.leximation.com/dfm/>

Cheers,

...scott

Scott Prentice
Leximation, Inc.
www.leximation.com

Ah, I was wondering where to set that cropped value, thanks. But, that didn't solve my issue. It still reads in the graphic, restricts it to 612pt width, and writes it out as such, distorting the display.

It did occur to me that 612 / 72 = 8.5, the printer paper width, but changing to landscape didn't help, either. So, I'm not sure what's cooking.

I'll keep looking, but any further suggestions greatly appreciated.

Thanks
Bruce

Bruce,

As far as I know, when you import a graphic, Frame creates an anchored frame large enough to hold the graphic, BUT does not allow the anchored frame to extend beyond the boundaries of the paper. So, if you first set the paper to landscape and then insert the graphic file, Frame creates an anchored frame that is no wider than 11".

Are you sure that the graphic is being distorted? If you right-click the graphic and select Object Properties, the dialog box should show 100% in the scale by box. IF the graphic is indeed distorted, this box will be empty.

So, you will have to scale the graphic after it is in the Frame file. OR, add a read/write rule (if one exists) that does some scaling during the import. OR write an XSLT transformation that calculates the scaling factor and sets an attribute to the factor, which a read/write rule uses to scale the graphic.

Van

Thanks, Van.

Yes, I figured that constraint should be due to the paper size, so switched the orientation to landscape. The graphic itself is 738 wide, so at 72dpi that should be 10.25, which fits in the 11" paper. Making that adjustment, resetting the dpi to 72 (which then shows 100% scaling), and saving the file, the xml comes out:



<image height="592" width="738" align="center" placement="break" href = "hello1.gif" />

So far so good. Closing and reloading the file, verifying that the print setting still has the paper in landscape (is there another place to set this?) and looking at the graphic, the width is again constrained to 612, the dpi is unknown and the percent scaling is empty (I didn't realize that was an actual indicator of distortion, so thank you). Saving the file again, without readjusting the graphic, produces:



<image height="592" width="612" align="center" placement="break" href = "hello1.gif" />

reflecting the constraint.

So, yes, I'm quite sure that the graphic is distorted, and not seeing that setting to landscape (or changing the paper size at all) is helping.

Hopefully, I'm missing something, but I'm not seeing it. I do have 8.0p277, but am not finding any updates so think I'm current.

Bruce

Bruce,

How do your read/write rules translate the attributes height and width to the corresponding Frame properties? If you are translating height to height and width to width, then note that within Frame height and width correspond to the height and width of the anchored FRAME, not the bitmapped image.

So, you might try giving your image element an impsize attribute, which is Frame's default for the import size of the bitmap. It contains both the width and the height of the bitmap. So, your image element would look like:

<image impsize="738 592" align="center" placement="break" href = "hello1.gif" />

Note the space between the width and height. You might have to specify as impsize="738pt 592pt" (I am not sure about this last bit; in my application, I specify the size in picas, as pc, and it works fine).

Van

Van,

Thanks, and I might try that, but would rather not hard-code those dimensions. Since the problem was with scaling GIFs, which don't scale nicely, the better approach seems to be to ensure that the GIFs don't transgress that 612pt limit. This involves a small change in our approach to screen captures, but is trivial. I don't like screenshots bigger than that, anyway, so it's all good.

Bruce