Generating HTML in RoboHelp 10 from FrameMaker 11

Hi,
In FrameMaker 11, i have a .fm source file that uses a custom template. In RoboHelp 10 (trial), how do I create a HTML help file from the source .fm file? Please note that I have a separate .fm template that contains the mappings for the generated HTML (which is different from the source file).
Thanks for your help!
Kathy

You can use the FM template file to control the formatting from FM, but that's a bit like driving the car from the backseat
Jeff is right, though, that sometimes the template is required and the blog post he referenced will help you to do that.
Instead, consider watching me do a one-hour run-through of the process at http://adobe.ly/16hU5db.
Beyond that, please contact me offline to help with specifics.
-Matt
Matt R. Sullivan
co-author Publishing Fundamentals: Unstructured FrameMaker 11

Similar Messages

When generating HTML Help, RoboHelp does not include all of the topics. Why and how do I fix it?

w

Looks like the rest of your post went for a walk.
See www.grainge.org for RoboHelp and Authoring tips
@petergrainge

Generated html does not open in firefox/safari when embed in an iframe

Hello,
I have been meddling with robohelp for a few weeks now. I can generate a html site from a Framemaker book fine. This is embed in an <iframe> to integrate it into our website. It works correctly on chrome. However on firefox/safari all I get is ' ï»¿ '. On viewing the source, it becomes apparent that this wierd bunch of characters appears before the <html>. I looked into the actual html generated and I see this tag <feff> prefixed before <html> in every file. Naturally, I went ahead and removed it and the page now loads correctly on firefox/safari. However, the bullets are all messed up. I read a post somewhere which said <feff> contains some information about css classes.
I use Technical Comm Suite-3.5(full version). The webhelp html is generated using the publish functionality from framemaker using a saved *.isf settings file.
So how do I fix this? Any suggestions are welcome.
Thanks

The "weird bunch of characters" is known as the BOM (Byte Order Mark). The problem is on the server.
I saw the same thing when first using RoboHelp 8 and this is what I was advised by the company hosting my site.
"I would therefore conclude that the solution to this problem (on Linux systems running Apache) is to add the AddDefaultCharset utf-8 directive to either the Apache config or the site .htaccess file. The advantage of the latter is that it only affects individual sites. The default Apache character set is taken from the locale file on Linux and defaults to iso-8859-1. It is the conflict between the Apache header with iso-8859-1 and the page character set of utf-8 that obviously causes Firefox a problem."
In a forum post Chrissy_Tissy added
My machine is Windows, but this fix still worked - some notes about making the fix visible:
1. Do the fix itself (httpd.conf: AddDefaultCharset utf-8).
2. Restart the box to apply the fix.
3. Once the box is restarted, clear your cache in FireFox to make sure you don't continue to see the cached file.
Once all this is done you will see the output content as expected.
See www.grainge.org for RoboHelp and Authoring tips
@petergrainge

Best HTML generators for use with Framemaker

Hi,
I'm currently evaluating the latest version of the technical communications suite, but I am now
concentrating on Framemaker with other ouput generators and would be interested to know
what other people's experiences are. I really like Framemaker and think that the quality
of the PDF is great. However, RoboHelp is unlikely to work for us, based on the poor
quality of the images that it produces in the html ouput.
What do other people use to produce html, Jhelp, wikis etc from Framemaker?
Someone mentioned a product from Omni systems which I will probably tryout.
I used Webworks Quadralay myself, but over 7 years ago so have no idea about the
latest product.
I'd be particularly interested in responses from people taking screenshots with lots of
details in them as our images have to be quite clear in the final html output.
Many thanks in advance for your help.
Best wishes,
Karen

