Known Participant

Answered

Tables resized in printed documentation

Forum|Forum|18 years ago
August 8, 2007
6 replies
1997 views

RoboHelp HTML Version 6
I create a project.
I add topics using Word as my editor.
I add tables to the topics. All of them are specified as being 7.6" wide (740 or 760 pixels when viewed on a screen, perfect for 800x600).
Also, when I print with a 0.45" margin on each side, 7.6" is the perfect width for printed documentation.

I spend 3 months creating this project with 150 pages of printable documentation.

I go to export to either .DOC or .PDF and get the same results either way:
Around 50% of my tables have been shrunk to 6" wide. The other tables are still at 7.6" wide.

I call in to Adobe technical support and explain this. They try to replicate the issue and are able to replicate it. They don't have an answer right away but agree it should not be acting like this. The rep and I phone and e-mail each other for a few days. I eventually end up talking to another rep who also cannot provide an answer. It is escalated to her supervisor, who tells me he also does not have an answer, but he will escalate it to Level 2 Technical Support.

Level 2 called me and stated that this is "expected behavior," that RoboHelp does this on purpose.
"Shrinks HALF of my tables to 6 inches and leaves the other half at 7.6 inches?"
"No," he replies, "it should shrink them all to 6 inches."

I told him I don't buy this answer, that RoboHelps printed documentation should look the same as it does on the screen.

He says he will have a Level 3 Technical rep call me, but I have not gotten a call.

Can someone please tell me what I need to do to have my printed documentation come out looking the way it does on the screen?

Thanks.
-Sean

Documentation

This topic has been closed for replies.

Correct answer Peter Grainge

We have found the problem and, for once, Word is not the culprit notwithstanding the code seen.

It seems that if you create a table editing in Word and there are no merged cells, when RH generates the printed output it sends it to Word as the defined width unless that is greater than the width between the margins when it scales the table to fit that width.

If however the table has merged cells, it does not get scaled and overruns the margins.

Having both types of table caused the difference. Cheeop has now gone back to Adobe on this and hopefully when he gets a response, he will mark this as the answer.

S

Sean ArenasAuthor

Known Participant

The last I talked to Adobe was last week. They wanted to see our e-mail thread, so I forwarded it to their Level 3 Technical Support. I haven't heard anything back. They said they would be in contact with you. I'll go ahead and mark yours as the answer as we now have output.

Thanks.

Peter Grainge

Correct answer

Community Expert

We have found the problem and, for once, Word is not the culprit notwithstanding the code seen.

It seems that if you create a table editing in Word and there are no merged cells, when RH generates the printed output it sends it to Word as the defined width unless that is greater than the width between the margins when it scales the table to fit that width.

If however the table has merged cells, it does not get scaled and overruns the margins.

Having both types of table caused the difference. Cheeop has now gone back to Adobe on this and hopefully when he gets a response, he will mark this as the answer.

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

P

prashanta91555329

Known Participant

Hi Peter,

I am creating two word outputs (documents). First output has table that has merged cells; it overruns the margins. Second output has simple table where cells are not merged; tables are shown as expected in word output.

Is this issue resolved? Or is there any workaround for this?

I am using RH9.

Regards,

Prashant

P

prashanta91555329

Known Participant

Hi Peter,

"Can you or somebody from your team reply to the following question?

I am creating two word outputs (documents). First output has table that has merged cells; it overruns the margins. Second output has simple table where cells are not merged; tables are shown as expected in word output.

Is this issue resolved? Or is there any workaround for this?

I am using RH9. "

Regards,

Prashant

H

HKabaker

Inspiring

Cheeop,

I looked at your site.

Here are some things you should look at.

1. You may want to stop using Word as your editor, if the primary output is html, and use RoboWYSIWYG or another html editor.

2. In your output tables, you have this phrase:

padding:0in 5.4pt 0in 5.4pt;

I see this in tables originally created in Word, then imported into RH. You probably won't see it in the RH html table properties dialog, and it thwarts any attempt to adjust padding values in RH.

It's possible that this code confuses the conversion of tables from RH html to Word. For a long time now, I have made it a point to search for all such garbaage in tables imported from Word, deleting or revising as necessary to clean up the table code. (The utility called FAR does this in a flash; just be sure the RH project is closed when editing table code.)

