FrameMaker Paragraph tags not consistently mapping in RoboHelp

Hello, I have a FrameMaker book, which i have linked to a RoboHelp project. I successfully mapped all the paragraph tags from FM to RH. However, when i compile my help some of my headings do not appear correctly. For example, my Heading 1s have a different appearance from topic to topic. I looked at my FM source files and there are no paragraph or character overrides on any of the affected headings. When I open the topic in RH, i can see that the paragraph symbol at the end of the heading is the correct size, but the text itself is smaller than it should be. I discovered a way to fix this, but it is VERY time consuming. (i.e. In FM, highlight each heading, reapply the paragraph tag, apply the default font character tag) This fix is not a viable option since i have thousands of topics. Any suggestions?

Apparently RH also ignores FM styles that only appear in
tables. Weird. If I add text using the parapgraph styles into the
body of the FM file, the styles are imported by RH (I had to add
text to the pgf for RH to see it). But if the style is not used in
FM anywhere but a table, RH ignores it.
Another show-stopper: Rows in tables are ignored by RH if
multiple conditional tags are applied to the row. For example, a
row is conditionalized with "A' & 'B' and you import the FM
file applying the 'B' condition, the row will not show up in the
table. If the row is only tagged 'B', it will show up. Other
straddled rows that are tagged with a condtion other than the one
used to import into RH will cause misaligned columns in the
table.

Similar Messages

Paragraph tags not applied correctly

Hi,
I’m importing an FM document into RH (Technical
Communication Suite). I fixed all the paragraph definitions and the
mappings.
After importing, the same paragraph tags are sometimes
applied correctly and sometimes not. Most problematic are the ones
that come right after a paragraph that has a bullet or number
setting. It seems as though the following paragraph sometimes has a
bullet or number even though you can’t see it.
If I reapply the paragraph tag it doesn’t help, but if
I apply a different one and then the original one I wanted –
it works OK.
Is there a workaround? Am I doing something wrong?
Thanks,
Rakefet

Have you updated lately? I applied RoboHelp patch 7.0.2 and
it fixed may random isses that I was having. Also I would recommend
mapping all numbered and bulleted lists to Normal to have them
appear correctly. Also don't forget to check Convert AutoNumber to
HTML list on the Style Setting window.
Amanda

Paragraph tag not included in catalog.

fm11 in win7.
In the document I'm working on, some lines appear to be in a paragraph tag named "RegName". But this "RegName" can not be found in the catalog, ie if I click on the arrow to select the paragrah tag, "Regname" is not included.
Thanks for your help.
Stephane.

> But I'm just wondering how this Paragraph tag could be referenced in the document while it was not in the catalog?
Paragraphs with new tags are not automatically added to the Catalog. It's an option when creating one. When pasting in text from another FM document, new tags are not automatically cataloged. For a tag one already in the catalog, doing a Delete Format on it only removes it from the cat. Text containing it is still present and still tagged with the deleted format.
There actually is a command (dialog sequence) that causes every format in use to get added to the cat (and the details of which I don't recall at the moment). Instances of existing catalog formats with overrides get cat entries with new names. Massive catalog pollution results, but it's great if the intent is to clean up overrides and weed out (or adopt) rogues.

Some paragraph tags are not printing when document is printed from Framemaker 10.

So this is really odd. I have a situation where I have a document that I am developing in Framemaker 10 several different paragraph tags are intermittently not printing when the document is physically printed. When I go to print the document from Framemaker 10 to a physical piece of paper some tags are printing partially or not at all. What makes this stranger to me is that when I print the document to a PDF, all of the content and tags show up in the PDF. Then when I try to physically print from the PDF, the tags do no print from that document as well.
Typically the tags that are not printing are those that have been bolded, but are across several different tags. Also the problem is sometimes only to the first line of a tag, where if the tag carries over to a second line in the document, the text on the second line prints. Another quirky instance that shows up is where the text a line will print only parts of the text. The document uses the same type font for the entire document, Helvetica 55 Roman. The font size varies and the coloring varies as well, but this issue is happening for all sizes and colors.
I'm not sure what additional information is important here, but if you need additional information please request it and I will supply it to the best of my ability. I'm a content developer with an intermediate amount of experience with Framemaker.

I'm not sure if this is the same problem, and you didn't mention your
OS, but there was a widespread problem with dropped text in PDF with
Windows XP. A hotfix was issued to fix it. If on Windows XP, you should
install it:
http://blogs.adobe.com/techcomm/2008/07/hotfix_for_framemaker_1.html
Also, you mentioned that it was "bolded" text that tended to have the
problem. Bolded text is artificially bold and does not use actual bold
fonts. (If I recall, text is double printed at a slight offset to give
the appearance of a bold font.) So there is no bold font to embed. Be
sure you install and use an actual bold font, rather than using the
bolded characteristic, or you could see problems.
This is a stretch, but you also mentioned that some of the problem
sections have colored text. Check the printer properties of your Adobe
PDF virtual printer to make sure someone didn't reassign the driver (on
the Advanced tab). It should be set to use the Adobe PDF Converter
driver (or Acrobat Distiller in older Acrobat versions). Years ago,
people sometimes changed this setting to use other drivers for various
reasons, not realizing that they limited themselves to the capabilities
of that driver. So, if they chose an HP LaserJet PostScript driver, for
example, their documents might no longer be able to be 11"x17" or
color-- because the printer couldn't handle it. The driver was limited
to 8.5"x14" and black-and-white. Perhaps there is a driver set that is
choking on the colored text-- though I would think it would merely
convert it to B&W.
Okay, I've grasped at enough straws.