Karen,
You don’t mention any version numbers and from my experience any decision depends on many parameters which are hard to discuss in a forum like this. I did not say "impossible".
I like to concentrate on your task to display screenshots with lots of detail.
You see, a pixel is a pixel. A screenshot is just a collection of pixels and some things are just one pixel wide, e.g. the stems of letters. Assuming you have a 1024 × 768 size screenshot. If you print that with a width of 7" on paper, this gives you 1024 / 7 = 146 pixels / inch, so even a simple laser printer with a resolution of 600 dpi has no problems.
But on screen it is totally different: You can achieve perfect display quality only if you display screen shots at the original resolution. A pixel is a pixel. You just can not display 1024 pixels in the space of 600 pixels without losing information.
You could try to rely on certain built-in downsampling algorithms but they differ between OSs and browsers.
My advice is:
Solve the problem by avoiding it. Is it really necessary to show screenshots in HTML? If this is only help the user is likely to see the original screen anyway.
If you have to show them, do the downsampling in a separate process, don’t rely on automatic solution and try to stick to easy fractions like 4/5, 3/4 or 2/3 to avoid moiré effects in patterns.
- Michael

Generating HTML from Structured FrameMaker 9

Hi,
My source files are in Structured FrameMaker 9. I need to generate the output in HTML format. Is there a method to do this? Can someone guide me through the process of generating an HTML output?
Regards,
Manish

Hi Manish,
You have a number of options. I'll briefly summarize a few, but all of them involve some measure of complexity so I wouldn't be able to "guide you through" any of them.
- Use a third-party product specifically designed for this, such as Omni Systems' Mif2Go, Quadralay ePublisher, or Adobe Robohelp. If you buy the Adobe TechComm Suite, Robohelp is included. All of these products can convert any FrameMaker document to HTML, with varying levels of additional functionality related to the subsequent generation of common online help formats with that HTML.
- Save your structured files to XML and then use XSLT as a post-process on that XML. This is the more complex option, but if you have the skills, it may be more attractive since you may not have to buy anything and you'll be able to easily customize the process however you want it.
- Use the DITA structure definitions within FrameMaker, then use the DITA Open Toolkit as a post-process to generate HTML from the DITA XML. There is lots of complexity with this as well, but it has some attractiveness as the DITA structured applications and open toolkit are effectively off-the-shelf software. Additionally, everything is free, unless you want to enhance your DITA experience with a third-party addon like DITA FMx from Leximation (recommended).
- Use XHTML as your structure definition within FrameMaker, then save as XML. You'll automatically have HTML when you save your files. FrameMaker includes a structure application for XHTML but I've never used it, so I don't know how well it works. With this option, you would have a more WYSIWYG conveniences while authoring but less control over variations in the HTML output.
There may be more and there certainly are any myriad of combinations of these techiniques. Hopefully this will help get you started. If you did buy the TechComm Suite, consider RoboHelp as a starting point since you already paid for it. The third-party product route is the most expensive in terms of software purchasing, but it is usually the least complex.
One additional note - You will see "Save As HTML" or similar somewhere in the FM menus. It is a very rudimentary feature that is not likely to serve your needs. Might be worth a try since it is already there, but don't get your hopes up on that one.
Good luck,
Russ

Glossary from FrameMaker not appearing in RoboHelp output

We are using FrameMaker 10 and RoboHelp 9.
We have user guides in FrameMaker that we want to publish to WebHelp from within FrameMaker. The user guides in FrameMaker all have a glossary in its own chapter at the end of the guide.
In FrameMaker, with the user guide book file open/selected, we select File > Publish.
The Publish Settings window appears.
We select WebHelp, and specify an ISF file that breaks chapters down into individual HTML files by heading level, then click Publish.
RoboHelp opens and publishes the content from the user guide to WebHelp, then RoboHelp closes.
We navigate to the folder that contains the WebHelp files, and launch it.
There is a glossary node at the bottom of the TOC in the WebHelp, but it is always empty.
Can someone please explain how to get RoboHelp to include the glossary content from the Glossary chapter in the user guide when it publishes from FrameMaker to WebHelp? We were hoping that the handoff from FM to RH was seamless, but apparently it is not.
Thank you!
Tim

