Can't create pdfs

[AcolinFlood]

Can’t batch or generate either .pdf files singly from RoboHelp 7. Says
“Internal error encountered, Failed to generate Printed Documentation.” This message is not only poorly punctuated, but also not very helpful.

Created Doc (horribly), not the pdf

[MergeThis]

Is this the same project that was discussed in your previous posting (one in which you were having trouble importing a Primo-generated PDF file with unsupported-by-RH image types)?

It might help us analyze your situation if you told us what format your data was in when you generated the PDF file using the Primo freeware.


Good luck,
Leon

[AcolinFlood]

same project? No. had no problem with the Primo pdf, it was the Adobe pdf with EPS images.

Here, I created a new project by importing Word doc: no problem with the graphics, some problems with text, TOC, tables, but I can't create the pdf from RH...

[MergeThis]

There's probably some corruption carried over from the original Word doc.

Try creating several Printed Doc layouts (Test1, Test2, etc.) and include portions of topics into each. Once you've narrowed the field down to one layout, break that out into several other layouts until you finally hit the bad topic. Not an easy answer, I know, but it should clear things up eventually.


Good luck,
Leon

[AcolinFlood]

BTW, most of the errors during the document or .pdf compile are created by InlineNormal types of text. Even changing it to Normal or removing the tag in the code does not seem to allow proper numbering. The numbering does not show in the Design view. Preview shows the sentence numbered, but it is the wrong numbering. I seem to remember that all text in Word documents should be Body, not Normal, before importing the document.

[MergeThis]

Read this article from Peter Grainge's site about importing Word docs. As you'll see, you have to actually manually Backspace Delete those numbers and bullets before you can go forward. There's other good stuff in there that might point you to fixing oher issues.


Good luck,
Leon

[AcolinFlood]

OK, this is an excellent resource, but the main complaint is still valid: RH should absolutely clean up and import files from the Word processor with 97% of the market! No wonder people are frsutrated - none of this stuff is in the RH Help files.

Though I must blame myself. I imported Word docs into FrameMaker a few years back and they needed to be cleaned up first before importing automatically. Just wish Adobe did a better job of preparing people for this.

[AcolinFlood]

Removed <meta name=Originator content=ImportDoc>
also <meta name="Originator content"="ImportDoc">

Multifile Find can't find p.Normal24 or any p.Normal or p.N

Warning: style (p.Normal24) is not defined and will be mapped to 'Normal'.
Warning: style (p.Normal44) is not defined and will be mapped to 'Normal'.
Warning: style (p.Normal43) is not defined and will be mapped to 'Normal'.

Is this what is preventing RH from generating a pdf?

[MergeThis]

You expect an HTML-based product by Adobe to "absolutely clean up and import files from" the Microsoft Word product, which produces perhaps the most bloated output of any on the market?

Pretty funny, dude...


Good luck,
Leon

[AcolinFlood]

Created test project with suspect pages. No warning messages, just this:

Failed to save 'Vista_and_XP.doc'...

[MergeThis]

Try this in Word:

1. Select Adobe PDF > Change Conversion Settings.
2. In the Settings tab of the Acrobat PDF Maker window, uncheck the Enable accessibility and reflow with Tagged PDF option in the Application Settings panel.


Good luck,
Leon

[AcolinFlood]

well, that is interesting: nothing happens when I click on Change Conversion Settings on the Adobe PDF menu embedded in Word. I can't seem to find this option by sleceting Adobe PDF from the Print menu either...

[AcolinFlood]

removed graphics, tables, images, deleted Orginator tag and nbsp strings, turned off all numbering in Word and saved as body text, yet Output View shows:

"Failed the generate PDF file 'C:\Documents and Settings\colin.flood\My Documents\Technical Writer\Help files\test\Vista and XP\!SSL!\Printed_Documentation\Vista_and_XP_Setup_without_formatting.pdf'...
Failed to save 'Vista_and_XP_Setup_without_formatting.doc'...
Cleaning up temporary files...

Internal error encountered, Failed to generate Printed Documentation."

[AcolinFlood]

OK. can't even generate a pdf from a new blank project with only RH text:

"First Topic


This is the first topic in your project. Delete this text and replace it with your
own. To add a new topic, click the New Topic button on the tool bar.

To learn more about the WYSIWYG Editor, pressF1 (with your cursor in this pane) to
display Help."

[AcolinFlood]

dont' think I can create pdf in RH 4 Word either

[AcolinFlood]

adobe pdf creation addon 8.1 is already installed on my my PC, so I can't re-install it...

[Peter Grainge]

You say
OK, this is an excellent resource, but the main complaint is still valid: RH should absolutely clean up and import files from the Word processor with 97% of the market!

That can be likened to saying that the plasterer should make up for any deficiencies in the bricklayers work. There's only so much that can be done. The rest is down to the quality of the input document. I am not saying your document was at fault but simply that you cannot always blame RH.

You ask

Multifile Find can't find p.Normal24 or any p.Normal or p.N

Warning: style (p.Normal24) is not defined and will be mapped to 'Normal'.
Warning: style (p.Normal44) is not defined and will be mapped to 'Normal'.
Warning: style (p.Normal43) is not defined and will be mapped to 'Normal'.

Is this what is preventing RH from generating a pdf?

No.

If you select to only generate the Word document, does that generate? If yes, what happens if you then try to generate the PDF from there?

[AcolinFlood]

Well, I am laying the bricks the way I laid them for a decade and no plasterer is telling me it is wrong.

I saw a parent in a pool with their young child recently.
“Swim,” they said, “swim!”
But the struggling child had no idea of how to swim. They did not know how to cup their hands, push down with their arms or kick their legs. They might as well have been laying bricks.