Convert FrameMaker paragraph formats to RoboHelp styles

This question was posted in response to the following article: http://help.adobe.com/en_US/robohelp/robohtml/WS12199CA1-968E-4a9b-9927-ED490DF6B87E.html

Thank you Jeff for a specific reply.
First, let me respond to, "Nobody else seems to be having any issue with this."
In the TechComm Central blog post, "Troubleshooting FrameMaker Content Conversion in RoboHelp Part 1," Mayank Agrawal, the author, says, "Many times, I hear from users that it appears as if Robohelp is not applying FrameMaker conversion settings or eating up the imported .isf settings." So, what we are seeing is not unique to us. However, we follow Mayank's steps, and the FrameMaker paragraph styles are still getting lost somewhere.
Second, we have the standard FrameMaker paragraph styles. For example, this is the content we see in WebHelp that has been published from RoboHelp, along with the FrameMaker paragraph style enclosed in square brackets. (Nothing is indented in WebHelp, but everyone looks fine in FrameMaker.)
1. This is the first step. [FM: List Number 1]
This is an indent that is not indented. [FM: Indent]
2. This is the second step. [FM: List Number +]
o This is a bullet that is supposed to be indented a bit. [FM: Bullet 1]
o This is another bullet that is supposed to be indented. [FM: Bullet 1]
3. This is the third step. [FM: List Number +]
a) This is an alpha list that is supposed to be indented. [FM: List Alpha 1]
b) This is another alpha list that is supposed to be indented. [FM: List Alpha +]
o This is supposed to be a bullet 2 indented even more. [FM: Bullet 2]
o This is another bullet 2 that is supposed to be indented,
and the text wrap for all styles in this example comes to the left margin. [FM: Bullet 2]
This is supposed to be a 3rd level indent. [FM: Indent 3]
Again, everything looks great in FrameMaker. However, FrameMaker does not appear to be automatically handing off ANY paragraph style formatting information to RoboHelp. And when we attempt to manually set the styles in the ISF file, the WebHelp generated from RoboHelp does not appear to retain the manually-set formats.

HTMLDataSet paragraph tag in header not allowed?

Anything I am doing wrong?
Spry’s HTMLDataSet (SpryHTMLDataSet.js - version 0.25 - Spry Pre-Release 1.6.1) doesn't seem to give the data in any column in which the header is enclosed within a paragraph tag.
Snippets demonstrating this are below. The first column of data does not display. Take out the <p></p> from the 1st column and all works as expected.
Strangely, the data may be enclosed without effect.
As a new user of CS5 and DW, I encountered this while going through the CS5 CW Classroom in a Book sample in chapter 14. Had to spend of bit of time narrowing down the source of the original problem, which was that only the headers display in Live View or IE. My apologies if this something most people already know.
<script src="SpryAssets/SpryData.js" type="text/javascript"></script>
<script src="SpryAssets/SpryHTMLDataSet.js" type="text/javascript"></script>
<script type="text/javascript">
var ds1 = new Spry.Data.HTMLDataSet("MySimpTbl.html", "SimpTbl");
</script>
</head>
<body>
<h1> My Temp Page Test </h1>
<div spry:region="ds1">
<table>
    <tr>
      <th spry:sort="HC1">HC1</th>
      <th spry:sort="HC2">HC2</th>
      <th spry:sort="HC3">HC3</th>
      <th spry:sort="HC4">HC4</th>
    </tr>
    <tr spry:repeat="ds1">
      <td>{HC1}</td>
      <td>{HC2}</td>
      <td>{HC3}</td>
      <td>{HC4}</td>
    </tr>