Hi Tim –
I am using a different process for single-sourcing our documentation in the TCS – FrameMaker 10 and Robohelp 9. I am creating the files in FrameMaker as book files, with TOCs, Glossaries, and Indexes. I am also conditionalizing some text for online and some for print. However, my workflow, based on a lot of research and watching tutorials, is to link the FrameMaker files in a RH9 project. Then, I use Robohelp to apply the .isf file settings, a FrameMaker template to use for conversion of things like cross-reference formats, a RH master page for the online help, the customized Webhelp skin I want to use, and to do any other small tweaks as necessary since the conversion process is about 90% seamless but not perfect.
I found that when linking the files (rather than importing, which is a static process), I also get “empty” default TOCs, Glossaries, and Indexes. The solution that I found is:
1.       After generating html topics from my linked FramMaker book files, I right-click on the book file in the Project Manager pod and select Properties.
2.       On the Contents tab of the “FrameMaker Document Settings” panel, I check all 3 boxes to “convert FrameMaker” TOC, Glossary, and Index files. For the TOC, I navigate to the FrameMaker TOC file of my book.
3.       I select the radio buttons to “Create new associated” TOC, Glossary, and Index and RH insists I name them, so I name them Contents, Glossary, and Index.
4.       Then, click OK to close this window.
5.       Back to the Project Manager pod, I right-click my new TOC, Glossary, and Index files (one at a time) and select the option to set these as the Default ones.
6.       I then have the option to right-click and delete the old (empty) ones (for simplicity’s sake). Everything is then right with my help files.
Yes, this is a lot of steps. It’s the only workflow I’ve found that produces the result I want (Webhelp versions of my FrameMaker generated files that contain all entries at the correct levels, and are automated). FWIW, I couldn’t find documentation on this process anywhere. I found it through trial and error and hair-pulling :o)
HTH!
Virginia Morgan | Technical Writer
TAKE Solutions, Inc.
O 512.735.4316 | M 512.426.8323
[email protected]

Bookmarks in webhelp generated from Framemaker

Hi all
We're using the trial version of Framemaker 12 as part of the TCS5 suite.
I've been experimenting with the Publish pod to create WebHelp and am wondering how to specify which Framemaker headings appear in the Webhelp TOC?
I thought it might use settings in the Bookmarks tab in PDF setup - but have tried this to no effect.
Certain headings do appear in the TOC, but not a new ChapterTitleHelp style I've created. How do I get this to appear?
I've looked in the Style Mapping tab in the Publish Settings dialog (when you right-click Webhelp and select Edit Settings). However, this seems to be more to do with the look and feel and character format than determining which headings appear.
Can anyone help please? We do have Robohelp as part of the suite, but to the best of my knowlege you should be able to output directly from Framemaker without opening RH. Is there a file somewhere where you can specify which headings you want?
Many thanks
Laura

Of course, once I post, I work it out.
It seems that the styles have to appear in the Framemaker TOC. I had not done this because I was still in the hard copy mindset and would never add the ChapterTitleHelp to the hard copy TOC.
Hope this helps someone else anyway.
Laura

How do I generate HTML from XML & XSL using XSL Processor ?

I want to generate a HTML from XML & XSL using XDK for C on
linux-8i.
I run the XSLSample well.
But it only generate a XML from a XML & a XSL.
Can any one give me some advise or sample code?

Just use HTML tags instead of xml tags in your stylesheet, and
you'll generate HTML instead.
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
    <html>
      <body>
        <xsl:for-each select="ROWSET">
          <table border="1" cellspacing="0">
            <xsl:for-each select="ROW">
              <tr>
                <td><xsl:value-of select="EMPNO"/></td>
                <td><xsl:value-of select="ENAME"/></td>
              </tr>
            </xsl:for-each>
          </table>
        </xsl:for-each>
      </body>
    </html>
