Resizing images on export to word

Forum|Forum|18 years ago
October 29, 2007
4 replies
1072 views

RH5X
Results of my testing show that when exporting to word, images are scaled vertically only if the height of the image does reach a certain value. For example, there is an image, let’s call it 1.png/gif at 400DPI, width: approx15cm (2362px), height: 1900px. There’s another image, 1.png/gif at 400DPI, width: approx15cm (2362px), height: 2208px.

Image 2 is displayed properly in Word (15cm horizontally at 400DPI), while the vertical resolution (not the height) of 1st image is extended.

My tests show that on export to word, the images that do not reach certain height (somewhere around 90% of the length at least) are extended vertically in terms of resolution (from 400X400DPI to 400 X <400DPI, for example).

Is it possible to control or override this behaviour (resizing images manually in word or reimporting them manually is out of question) and what is the reasoning behind it?

I'm afraid that this is yet another RH related question I posted that will in spite of many replies remain unanswered.

Documentation

This topic has been closed for replies.

Correct answer Peter Grainge

My first reaction was that we are testing with what seem to be unrealistic sizes as even the highest resolution screens could not cope with those sizes in the HTML format, other than by scrolling. The main point in picking up on the size is it doesn't surprise me that with such massive resizing, it goes wrong.

There does seem to be an easy solution though. Change your settings in RH from embedded images to linked images. Also look in Print Issues on my site. That covers a problem with missing images where the solution is to create an output with linked images and then follow a simple procedure to embed them afterwards. It will be interesting to see if when you know Word is doing the embedding, is the 1902 image still distorted or do both images then get displayed as you want.

Let me know please.

Peter Grainge

Correct answer

Community Expert

My first reaction was that we are testing with what seem to be unrealistic sizes as even the highest resolution screens could not cope with those sizes in the HTML format, other than by scrolling. The main point in picking up on the size is it doesn't surprise me that with such massive resizing, it goes wrong.

There does seem to be an easy solution though. Change your settings in RH from embedded images to linked images. Also look in Print Issues on my site. That covers a problem with missing images where the solution is to create an output with linked images and then follow a simple procedure to embed them afterwards. It will be interesting to see if when you know Word is doing the embedding, is the 1902 image still distorted or do both images then get displayed as you want.

Let me know please.

Use the menu (bottom right) to mark the Best Answer or Highlight particularly useful replies. Found the answer elsewhere? Share it here.

P

Primož_KuštrinAuthor

Known Participant

Peter,

The resolution of 400 DPI is a minimum for line art graphics to print or display without “jagged” borders (even though 600 DPI is recommended). From my RH project, I create both webhelp and pdf (using the acrobat word plugin and not robo2pdf), so I insert two graphics in RH files, one is “conditionalized” as “webhelp” and created at 72 DPI, while the other is “conditionalized” as “print” and created at 400 DPI.

The solution with linked images fixed the problem, since word is only an intermediate step in the process of creating the pdf, which is the final output. Thank you.

And finally, my prediction that the question will remain unanswered was proved wrong.

Peter Grainge

Community Expert

I think it is more accurate that we both work with the same image rather than a similar one. See the contact page on my site and attach the image.

There are a number of posts in the forums where pngs created with different applications work in different ways. That shouldn't be true but it is. Thus wanting to use your file.

Use the menu (bottom right) to mark the Best Answer or Highlight particularly useful replies. Found the answer elsewhere? Share it here.

Peter Grainge

Community Expert

I said I believed it was a Word issue, not that it categorically was. I picked my words carefully as I could not be 100% sure without getting some other application to export to Word. It is quite possible that Word handles pasting in and importing in different ways. It is quite possible that it is RH. My point here is simply to be cautious about laying blame.

Is the pasted in graphic entirely within the margins of the page?

Email me the image (via my site) and I will see what results I get.

Use the menu (bottom right) to mark the Best Answer or Highlight particularly useful replies. Found the answer elsewhere? Share it here.

P

Primož_KuštrinAuthor

Known Participant

With no intention of being rude or unpolite, I think it will take less time and effort if you just create two png or gif files using the data I stated in my first post in the thread, put them in a RH project and generate word output. I visited your web site, but the areas where files could be uploaded (emailed?) require a password.

Peter Grainge

Community Expert

I believe this is a Word issue. When Word receives images, and tables for that matter, if it cannot fit them on the page, it does its best to resize them. I am not aware of any way to control it.

Use the menu (bottom right) to mark the Best Answer or Highlight particularly useful replies. Found the answer elsewhere? Share it here.

P

Primož_KuštrinAuthor

Known Participant

When deleting the uncorrectly displayed graphic from a document generated by RH and reinserting it again (without any manual adjustments), word displays the graphic correctly. Peter, if your answer is correct, that means that words displays graphics uncorrectly only when they are exported from RH. Therefore, in my opinion, this still seems to be a RH problem.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.