</table>
</div>
<p> end of page </p>
</body>
Within MySimplTbl.html:
<body>
<table id="SimpTbl">
<caption>
    Simple Table
</caption>
<tr>
              <th><p>HC1</p></th>
    <th>HC2</th>
    <th>HC3</th>
    <th>HC4</th>
<tr>
    <td>r1c1</td>
    <td>r1c2</td>
    <td>r1c3</td>
    <td>r1c4</td>
</tr>
<tr>
    <td>r2c1</td>
    <td>r2c2</td>
    <td>r2c3</td>
    <td>r2c4</td>
</tr>
<tr>
    <td>r3c1</td>
    <td>r3c2</td>
    <td>r3c3</td>
    <td>r3c4</td>
</tr>
</table>
</body>

Thanks for your reply.
Re:
In the same way I am confused why you should want to use a p-element for a heading.
Excellent question. I'm all for the - if it hurts, don't do it without good reason - philosophy. The authors of the book I am using to learn Dreamweaver, "Adobe Dreamweaver CS5 Classroom in a Book", had the p-elements in their lesson 14 file for learning HTMLDataSet use. I couldn't tell you why they chose to have p-elements in the headers. The rest of the book, which has versions for CS3 and CS4, has been without significant flaw. So as a newbie, I assumed I might have the incorrect .js or done something wrong.
Lacking vision of a positive return on effort required to pursure this further, I'll mark this question as answered and benignly assume that an undocumented and unsupported feature of supporting p-elements in the headers of previous versions of the HTMLDataSet has been removed.

Why does my paragraph tag for images get repositioned AFTER the image?

I have TCS2 and link my FM docs to RH.
I use a paragraph tag in FM called "figure" for my imported images. I noticed there is too much space after the images in RH and discovered the "figure" tag is BELOW the images. So even if I map the tag to a RH style, it won't do any good. Any suggestions?

This might fix your problem. Look at how your anchored frame appears in the FrameMaker document. It's probably like this:
┴ ¶
Which is simply the anchored frame marker followed by the paragraph marker.
Now try this. Before the anchored frame marker, add a forced space (CTRL-Space).
|_| ┴ ¶
When RoboHelp interprets this, it appears to place the paragraph before the anchored frame, not after it.
This is assuming you've got the anchoring position set to"Below Current Line," as suggested earlier.
Hope this helps!
Jason

How to create FrameMaker glossary entries which convert properly to RoboHelp HTML 8?