</xsl:template>
</xsl:stylesheet>

Best methods for creating e-books from FrameMaker 10 (TCS 3.5)

I would like to know your thoughts on which of the following methods is the best, and easiest, way to create e-books from FrameMaker. I will most likely be using Calibre to do the file conversion.
(1) Using File > Publish > ePub to create an ePub file, which can then be imported into Calibre.
(2) Using the File > Save Book As > HTM command (which creates a separate HTML file for each FM file), editing the HTML files in RoboHelp (or another HTML editing tool), then importing all of the HTML files into Calibre.
Note that when I published to HTML from FM, it appears that only an output file was created from RoboHelp, as I could not find any HTML files were actually created. Is that the case, or was I just not looking for the HTML files in the right place?
If anyone has any other recommendations, please let me know! Thanks!

I linked the FrameMaker book to RoboHelp, then generated an ePub file from RoboHelp, and have a couple of issues.
(1) When I open the ePub file in Calibre and Adobe Digital Editions, there is no contents section within the book. The only contents is the contents in the navigation bar. How do I generate a contents to appear in the front of the ebook, or do I have to create that manually in RH? I did specify the settings in RH to convert the FM contents.
(2) The ePub file looks much better in Calibre than Adobe Digital Editions. Should I be concerned about this? Which viewer should I rely on?

Is there a way to prevent Robohelp WebHelp from appending characters to the end of the URL address for a TOC Entry?

I am running RoboHelp 10 on Windows 7 Enterprise SP1 64 bit OS.
WebHelp is appending characters to the end of the TOC entry's URL address. The characters "bc-n" where n is a number are being generated for all of the TOC Page Entries when I generate WebHelp output. We are exporting the HTML files for import into an application. The TOC Page Properties Link to: property does not contain the characters in RoboHelp.
We have standardized names defined for our application and the appended characters are not going to work in the application.
cid:[email protected]
When I use the generated html output in IE10 Version 10.0.9200.16635 Update Versions: 10.0.7 (KB2846071) the characters show up in the URL when I hover the mouse over the TOC entry as shown in the screenshot below.
cid:[email protected]
The two screenshots show that the Link to property does not have the characters "bc-7" but the URL address does.
Is there a setting or way to configure RoboHelp to prevent Robohelp WebHelp from generating and appending characters to the end of the URL address for TOC Entries?

I have never known Rh add any characters so I think something else is at play here. Please open one of the sample projects and see what happens there. Click Open on the RoboHelp Starter page and then click Samples in the ribbon on the left.
See www.grainge.org for RoboHelp and Authoring tips
@petergrainge

Robohelp vs. FrameMaker

Hello,
I have a few large scale RoboHelp 6 projects. I am debating whether to upgrade to RoboHelp 9 or to convert my projects to FrameMaker (to which I have an existing license). My projects' main purpose is an online tutorial (HTML), but I will also need chms and pdfs. My questions are:
1) Is there a reason to prefer RoboHelp 9 over FrameMaker in my case?
2) How difficult will migration be from RoboHelp 6 to FrameMaker? Or to RoboHelp 9?
Thanks in advance

Most people are doing the TCS integration of FM to RH because FM can create better looking PDFs than RH (especially if your docs are long). However, many people do all their authoring in RH and then use the Printed Documentation SSL to get their PDFs via Word. Upgrading a project from RH6 to RH9 will probably go smoothly, but make sure you have a backup before you begin. You may experience difficulties with numbered/ordered lists and the change to XHTML in RH8+. There is no clear path from RH to FM. You will have to cut & paste or export to Word & re-import into FM to get content over.

Loosing document from FrameMaker book

When I import/link a FM book, one document does not get generated as topic. RoboHelp does display the chapter icon under the link in the Project manager, and also indicates the status (green, yellow needs update..) but no topic is present there.
Is there any specific content that prevents the importing/linking process?

