8.5 x 11 image on 8.5 x 11 page == image going off the edge?

[Andrew]

I'm new to creating decent print layouts with actual front matter, etc. from Flare. As the title of the post suggests, I have a page-sized image (8.5" x 11"), and I've added it as a background to a page layout that is 8.5" x 11". The right side of the image has been cut off (perhaps the last half-inch to inch), as if it was wider than 8.5.

I have done the following:

- Set all margins for the page layout to 0
- Set the image to no-repeat
- Set the X and Y coords in the page properties to 0
- Opened the image in Photoshop, and verified it is indeed 8.5x11

Anyone else have experience with this, or suggestions for troubleshooting? I'm out of ideas.

Thanks,
Andrew

[lacastle]

Usually printers have a default minimum page margin (around .2 inch), so they will not print the edges. If you really want an 8.5x11 image, you have to print on larger paper and cut it to size (it's called a full-bleed in printing terms).

http://en.wikipedia.org/wiki/Full_bleed

(but i don't know why the image would appear to be going off the page)

[LTinker68]

Also, make sure your html and body tags in the stylesheet have margin and padding both set to 0. At least in the print medium.

[Andrew]

Modification to my original description of the problem: the image looks like its running off of the right and bottom sides (as if it were locked to the upper-left corner, and the image was larger than the 8.5x11 sheet of "paper"). So the top and left look great; it's merely the bottom and right that are running off the edge.

Usually printers have a default minimum page margin (around .2 inch), so they will not print the edges. If you really want an 8.5x11 image, you have to print on larger paper and cut it to size (it's called a full-bleed in printing terms).

http://en.wikipedia.org/wiki/Full_bleed

(but i don't know why the image would appear to be going off the page)

Thanks Laura -- I know a bit about bleeds (at least enough to get myself into trouble ), but I thought they only applied to actual printers. In this case, I'm printing to PDF...does the PDF target have some problem, I wonder? I just tried the XPS print target, just in case, and the same problem recurs. Ah well.

Also, make sure your html and body tags in the stylesheet have margin and padding both set to 0. At least in the print medium.

Those are really good thoughts, thanks. After I checked them (all margins and padding in html and body tags in the print stylesheet), nothing changed, unfortunately.

[lacastle]

does the PDF target have some problem, I wonder?

Yes, i think PDFs have the same default margin issue.

[LTinker68]

I haven't played with inserting full-page graphics into the print layouts yet, but I know when I've designed brochures using Photoshop and/or Illustrator that I could have an image or color extend to the edge of the page and the PDF created from it would have the image/color extended to the edge of the page, too. It was only when I tried to print to one of our printers, which all have a default margin, that I got the white banding around the page.

Make sure you also check the settings on the page layout you're using. There are margins there, as well, I believe (and padding), and you can lock the positions, so make sure everything in the page layout is set to position the image at the correct location.

[Andrew]

does the PDF target have some problem, I wonder?

Yes, i think PDFs have the same default margin issue.

That's not the margin issue I'm having, though (printer bleed issues, AFIAK, mean you get an unwanted white border around your print, whereas mine goes all the way to edge). Unless I'm mistaken about the effects printer margins have on bleeds.

I haven't played with inserting full-page graphics into the print layouts yet, but I know when I've designed brochures using Photoshop and/or Illustrator that I could have an image or color extend to the edge of the page and the PDF created from it would have the image/color extended to the edge of the page, too. It was only when I tried to print to one of our printers, which all have a default margin, that I got the white banding around the page.

Yep, but I'm not seeing any white banding. Print goes all the way to the edge -- it just cuts off as if the image were too large.

Make sure you also check the settings on the page layout you're using. There are margins there, as well, I believe (and padding), and you can lock the positions, so make sure everything in the page layout is set to position the image at the correct location.

Yes, I've made sure of those.

Thanks for the ideas so far! I've just started to play around with image sizes to see if I can reduce the image size to make it work.

[LTinker68]

Is it cutting it off just in the XML Editor, or is it cutting off the image in the actual output?

[Andrew]

Is it cutting it off just in the XML Editor, or is it cutting off the image in the actual output?

Yes, on both counts.

[LTinker68]

Is it cutting it off just in the XML Editor, or is it cutting off the image in the actual output?

Yes, on both counts.

Well, at least it's consistent.

[Andrew]

Ah, I have a theory! When I reduced the size of the image to (according to Photoshop) 6.758" x 8.75", I get the correct size (it just fills an 8.5 x 11 sheet -- page size confirmed in Acrobat).

My theory is that Flare is basing things on pixels rather than inches, so given the resolution and inches, it comes out at the wrong size in Flare (for pixel counts). I'm going to put a call into MadCap tomorrow and see if I can get to the bottom of this...but if I'm right, it seems like a bug to me. Print Layouts should be figured in terms of inches.

[SteveS]

I think it could be photoshop.

If I take an image from Word to Photoshop and back again the image is suddenly bigger than when it started! PS Elements does it as well.

[Andrew]

Problem solved.

The crux of the issue is that Flare uses 96DPI to measure how many pixels in its "inches" while Photoshop can use *any* resolution and adjust the number of pixels per inch accordingly.

My graphic was 120DPI, so PS was setting it to 1020 x 1320 pixels, which at 120 DPI it defined as 8.5x11. Flare, on the other hand, saw a 1020 x 1320 pixel image as 10.625" x 13.75". I adjusted the DPI in Photoshop, and the output worked great.

My question now: how does one create a PDF output with a higher-DPI image? Wouldn't that require Flare understanding better than 96DPI, or is there some CSS trick, etc. that I am missing?

[LTinker68]

Try this... Leave the graphic at the high resolution. Then in Flare, create a custom img class and in the print medium, set its height and width dimensions to 11 inches and 8.5 inches. Apply that custom class to the front page image. It might not show up correctly in the XML Editor or Preview window, but try the output.

[KevinDAmery]

Problem solved.

The crux of the issue is that Flare uses 96DPI to measure how many pixels in its "inches" while Photoshop can use *any* resolution and adjust the number of pixels per inch accordingly.

My graphic was 120DPI, so PS was setting it to 1020 x 1320 pixels, which at 120 DPI it defined as 8.5x11. Flare, on the other hand, saw a 1020 x 1320 pixel image as 10.625" x 13.75". I adjusted the DPI in Photoshop, and the output worked great.

My question now: how does one create a PDF output with a higher-DPI image? Wouldn't that require Flare understanding better than 96DPI, or is there some CSS trick, etc. that I am missing?

To me that sounds like a bug (or an improperly implemented feature... either way it ain't right). If Madcap wants Flare and Blaze to be real print authoring tools, they need to handle DPI properly.

What I have been able to do successfully with Flare 3.1 and earlier is set the image size and DPI to exactly what I need in Photoshop, then manually add height and width specifications in the topic code to match. In other words, open your topic in the text editor of your choice and add

Code: Select all

style="width: 8.5in;height: 11in;"

directly into the img tag. That's been working for me in smaller images, so it should work for this one as well (in theory....) It's a pain to have to do this, plus I hate using inline code rather than proper styles, but I haven't found a better way to get it to work.

In case you need it, you can make a bug report here:

http://www.madcapsoftware.com/bugs/submit.aspx

[LTinker68]

It's a pain to have to do this, plus I hate using inline code rather than proper styles, but I haven't found a better way to get it to work.

Custom img class, although if you have just one full-page sized graphic, there's not as much reason to put a custom class in the stylesheet versus putting the dimensions inline.

[Andrew]

To me that sounds like a bug (or an improperly implemented feature... either way it ain't right). If Madcap wants Flare and Blaze to be real print authoring tools, they need to handle DPI properly.

What I have been able to do successfully with Flare 3.1 and earlier is set the image size and DPI to exactly what I need in Photoshop, then manually add height and width specifications in the topic code to match. In other words, open your topic in the text editor of your choice and add

Code: Select all

style="width: 8.5in;height: 11in;"

directly into the img tag. That's been working for me in smaller images, so it should work for this one as well (in theory....) It's a pain to have to do this, plus I hate using inline code rather than proper styles, but I haven't found a better way to get it to work.

In case you need it, you can make a bug report here:

http://www.madcapsoftware.com/bugs/submit.aspx

Thanks for your suggestion, Kevin! Unfortunately, the place where the image is specified is basically a background image. The XML code from the flpgl file looks like this (blue text):

Page Name="Title" Width="800" Height="800" Padding="20px" PageSize="Letter" PageType="first" PaddingLeft="0" PaddingRight="0" PaddingTop="0" PaddingBottom="0" BackgroundImage="../Images/Cover0875.tif" BackgroundRepeat="no-repeat" BackgroundPositionX="0" BackgroundPositionY="0">

I'm not sure how to I could apply a style to that using Flare. In any case, I found a workable solution for the time being; I'm going to talk to MadCap support about it, and ask them to create a bug report if there is no way to handle it.