I have been having a challenging time creating FrameMaker 9 glossary
entries which convert properly into RoboHelp HTML 8. Here is the process I'm doing, and perhaps someone call tell me what I'm doing wrong.
1.) In the FrameMaker document, I highlight a word or phrase which serves as the "glossary term" to be defined.
2.) I open the Marker dialog box, select the Glossary option, then enter the "glossary definition" for the highlighted "glossary term." I commit the entry.
3.) In the FrameMaker Book file, I create a new "Index of Markers" (IOM) of "Glossary" type. Upon generation of the IOM, my FrameMaker output is much like a standard index: There are letter delimiters ("A," "B," C," etc.), and under each is the "glossary definition," then a page number where the "glossary term" is.
4.) Now I go to RoboHelp HTML 8 and update the document there. The glossary displays such that the "glossary term" is the entire paragraph in which the marker had been placed in the FrameMaker source file. The "glossary definition" is displayed properly (the text I placed into the Marker dialog box.
So, how am I to create auto-generating glossaries? This implies that I need to create a manual glossary whereby the "glossary term" is in a paragraph by itself (much like a printed glossary would look). Furthermore, I would need to add this manual glossary as a file in the FrameMaker Book file for RoboHelp 8 to detect and pull the entries.
Surely this isn't as how it was designed. I suspect I'm doing something wrong in how I create glossary entries or create the file in the FrameMaker Book file.
Could someone offer some assistance?
Thank you very much in advance!
Most sincerely,
Sammy Spencer

It's because you're doing your markers backwards. The text inside your Glossary marker should be the term. The paragraph your marker is inside is the definition.
I should say, rather, that Robohelp does it backwards, because when I think of glossary terms and definitions, I think there should be a way to highlight a word and provide the definition in the hidden marker, not hide the term inside the marker.
I am still figuring out how to make a glossary in my Framemaker file that will work with my Robohelp file, and not have Robohelp generate a separate content file for the glossary file. I think I'll get it, though. Eventually.

Extra and unwanted paragraph tag after text inset

Using Framemaker 7.2 -- we maintain a number of manuals which reference a group of common sections, each of which is a separate .fm file.
The ratio is one-to-many: for example, there is an .fm file called "Bob" which contains information common to multiple manuals. The contents of "Bob" is then imported by reference into other .fm files which reside with the rest of each manual.
By way of description, the entirety of the in the target document is selected when clicked anywhere; double-clicking causes the Text Inset Properties dialog to appear. "Updating of Imported Flow" is set to Automatic.
The problem is that each time "Bob" is updated and the changes are populated out to the dependent sections of the manuals, an empty paragraph is inserted at the end of the imported text. By default, this empty paragraph receives a tag which causes it to show up in the TOC of the manual in question.
This behaviour is annoying until the erroneous TOC sneaks through the editing process -- my fault! -- at which point it becomes embarrassing. Is there a way to prevent this behaviour from happening in the first place?

> We would like to insert the text inset between two topic titles.
> When we do this, an empty paragraph tag appears under the text inset.
Well, not really. A text inset has to be anchored to a paragraph.
This is the paragraph in which the cursor is placed when you
import the inset. If you anchor it to an empty paragraph, then
that paragraph will still be there, empty except for the inset anchor.
(There is no "anchor" symbol associated with an inset)
> When we delete the paragraph tag, it seems that the last topic
> title becomes a part of the text inset.
No, it doesn't. The topic title is placed in the same paragraph as
the inset anchor, that's all.
> When you update the FM book, go to the TOC and click on the link
> of this last topic title, the whole title and text inset is selected,
> not only the title as it used to be.
And why is this a concern? The inset should work as expected.
The reason is that if you follow a TOC link, the whole paragraph
becomes selected, including the inset anchor and the inset.
If this bothers you for some reason, you need to anchor the inset
in a VERY small paragraph between the two topic titles, say 2-pt
font size with zero space above/below.
/Thomas Michanek

Missing closing paragraph tags

Well this is a conundrum. The closing paragraph tag (i.e.
</p>) which is considered optional and which Dreamweaver does
not automatically insert at the end of a paragraph makes a
difference to Internet Explorer (at least version 7.0 which I
previewed the page in). Without the closing tag, IE does not add
space btw paragraphs. I created many web pages recently and
previewed everything in Firefox. I wasn't sure what the client was
talking about when they complained that I was removing spaces btw
paragraphs. I had to go back by hand and insert the missing tags.
Has anyone else run into this problem? Why would a tag that
is so essential be considered optional? Any way just make sure that
you close your paragraphs!
Tom

> Here is the doctype code from one of the problem
documents
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN"
> "
http://www.w3.org/TR/html4/loose.dtd">
>
> (Is there a recommendation for which doctype to use?)
You should choose a doctype that's consistent with your
coding ability.
This one is fine unless you are an advanced coder.
> This seems like a loophole that Dreamweaver should try
to fix. I only say
> this
> after having spent several hours having to fix this.
Normally it wouldn't
> bother me.
I have confirmed your finding. I'll submit it. Wouldn't hurt
if you did
too!
http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
Murray --- ICQ 71997575
Adobe Community Expert
(If you *MUST* email me, don't LAUGH when you do so!)
==================
http://www.projectseven.com/go
- DW FAQs, Tutorials & Resources
http://www.dwfaq.com - DW FAQs,
Tutorials & Resources
==================
"TSemmes" <[email protected]> wrote in
message
news:gqr5lv$5s6$[email protected]..
> Here is the doctype code from one of the problem
documents
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN"
> "
http://www.w3.org/TR/html4/loose.dtd">
>
> (Is there a recommendation for which doctype to use?)
>
> Actually I did a test with Dreamweaver to see if it
would automatically
> add
> the closing tag.
> This is what I found.
> If the text that is being editing does not have a
paragraph closing tag,
> when
> that text is broken into paragraphs, each paragraph does
not have a
> closing
> tag. It seems that Dreamweaver picks up its decision to
include a closing
> tag
> or not, by the paragraph that is already there.
>
> This seems like a loophole that Dreamweaver should try
to fix. I only say
> this
> after having spent several hours having to fix this.
Normally it wouldn't
> bother me.
>
> Tom
>

Upgrade problem w/Wingding symbols in paragraph tags

We just were upgraded from 7.2 to 8. One manual created under 7.2 has a paragraph tag formated with a wingding symbols of a large black circle. In 7.2, this symbols was copied in from the character map in Windows XP.
In 8, the large black circle symbol translates as a hand. We tried other circle symbols and none work as circle symbols - they appear as other symbols in the character map. The original circle symbols was part of the Character map WingDing 2, but I've tried it using Wingdings, WingDing 2, and Webdings.
Has anyone else had this problem - Is it a known bug with a patch available? Does anyone have a fix?
Upgrading to Windows 7 or Frame 9 or 10 is not an option.

The difference you're seeing is almost certainly because of the change in FM8 to use Unicode font encoding. I seem to recall that a few popular Wingding characters are actually are actually "unavailable" in FM after the switch, and folks have had to either change the symbol they use, or change to a different Wingding version (usually a purchased one) in order to get the desired character.
First, though, be absolutely certain that you're using the latest update available for FM8, as shown in Help > About, and listed here:
http://www.adobe.com/support/downloads/product.jsp?product=22&platform=Windows
as I believe there were some character location changes in the patches.
Also, using the tool to search FM forums on the upper right of the main FM page,
you should find quite a lot of info about the character change searching for "Unicode"

Make new paragraph tag available in all documents in a book

I'm very new to FM10, so please excuse my ignorance.
All I want to do is make a custom paragraph available in all the chapters
of my book. I created a variation of Heading2 (and gave it the paragraph tag
of H2), in one chapter and use it extensively there.
I checked the "add to catalog" box when I created it, but when I'm working on
the other documents (chapters) in the book, H2 doesn't show up in the
paragraph catalog .
After failing to make "import format" work, I even tried to re-create the same H2
paragraph from scratch in one of the the other chapters.
But to add insult to injury, after typing in all the custom H2 characteristics in that
other chapter, and attempting to put in the catalog (which was not showing
an H2 in that chapter), FM told me that it couldn't do it because there was already
a paragraph tag of that name in the catalog.
At that point I decided to throw myself on the mercy of the forum.
Cheers,
JP

JP,
Open the file in which you created the H2 tag. In the book file, select all. Then with the book file selected, select File > Import > Formats. In the dialog, deselect all and then select paragraph formats. From the dropdown at the top, select the open file. Click OK, or whatever. This copies all the paragraph formats from the open file into all the selected files of the book. IF an H2 tag already exists in any of the files in the book, it is overwritten. No tags NOT in the open file are deleted.
After failing to make "import format" work, I even tried to re-create the same H2
paragraph from scratch in one of the the other chapters.
But to add insult to injury, after typing in all the custom H2 characteristics in that
other chapter, and attempting to put in the catalog (which was not showing
an H2 in that chapter), FM told me that it couldn't do it because there was already
a paragraph tag of that name in the catalog.
The second paragraph implies that the import format DID work. What do you mean by failing to make import format work?
Van

Table headings (tagged in paragraph tags) to be merged as a single entry in the TOC

Hello,
I am working on a previous file done by somebody else. And here, I have the TOC as shown in screen shot below (which looks quiet normal).
- The body page headings are placed in tables as shown in screen shot below.
But, the entries when they appear in the TOC, they appear as one (IP31/42 T40) heading.
How do we tag table headings (in different paragraph tags) and merge them as a single entry in the TOC.
Also, suprising to note the paragraph tags are different in the TOC and different in the body (for the same headings).
Below are the different paragraph tags that show up for the headings in the Table of contents:
Below are the different paragraph tags that show up for the headings in the Table of contents:
How do we tag table headings (in different paragraph tags) and merge them as a single entry in the TOC.
Help much needed!!
Please advice....
Regards,

You cannot have two paragraph styles in one paragraph, but you could use different styles in each cell of your table and include them all in the TOC.
As far as using a different paragraph style for the lisitng in the TOC and the actual text that is picked up, that's very common. It allows you to find many different paragraph styles to include, but have the listings all look the same, and completley different from how the text looks in the body of the book. You'd problay not want 24 pt Bold TOC lisitngs, but that might be appropraite for section headings that you want to pick up.

Paragraphs do not align to grid

Hello there:-)
I created a baseline grid of 6pt, body text 12pt, head lead 12pt, space before and space after 12pt and 6pt. In one chapter, everything aligns, in the second one the paragraphs do not align. I'm going back and forth the paragraph style to change the space before and after of the head, but everything is still the same. What am I doing wrong?
Any help is appreciated.

saranas wrote:
I think you're right. Could you please give an example of how to do this "Unless the total of the leading, space before, and space after total an increment of 12 you'll be off grid."? I just need to see some numbers to see whether I can correct this.
Many thanks.
Well, in all honesty there's no way to do this so that you always have grid alignement and consistent spacing between the headings and and the body text unless they all use a leading value that's a multiple of 12 and all space before/space after is also a multiple of 12 (or whatever number you've chosen for the leading or the body text). As soon as you introduce an odd number you're going to wind up with a larger space below a heading (usually at the top of the page), or a misalignment.
On the other hand, if youy keep everything in multiples of the same body text leading value, you don't need a grid to maintain alignment.

Unwanted paragraph tag after text inset

9.0p255 on XP ... Just searched the forum for a reminder, as it's not every day I need to work with insets. A couple of posts towards the top of a long thread gave the tip of leaving a special space between the anchor for the inset and the end-of-paragraph marker; "ah, that sounds familiar!" I thought, and tried it. Well, it may sound familiar ... but it doesn't work. Yes, I've already tried a special paragraph style with space above and below set to -2; no luck there either. All the more annoying since I'm fairly sure I did manage to do it in another file-set/on another PC last year. Thanks in advance for any tips!

Niels -
I am stuck in Frame 7.0p577 on Mac (having not yet invested in emulators etc.), so what I say here may not apply to Frame 9 on Windows – but it probably does. I am very familiar with the iceberg of an issue whose tip you have encountered. As I see it, here's what's up:
When Frame imports a text inset, it takes the end-of-flow and turns it into an end-of-paragraph (displayed with ¶ at its end, assuming you have Display Text Symbols turned on in View Options). Provided that the inset is followed by another paragraph, then all is well. However, the creation of this extra paragraph is insidious in cases where the inset lies at the end of a flow.
First, if the inset ends a document, an extra line results; that extra line is troublesome if it pushes over a page boundary. The workaround is to increase the height of the page frame, to make room for the line without spilling onto a new page, but that's messy because the manual height adjustment needs to be adjusted again if subsequent editing changes the placement of the extra line.
Second, it seems that the extra paragraph takes the paragraph tag – and therefore, the paragraph formatting – of the FIRST paragraph in the inset. If the first paragraph of the inset's source flow has an autonumber, then the stray paragraph after the inset will appear with ANOTHER autonumber of that style.
Third, if an inset is placed in a table cell, the extra line causes the height of that cell to increase. In the common case that the cell then exceeds the height of other cells in the row, the height of the entire row will increase, leaving undesired space. Workarounds such as manually limiting row height are a pain.
Fourth, if the inset is placed in a footnote, the extra line causes the footnote height of that cell to increase, leaving unwanted space between footnotes of at the bottom of the page.
Over the years I have adopted the following technique: At the front of flows liable to be used as inset sources, I have an empty paragraph tagged BOF. I set the BOF format in both the source document and the host document to Run-In. Any autonumbering in the first functional paragraph of the source will then be prevented from being carried into the referring document. You might think that a comparable paragraph at the end of the inset source – EOF, maybe – would defeat the insidious behaviour that I describe, but too much of this and things start to fail.
I have one or two additional ideas in case anyone who made it this far wishes to contact me directly. In fact I'd be delighted for anyone who understands any of the above to contact me!
I would be delighted if someone at Adobe would follow-up on this, but honestly don’t expect too much.
- Charles,
www dot Poynton dot com

FrameMaker Paragraph tags not consistently mapping in RoboHelp

Similar Messages

Maybe you are looking for