RoboHelp does not generate a topic for a particular FM file if the topic to be generated does not have any content. In other words, blank topics are not generated by RoboHelp during conversion from FrameMaker. Please make sure that the chapter has some content to be converted to RoboHelp topic.

RH9 - window caption not correct in generated html-output

I installed RH9 and opened an existing project coming from RHX5 in the new RH9.
When generating HTML Help, the window caption of the output displays "HTML Help" instead of the name I gave to the default window (in my case: "Rimses 5.6 Help").
In RHX this was related to the default language in the Robohelp-project (Dutch in my case) versus the Regional settings of the PC.We had a workaround by adding in the HHP-file / Section "Options" the text "Language=0x409 English (United States)".
Now, in RH9, this workaround is not working anymore.
I tried several things:
- removing he workaround in the HHP-file
- changing the regional settings of my PC
- checking the project settings, html settings, default window etc.
Anyone an idea how to solve this in RH9?
thanks,
Natacha

Hi Natacha and welcome to the RH forums. Have you tried creating a new window? I wonder whether the old settings are causing RH9 to throw a wobbly and by starting afresh it may give it a shove where it is required.
The RoboColum(n)
@robocolumn
Colum McAndrew

Error while generating HTML

Hi,
I have a design studio application I want to share publicly on BI Launch Pad for my company. The dashboard/application made in design studio works fine locally and on BI Platform public folder (through my login credentials).
However, when other people from the company try to view this DS application, it throws "Error while generating HTML"
The root cause is:
The initial exception which caused the request to fail was:
Index: 0, Size: 0
Any clue why such a thing might be happening?

What version of BI4x/patch?
Looks like this error has been shown before on older versions of the BI Platform - see Error HTML in Mobile BI App, not in local (version 1.4)

FAQ: Creating PDF Files from FrameMaker v.6 & earlier Documents -- Why you should not use "save as PDF"! -- Windows & MacOS Only!