I suggest creating one of your tables from scratch in RH, copying only the text in each cell, and using the table properties dialog to approximate the original. Compare them in new WebHelp output.

3. Some of your table widths are specified in inches, others in pts. Is it possible that values like 49.1 pts are the cause of shrunken tables? I don't know.

4. I have never seen html table code like this:

mso-border-left-alt:solid gray .5pt;
and
mso-padding-alt:0in 5.4pt 0in 5.4pt;

I think this is Microsoft Office markup. Again, the RH conversion of html to Word might not interpret this code as Word expects to see it..

5. RH always creates a Word version of printed output, even when you have specified a .pdf version. That's why you won't see any difference in .pdf alone.

I hope this helps.

Harvey

S

Sean ArenasAuthor

Known Participant

Another thing I would like to add about this project, is that it shows up just fine on the screen.

When I go to do the export to a printable format, it doesn't matter if I choose Word or PDF destination, it still does the same torture to the tables, shrinking half and leaving the other half alone.

It has not changed my images at all, either in the on-screen format or the printed format, so I do not believe the tables are affected by images, and the images are not affected by the tables or margins.

I called Adobe Technical Support again today. They verified that they promised me an escalation to Level 3 Technical Support three days ago, but no one has called me back. I asked when I would receive a call from Level 3, and was told they don't know. I asked for a supervisor so they could tell me when I would get a call from Level 3, and all supervisors are in a meeting.

The representative told me that she would have a supervisor call me back after they get out of their meetings, but it's been two hours and I have not had a call. It's now time for me to leave work and go home for the week.

This particular case has been open with Adobe for 3 weeks, and I had the problem for 3 weeks before that. We now have customers who need our printed output, and I am not able to provide it for them.

S

Sean ArenasAuthor

Known Participant

Hi Peter, thanks for the reply.
There's nothing secret in this documention. In fact, it's available online at www.emcmanual.com.
I took over the project in April this year, so everything Version 7 and previous was not mine.
Mine is under Version 8 - just select Verson 8 on the left menu, and all topics in it were rewritten or written fresh by me.

I will create a new project as you suggested, but I know that the Adobe folks were able to re-create this problem while still on the phone with me. I'll e-mail it to you as you suggest.

A

Anonymous

I have a suspicion of what might be happening.

It was the 6.00" pictures that gave me a clue. That's the width of the Word page in the default document template. When RoboHelp generates a Word document, it creates an empty Word file first, and then it applies the template you chose in the Printed Doc wizard. As if you clicked the little white page in the Toolbar - not as if you clicked File > New in the menu and selected a template.

When Word inserts a picture that's wider than the available page, it resizes it to fit in the margins (and that's the Page Setup left and right margins, not the actual margins of the line, which might have indents). So if your normal.dot template has 1.25" right and left margins in the Page Setup, RH may be resizing the pictures to fit, then applying your beautiful template with its .75" right and left margins. And now you have squashed pictures.

I don't know exactly which templates RH refers to in the printed doc generation process, but I would start by changing the Page Setup margins in normal.dot to .75" right and left. Oh, yes, and while I was in Page Setup, I'd reset the default page setups to have those margins, too.

Let me know if you have any success bending Word to your will!

Elisa

S

Sean ArenasAuthor

Known Participant

Hi Elisa, thanks for replying.

In my several weeks of trying to fix this issue, I have opened the topic from within RoboHelp, seen the 1.25" margin, and reduced it to 0.45" (and even 0.25" just for grins). When I produce the printed documentation, it still shrinks half of the tables to 6" and leaves the other half at 7.25".

The really confusing part here is that it does NOT change half of the tables to 6". If it changed ALL of them to 6", I would believe it's intentionally adjusting my page for me. The fact that it's only changing around 50% of them tells me that it is not an intentional thing, meaning "bug."

Peter Grainge

Community Expert

Nothing surprises me if you are using Word to edit HTML topics. Petrol and diesel mix better. However, you are using Word so we have to go with that.

Can you create a new project and import a couple of topics that demonstrate this problem? If the content covers converting base metal to gold, you can change the content but don't mess with the tables. Generate an output and check the problem exists.

Then zip that up and email it via my site.

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

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.

Scanning file for viruses.

This file cannot be downloaded