Take for example, Image mapping. RoboHelp’s own Help file does not say what this is, just how to click on the buttons. Duh! I have to go to a Sams book to find out that “image maps are graphics with hotspots.” Even better, take importing Word documents. The obvious steps are in RoboHelp’s instructions, but NOTHING is said about preparing the incoming Word document beforehand, such as changing Normal to Body text!

Now I have a HHC1000 error. Think there is anything in the Help file about what that error means in the context of this application? Nada. Not even a mention of HHC errors. Guess the Adobe QA people and Technical Writers never got any errors when they were vetting the product. They sure as hell didn’t document them for the benefit of Adobe customers.

I don’t know the top problems that a majority of customers have with RoboHelp, but believe me, if I craft the Help file, there will be two-tons of supporting bricks to shore up customer questions!

Thank you for your help, but it is easy to blame me for not laying the bricks properly without instructing me how to lay them. I am but a child with RoboHelp.

It may be hard for RoboHelp to plaster over Word’s crooked wall, but unless you tell me how it should built differently, that is exactly what RoboHelp should be able to do!


Using Word's Print menu, Adobe does create a pdf from the awkward doc created by RH. Never had a problem with that. So I guess that can be the work-around.

[Peter Grainge]

Whoah! Let me repeat

"I am not saying your document was at fault but simply that you cannot always blame RH."

The problem is that Word documents get prepared by many people of differing levels of Word expertise. If these documents have only been touched by you and you are happy they were prepared using proper styles and so on, then the source should be OK as long as some basics are covered. These are described on my site under Importing Word documents. I don't know where you picked up that Normal should be changed to Body Text but that is the reverse of the correct procedure. Sometimes though the documents have been through other less expert hands and "messed with" so that they look OK but are badly structured. Awhile back it took me a week to clean up some documents. Before the import was awful. After, it was near perfect. I don't blame RH, it was down to the creators of those documents, or to be more precise the lack of Word training they had been given. The documents looked good and that was all these guys needed.

** My ** QA people and technical writers? I don't work for Adobe. I am a user like you.

Now that I know you can create the PDF from Word, it seems likely you have hit the same problem as a few others where that method works but direct does not. That is being investigated at the moment. I have seen it on one PC with a project that is fine on another PC.

What is wrong with the document? Anything in my Printed Documentation article that helps?

Numbering has long been a problem. From what I have read about it, many Word guru's maintain that bullets and numbering have not worked so well in Word since the days of Word 2, many moons ago.

Take a look at the two articles and see if things improve. If not, post back the specifics and I will see if I can advise.

[Moonlion2]

quote:

---

Originally posted by: Peter GraingeFrom what I have read about it, many Word guru's maintain that bullets and numbering have not worked so well in Word since the days of Word 2, many moons ago.

---

True story. At least from a formatting point of view, they should not be indented--the bullets themselves are the distinguishing characteristic that sets them apart from the rest of the text. The indentations are redundant and ugly and have taught people the wrong way of doing things.

[AcolinFlood]

Thank you for talking the time to craft a thoughtful and complete reply. What do you mean by “using proper styles” in Word? How do new RoboHelp children know what that means?

Your articles were most helpful. I will take a look at them again, since I am re-cleaning up the new import of Word (lost graphics by moving the files) and see if things improve. I will post the specifics and thanks again for all your help.

[Peter Grainge]

The bit about being correct in Word is purely to do with creating things the correct way in that software, with no thought to RoboHelp.

What I am getting at is that many times you will see a document in say Verdana. If however you select all the text and hit Ctrl + Spacebar (which removes inline styling), then the text will change, probably to the default install for Word which is Times New Roman.

This is because instead of changing the normal style to Verdana, the user has not known how to do that so they select all the text and change it to Verdana. That does not change the Normal style though.

Similarly when they want an indented paragraph, they will hit the Word inline icon rather than create a proper style with an indent.

All shortcut methods that work if you just want to knock out a Word document quickly but not the truly correct way of doing things.

These are all things Word permits and for many users that's fine. However, when you start moving that text to other Word documents it can cause issues. Now imagine what happens with transferring it to RH. First RH saves the document using Word's function to save the document as a web page. Problem is now, on top of the foregoing, Word does not create good HTML but RH has to live with what it is given. Dare I mention the bad brick wall again?

Is that clearer?

[AcolinFlood]

yes, thanks, I did not know any of that stuff about Word, not from my Sams book (RH 2000), your web site or the RH help files. My point is, how was I supposed to know? My Word walls were fine until RH plastered them.

[Peter Grainge]

In a friendly way, perhaps your walls weren't as good as they looked and plastering them sort of exposed that? That is sort of what I was trying to say in my last post. The walls all looked OK and for many purposes were absolutely fine. However, for converting them from DOC format to HTML they needed to be more robust.

The things I described are the correct way to use Word, whether or not you use RH or any other piece of software. They are things you pick up from heavyweight use of Word if you like. Like many things, you can often "get away" with not doing things the correct way and using alternative methods.

How were you supposed to know? Like most of us with many things in life, by finding out when they break. :-)

I guess my other point is that I don't think it is up to Adobe to explain how to use Word. Microsoft have made the commercial decision to not enforce the correct use of styles as for the majority of their customer base, it doesn't matter. However, we are in a group of users where it is important.

Happy to help with the fallout from my answers!

[AcolinFlood]

I don't get who is determing the right and wrong way - where is the list or the lessons? Peter has a few on his web site, but I think it is up to Adobe to tell us how to prepare a doc file for import into RH; that is all I am looking for!