An issue that has come up over and over again on several FrameMaker and Acrobat/PDF email lists as well on the corresponding Adobe User-to-User forums is that of creation of PDF files. FrameMaker 5.5.6 and 6 have what looks like a convenient feature that is supposed to allow you to create PDF files via simply saving the document as a PDF file. I have gone on record as advising end-users not to use this approach for reliable creation of PDF files from FrameMaker documents under Windows and MacOS with FrameMaker 6 and earlier. Why do I most vociferously offer this advice and why doesn't the problem get fixed? And how SHOULD you create PDF files from FrameMaker?
GOOD NEWS
I will start with the good news. The "next major version" of FrameMaker will indeed have "save as PDF" re-implemented in a manner that it will be as reliable as printing to the "Acrobat Distiller" printer instance under Windows or the "Create Adobe PDF" desktop printer under MacOS. I am personally working with the FrameMaker development organization to make sure this really happens and is fully and properly tested and debugged! Furthermore, this next major revision of FrameMaker, unlike FrameMaker 6, will come with a Distiller installer that will properly install the "Acrobat Distiller" printer instance under Windows and the "Create Adobe PDF" desktop printer on the Macintosh (of course assuring that the latest PostScript driver is also automatically and correctly installed).
DON'T USE "SAVE AS PDF"
But what's wrong with "save as PDF" as currently implemented?
The following are some of the SYMPTOMS reported over the last few years by FrameMaker users that were traced back to use of "save as PDF" under FrameMaker:
(1) No PDF file is produced at all, possibly with a log file showing not-readily apparent PostScript errors during distillation.
(2) The PDF file "loses" color in images. All or some images (raster, bitmap images, NOT vector artwork) appear in the PDF file in grayscale.
(3) The resultant PDF file is on the wrong paper size, i.e., the document's logical page size does not match the output page size as seen in Acrobat or Acrobat Reader.
(4) Some or all text in the resultant PDF file is blotchy looking or overly bold.
(5) Some or all text in the resultant PDF file cannot be searched or indexed.
(6) Some or all text in the resultant PDF file appears in Courier or in some other substitution font.
(7) Interword or intercharacter spacing is a bit irregular in the resultant PDF file.
(8) Content is missing in the margin areas of the page, i.e. you cannot do full-page bleeds.
(9) Some or all page content is missing (other than margin areas).
(10) Relatively inefficient PDF is generated.
If this list by itself isn't enough for you, please note that some of these symptoms are very subtle and may escape attention when the PDF is first viewed or printed. Oftimes, it is when one attempts to manipulate the PDF file in Acrobat or repurpose its content or even view or print on a system other than the one on which the PDF file was created, that some of these symptoms make themselves obnoxiously visible (or invisible in some cases I won't make any bad jokes here about graphic examples!).
It is important to understand that FrameMaker does NOT have its own native ability to create PDF. Any and all PDF created from FrameMaker documents is actually done by creating PostScript via the PostScript driver and having the Acrobat Distiller create PDF from that PostScript. The only exception to this is creation of PDF via the Acrobat PDFWriter driver, which is likewise not recommended (see below).
In order for "save as PDF" to work correctly, FrameMaker must do the equivalent of calling Printer Setup and selecting the "Acrobat Distiller" printer instance under Windows or the "Create Adobe PDF" desktop printer under MacOS followed by setting the driver's options correctly for paper size, page range, etc., followed by sending the proper commands to the driver to create PostScript.
Contrary to popular belief, PostScript as generated by the Windows and MacOS PostScript drivers is VERY device-dependent. The information in the PPD file associated with a printer driver instance provides critical parameters for generation of PostScript including:
Whether the printer supports color (Acrobat Distiller does)
What PostScript language level is supported (Acrobat Distiller 4.x and Acrobat Distiller 5.x are both PostScript language level 3)
Whether native TrueType support is available (Acrobat supports native TrueType as Type 42 fonts)
Available binary communications (Acrobat Distiller supports pure binary and ASCII, but NOT TCP, TBCP, or PJL)
Resident fonts (Acrobat Distiller doesn't really have resident fonts)
Available paper sizes and custom paper size availability (Acrobat Distiller supports a wide range of predefined sizes and continually variable "custom" sizes up to 200" by 200")
Margins / printable areas (for PDF and the Acrobat Distiller, there are no margins in which imaging is not permitted)
Device resolution (Acrobat Distiller can be set to any value from 72 to 4000 dpi; as a convenience, the Acrobat Distiller PPD provides a series of values for use by the driver. Since there is no inherent "resolution" of a PDF file, this parameter is used only for purposes of allowing PostScript programs that query for such a value to be satisfied and for the driver to be able to communicate this value to the operating system and/or application as required.)
Paper handling (totally irrelevant to Acrobat Distiller if input or output tray selection via "setpagedevice" is found in the PostScript stream, it is ignored by Acrobat Distiller)
Thus, if the wrong printer driver instance is selected (i.e., it isn't associated with the Acrobat Distiller PPD file) or that driver instance is improperly configured, improper PostScript will result and one or more of the symptoms described above can occur. As currently implemented, FrameMaker depending upon version will not necessarily choose the correct printer driver instance and/or correctly parameterize the print job via driver setup options. In fact, FrameMaker 5,5,6 might even try to generate PDF via calling a PCL driver, FAX driver, or even a non-PostScript inkjet printer!
DON'T USE PDFWRITER
The Acrobat PDFWriter is a relic of older versions of Acrobat. In fact, it is no longer installed by default in the "easy install" or the "typical install" of Acrobat 5. It hasn't really be updated since Acrobat 3 and only supports PDF 1.2. It is a GDI (Windows) / QuickDraw (MacOS) driver that directly generates PDF without any intermediary PostScript. Since it is not a PostScript printer driver, applications cannot pass through EPS graphics and/or PDFMark information (used for a wide variety of purposes by FrameMaker). For EPS graphics, most applications will send the low resolution TIFF (or PICT) EPS header in lieu of the PostScript text, if they send anything at all, to the driver. Forget about links, structure, or any other PDF "goodies." Expect that PDFWriter will fully "bite the dust" in the next major version of Acrobat.
SO HOW DO I GENERATE PDF FILES FROM FRAMEMAKER 6 & EARLIER?
The ONLY method that is really reliable for producing PDF files with FrameMaker 6 and earlier requires the generation of PostScript via a properly set printer driver instance associated with the Acrobat Distiller PPD and distillation of the resultant PostScript by Acrobat Distiller.
Case 1: FrameMaker and the Full Acrobat 4.05 or Acrobat 5.0x Products
PDF file from a "chapter" -- print directly to the Acrobat Distiller printer instance (Windows) or the Create Adobe PDF desktop printer (MacOS) already installed by Acrobat. If you check the "Acrobat data" option, then make sure to UNcheck the "print to file" option that gets set at the same time. As a result, the driver will automatically send the generated PostScript to the Distiller for you and delete the intermediate PostScript when done.
PDF file from a "book" -- print directly to the Acrobat Distiller printer instance with the "print to file" option checked (Windows) or the Virtual Printer desktop printer (MacOS) associated with the Distiller PPD (see details below under Case 2/MacOS). You will need to manually process the resultant PostScript file through the Distiller (or use a "watched folder" arrangement).
In both the above sub-cases, the default driver options generally will be OK, but check on paper size and communication protocol (Use pure binary, not ASCII, for optimal performance AND no CTRL-D characters under Windows. Make sure to set Level 3 only and Binary under MacOS. Font inclusion "All" for Acrobat 4.05 and "None" for Acrobat 5 under MacOS.). With Acrobat 4.05, make sure you preset the Distiller to use the joboptions you want. With Acrobat 5, you can set this on a job-by-job basis via the driver printer setup interface (or print dialog on MacOS).
Case 2: FrameMaker 6 and the Bundled Acrobat 4.05 Distiller
Windows -- Create a new printer driver instance using the latest version of the Adobe Universal PostScript Driver Installer, downloadable from Adobe's web site AND the Acrobat Distiller PPD file (located in the XTRAS subdirectory of the Distiller directory). This driver instance should be set to print to the local port named "FILE:". Name this driver instance as "Acrobat Distiller". The default driver options generally will be OK, but check on paper size and communication protocol (use pure binary, not ASCII, for optimal performance AND no CTRL-D characters). Make sure you preset the Distiller to use the joboptions you want. Print directly to this Acrobat Distiller printer instance. Make sure that the "print to file" option is checked. You will need to manually process the resultant PostScript file through the Distiller (or use a "watched folder" arrangement).
MacOS -- Install the latest version of AdobePS 8.7.x, downloadable from Adobe's web site. In FrameMaker, go to Page Setup and select the "Virtual Printer" and go to the "Virtual Printer" window pane. Select the Acrobat Distiller PPD file (located in the XTRAS subfolder of the Distiller folder). Print directly to the "Virtual Printer" (Make sure to set Level 3 only, Binary, and font inclusion "All".). Make sure you preset the Distiller to use the joboptions you want. You will need to manually process the resultant PostScript file through the Distiller (or use a "watched folder" arrangement).
Case 3: Acrobat 3
Acrobat 3 is not officially supported for the latest OS versions and I personally would no longer recommend its use for generation of PDF files given that Acrobat 5.0.5 is the current version of Acrobat.
- Dov

You're asking a lot of ancient Acrobat to work with an Office that never existed when it was made. "Just updated my office suite" is a massive change, and Window 8 didn't exist at that time either...

Generating HTML in RoboHelp 10 from FrameMaker 11

Similar Messages

Maybe you are looking for