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

Similar Messages

  • 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

  • Feature request: Heading Tags and Paragraph Tags for Text element

    Sugestion: Would like to see Reflow be able to format text element with heading tags like <h1> and paragraph tag <p>.

    Thanks! Style management and reusable styles are a HUGE feature set coming to Reflow...won't be there immediately but very soon.  Thanks for the input.

  • PgfLocked Yes after text inset

    I'm spinning off versions of some manuals for another division (same product, different paint), and decided that rather than entirely clone parallel FM files, I'd try having the main Flow A be a text inset from the defining instance of the product manual, with division-specific content controlled by Condition Codes. Grave warnings on this forum to the contrary notwithstanding, it works perfectly . But I did run into an oddity while testing.
    The clone manual started as a whole-flow paste of the defining content. When I began to test doing it as an inset, I deleted the clone Flow A, which had a Heading1 as the first Paragraph Format. This left an empty Heading1, into which the defining flow was imported, as:
    <*> Body Page Flow [ A (Main Flow) ]
    <*> Retain Source's Formatting
    <*> Automatic
    Alas, there were two extra empty pages at the end, due to the Heading1 having Top of Page elected, and due to Make Page Count Even on save.
    So I deleted the inset and tried to change the Heading1 to Body.
    No go.
    I could insert or delete text in that Heading1 (so it wasn't set to read-only), but nothing would change the Paragraph Format.
    So I saved it as a MIF. I found these tags:
    <Para
      <Unique 5547797>
      <PgfTag `Heading1'>
      <Pgf
       <PgfLocked Yes>
      > # end of Pgf
      <ParaLine
       <TextRectID 80>
       <String `'>
      > # end of ParaLine
    > # end of Para
    > # end of TextFlow
    # End of MIFFile
    I've never noticed tag PgfLocked before.
    And if you import the inset with
    <*> Reformat Using Current Document's Formats
    tag PgfLocked is not there.
    Changing "Yes" to "No" (MIF hacking) fixed the problem.
    Is there a Frame menu item for this? (this is 7.1/Unix)
    I'm guessing that specifying:
    <*> Retain Source's Formatting
    is what's causing the lock.

    ... I don't believe it's documented in the FM9 MIF reference guide
    It's certainly not in Help. And it's had no mention here (at least based on a quick googling).
    I probably never noticed it before because it's probably never been in any MIF I hacked.
    Meanwhile, back at the culprit:
    <*> Retain Source's Formatting
    I found two more reasons to avoid this option on text insets:
    Text defined by Variables in the inset lose their Character Formats (and it might be my imagination, but the loss appears to occur during printing - the ChFmt is visible during edit)
    If the text inset contains a text inset (yes, that actually works), text defined by Variables in the subordinate inset don't make it into the top document at all.
    And this is the case when when all of the documents involved share the same pfg/ch formats and variable defs.
    <*> Reformat Using Current Document's Formats
    fixes both of these problems, plus the <PgfLocked Yes> issue.

  • Add paragraph tags after each period

    Hi!
    I'm into a hidious task to add <p> </p> paragraph
    markers after each period (.) in a long set of text. Is there any
    way to automate this work?

    Andy Bay wrote:
    > I'm into a hidious task to add <p> </p>
    paragraph markers after each period (.) in a long set of text. Is
    there any way to automate this work?
    Start by making a backup, then use Find and Replace.
    Set the Search to Source Code. Search for ". " (without the
    quotes).
    Replace with ".</p><p>" (again, without the
    quotes). Click Replace All.
    You can finally tidy it up with Commands > Apply Source
    Formatting.
    David Powers, Adobe Community Expert
    Author, "The Essential Guide to Dreamweaver CS3" (friends of
    ED)
    Author, "PHP Solutions" (friends of ED)
    http://foundationphp.com/

  • Unknown space after text inset

    As seen in the picture below (also added link for larger picture, will be available 24 h ExtraZoom High Definition image #32005. Zoom in or zoom out high resolution photo.),
    there is a huge space between the inset (table broken across 2 pages) and the following paragraph.
    All insets are written in the same way, but only this one happens to look so weird. I've checked the inset and there is no huge space at the end of it.
    As you can see in the picture below, the end of the page is right at the end of the table's anchor (text cursor can be seen)
    Any ideas as to what I could possibly do to resolve this?
    Thank you!

    Hello!
    In regards to your response, I've uploaded the fm files (main file + insets) and scrubbed the confidential information out of them. The issue is still reproducible, as seen in the Data.fm document.
    Thank you for replying on such short notice!
    Dropbox - fm files.zip

  • Getting and setting paragraphs space after

    Hi,
    I'm trying to create my first script (using javascript)... The idea is to increase (or decrease) space after a paragraph (0.5 mm). I can't find anywhere how can I get the space after value of a selected paragraph... Could someone please help me?
    I'm brazilian... Sorry about my bad english!
    Thanks.

    Hi.
    try this code
    var para = app.selection[0].paragraphs;
    try {
      para[0].spaceAfter -= 0.5; // or += 0.5
    catch(e){alert(e);} // space after and space before must >= 0
    and, you can get other properties with this code
    $.writeln(para[0].properties.toSource().replace(/,/g,",\n"));
    thankyou,
    mg

  • Weird and unwanted color gradient after Photomerge

    Hi all,
    I got an annoying problem with a weird color gradient that appears where it shouldn't. My context is, that I'm producing underwater photomosaics. I use Photomerge for merging, which works great for the often uniform seabed sediment images.
    [merge1.jpg]
    The example is 65 images, btw. After placing the images manually within Photomerge, all looks great and ready for a perfect result after rendering (see above). However, when doing so, the final merge from within Photomerge (by clicking the OK button) creates perfect smooth blending, but a weird color gradient crossing the whole mosaic. this might originate in the fact, that the individual images also are not perfect, due to the uneven lighting situation underwater. In case all images are a bit reddish at the top and yellowish at the bottom, the final gradient over the full mosaic shows that as well. So to me it looks as if Photoshop just tries to be too smart and thinks, reapplying that pattern to the whole would be a great thing to do, which it isn't of course.
    [merge2.jpg]
    I discussed this "bug" with (indeed very helpfull) Adobe staff and they recommended, to create the merge with the "Blend Images Together" option in the "Load" dialog unchecked. This creates a mult-layer document after rendering, with the images being placed properly but not blended.
    [merge3.jpg]
    From here on, Adobe staff  recommended, I shall use the "Auto Blend Layers" function (File menu), but the result is identical as image 2. Ok, then, they recommended, to uncheck "Seemless Tones and Colors" in the "Auto Blend Layers" dialog. Indeed, this gets rid of the gradient, ...
    [merge4.jpg]
    ... but shows very hard edges of the images, which get very prominent after optimizing levels:
    [merge5.jpg]
    Was that understandable? Would anyone have experienced (and solved) the same issue? Or would anyone have an idea, how this could be handled in a way, that my resulting mosaic looks as perfect with respect to the original colors as in the initial merge window before rendering it (image 1)? Maybe it's a specific Color Setting (Edit menu)? I tried a lot so far but nothing helped and I might not have tried the right thing.
    The problem appears, btw, in CS3 to CS6!
    Any help appreciated, more information on request! Many thanks,
    g

    H there,
    @TLL: you're right with what you said about the subjective element. Getting spoiled is easy, but staying ambitious is good as well. I do these mosaics since 2003, when Photomerge was part of Elements only. Then, in the first years with CS and CS2, I never had this bug with the color gradient being applied to the final merge. This started with, I guess, CS3 and I think it's due to enhancements Adobe made to the programm (making it more "intelligent"). Unfortunately, sometimes enhancements have dark sides and cause unexpected issues elsewhere. And since we are a minority (making large merges), these do not get fixed, since the majority, stitching what, 20 image panoramas of their home and garden do not suffer. Their images have strong contours and contrasts and the issue gets effective only on uniform images like underwater sediment or, in your case, landscapes shot from above. Going back to CS or CS2 is no option, since only the newer versions give me the processing power I need, also is the blending much smoother.
    I played around with gradient masks but I haven't got the right touch yet. Even if I get rid of the color differences, there will always be a brightness gradient, since borders of the images are always darker. And then, the weird gradient is a bright / dark one, not a red / yellow one. Not much better. Also, each batch job has to work for thousands of images, so has to be a compromise. I just cannot spend more than a day for a 1000 image mosaic, or a week for 6000 images, time is money on a ship (and elsewhere).
    I just think the solution would be, splitting the "Seemless tones and colors" function up into "Seemless Blending" (doing soft blending but not changing the colors) and "Seemless Color Transitions" (just dealing with the colors). And making both optional by check boxes...
    So far,
    g

  • Text Inset in Container File Loses Conditional Tag

    Hi,
    (Framemaker 8.0p277,unstructured)
    I have a number of books that make use of text inset and conditional text.  Some text insets contain conditional text in their source. Then, after the inset is put into the container file, the inset may be further conditionalized. This illustrates the situation:
    --- Text Inset ---
    This inset was created for end users.
    When using function X, blah blah blah
    -----End Inset----
    The red text indicates an InternalDocComment condition. This inset is then placed into the container file where it has another condition applied, PrintOnly for example. PrintOnly is in blue.
    The writer is able to set all this up fine. After placing the inset into the container, she selects the inset and applies PrintOnly.  The text inset appears in blue and the InternalDocComment as visible shows the maroon of two mixed colors. The writer saves the file, continues working on the files, then later in the week, the writer opens the container file. The blue color indicator is gone from the inset. When the writer selects the inset and chooses Apply Conditional Text, the Conditional Text dialog shows the current selection is Conditional (radio button) but no tags appear in the In portion of the dialog.
    I've tried using spacer paragraphs in and around the text inset to see if we can get the conditional tag to "stick" but nothing is working.
    Has anyone run into this before?
    TIA,
    Mary

    I use a lot of conditional text and insets but within a structured document. I have noticed that FrameMaker does not always do what one thinks it does. For example, copy a piece of unconditional text and paste it in the middle of conditional text and the pasted text remains unconditional. Each time you open the document, FrameMaker updates the text insets. In your case, it is updating a text inset that is on the whole unconditional. So, my guess is that it bringing it in as unconditional, much like the copy and paste example above. You might test this by creating a small document with the inset and over conditioning, saving it in the mif format, opening the mif file, and looking at how the conditioning is applied. Then save the Frame file, open it, save as mif, and repeat the above. If the containing file conditions DO hold up, then try removing the conditioning within the containing file and reapplying it; this may help to clear out some bad conditioning.
    I vaguely recall trying to conditionalize a text inset within the containing document and had problems. I cannot remember what exactly the problems were. My solution was to do the conditioning within the inset file itself. So, if the text inset is always to be conditionalized in the containing document, then do the conditioning within the document itself.

  • Some conditional text in text inset showing when text inset is set to condition and hidden

    I'm using Frame 8 on XP Pro SP3.
    I have some text insets that I want to mark to appear or disappear depending on whether the document needs them or not. One is "domestic" and the other is "row".
    My problem is that within the text inset is a condition (G2) that also appears in the document that I want to show in the document whether or not the text inset shows.
    So what's happening is:
    1 - Click on the text inset.
    2 - Set it to "domestic".
    3 - Set my target file to show "row" along with "G2".
    4 - The text inset disappears except the "G2" tagged text from the inset still shows.
    I end up with a heading on the following paragraph that has the paragraph number followed by however many instances of text tagged "G2" in the text inset or insets followed by the actual text of the heading.
    I seem to remember that previously if you tagged a text inset with a condition and then turned off the condition, the text inset (all of it) did not show. So it appears that Frame 8 now will hide the text inset except for any text tagged with a condition that is used and set to show in the target file.
    I'm haven't played with the expressions much, but I'm not sure there's a way to tell it to use the "G2" condition in the file, but ignore it if it's in a text inset that isn't to be shown.
    Thanks,
    Mike

    Mike, please specify the exact version of FM you're using, from Help > About, the "pxxx" numbers.

  • TOC imported as Text Inset does not have active hyperlinks in PDF

    Hello,
    The template I've inherited uses a method in which the TOC appears in the main FM doc as an imported text inset. To create the TOC, a standalone TOC is created and then imported as a text inset to the specific location in the main file. When this FM file is saved as a PDF the TOC page's hyperlinks don't work.
    --Am I doing something wrong, or is this a limitation of importing text insets as a TOC?
    Thanks,
    Donna

    Apologize for the delay but had to wait until I visited this particular client again to check out your suggestions. Started out with Art's basic pointer and then applied Van's solution. Michael's solution I'm filing for future reference!
    Thanks so much to all of you for your help! Am truly grateful.
    Donna

  • 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

  • Issue Using C# to Get RTF Text From Clipboard to Outlook With Formatting and Without Encoding Tags

    I have created a little application that gathers data from various text boxes and then combines the data into a formatted richTextBox.  A person using the tool asked if I could then add a button that would allow that text (with formatting) to be copied
    and pasted into an Outlook Email.  When I do this, I can get the text into an email, but I either strip out the formatting or I get all the RTF encoding tags to come along with it. 
    I have tested to see that the copy of the data from the richTextBox has indeed made it to the clipboard correctly.  This has been verified by the fact that I can manually press "ctrl" + "v" and I can past the text with proper
    formatting into the mail body.
    I do know that I can brute force things by trying to manually wrap HTML tags around my textBox fields and then pipe that into an HTMLBody property.  In fact I can get a lot of things to work with the HTMLBody property, but while it is nice that will
    work, I feel that I must be missing something really simple while trying to work with RTF.
    I currently am pasting (using the Clipboard.GetText(TestDataFormat.RTF)) the RTF data into the Body property of the mail item.  This is bringing in all the RTF encoding tags.  I have tried to paste this directly into the RTFBody of the mail item,
    yet an execption gets thrown when executed.  Oddly, though, if I change RTFBody to HTMLBody, I do not get the exception, but I still have the RTF encoding tags in it.  Though if I feed the HTMLBody property straight, HTML text with the encoding tags,
    it will render properly.
    This has me confused then why if I feed HTMLBody HTML text with the encoding tags that it will render, but if I try and do the same for RTFBody and feed it RTF text with encoding tags it still throws an exception.  Any help in the matter would be greatly
    appreciated.  I have included the code snippet below for sending the richTextBox information to the clipboard and then attempting to retrieve it and paste it into an Outlook email.
    Thanks for the help.
    Some pertinent information:
    Blend for Visual Studio 2015 CTP6 (I switched from VS2012 as intellisense was added to Blend in 2015)
    Because of this Systems.Windows.Forms is not in use
    private void buttonEmail_Click(object sender, RoutedEventArgs e)
    //Copy richTextBox information to Clipboard
    Clipboard.Clear();
    richTextBox.SelectAll();
    richTextBox.Copy();
    //Get current date to add to email subject line
    DateTime myNewDate = new DateTime();
    myNewDate = DateTime.Now;
    //Create Email
    Outlook.Application myNewApplication = new Outlook.Application();
    Outlook.MailItem myNewMailIoI = myNewApplication.CreateItem(Outlook.OlItemType.olMailItem) as Outlook.MailItem;
    myNewMailIoI.To = " "; //An attempt to ensure that the focus moves down to the body field
    myNewMailIoI.Subject = "IoI - " + myNewDate.Date.ToString("d");
    myNewMailIoI.BodyFormat = Outlook.OlBodyFormat.olFormatRichText;
    //Pasting data into body of email
    myNewMailIoI.Body = Clipboard.GetText(TextDataFormat.Rtf); //This will past the text with encoding tags into email
    //If this section is uncommented, it will add a properly formatted HTML text to the email
    //myNewMailIoI.BodyFormat = Outlook.OlBodyFormat.olFormatHTML;
    //myNewMailIoI.HTMLBody = "<p>This stinks!!!</p>" + "<p style='color: green; font-size:10pt; font-family:arial'>different font and color</p>";
    myNewMailIoI.Display(); //Allow for window to be minimized
    myNewMailIoI.Display(true);

    Ok, I found the solution.  Part of the issue was caused by the confusion of the HTML body property acting as a text encoder for HTML text when a string is passed in vs the RTF Body property needing to have a plain text file taken and encoded into a
    byte stream.  Even though the RTF text is in readable text (albeit with the RTF Encoding Tags) it needs to be reencoded into a series of bytes. 
    This is where I failed to understand the previous answers.  I knew that RTF Body needed to have a array of bytes, and the previous answers seemed to indicate that the data in the clipboard was already in this byte format (this may have just been my
    misunderstanding) and that I needed to somehow take this byte array and do something with it.  My misunderstanding was that all the methods for getting values from the clipboard returned strings and not bytes.
    after some digging last night and with the few hints that were offered before, I came across a post on CodeProject (apparently I cannot post links, so I will try and include this so that you can find the postcodeproject(DOTCOM)/Questions/766917/How-to-convert-richtextbox-output-into-bytearray). 
    This showed that I needed to take the raw, RTF text with its RTF encoding tags from the clipboard and and encode it to a byte array and then pass this into the RTF Body property.  Included below is the final code such that I hope that it helps some other
    person as there seem to be a lot of searches for this on the web, but not a lot of direct answers.
    using System.Text;
    using Outlook = Microsoft.Office.Interop.Outlook;
    private void buttonEmail_Click(object sender, RoutedEventArgs e)
    //Copy richTextBox information to Clipboard
    Clipboard.Clear();
    richTextBox.SelectAll();
    richTextBox.Copy();
    //Get current date to add to email subject line
    DateTime myNewDate = new DateTime();
    myNewDate = DateTime.Now;
    //Create Email
    Outlook.Application myNewApplication = new Outlook.Application();
    Outlook.MailItem myNewMailIoI = myNewApplication.CreateItem(Outlook.OlItemType.olMailItem) as Outlook.MailItem;
    //Add Subject
    myNewMailIoI.Subject = "IoI - " + myNewDate.Date.ToString("d");
    //Set Body Format to RTF
    myNewMailIoI.BodyFormat = Outlook.OlBodyFormat.olFormatRichText;
    //Converting RAW RTF data from string to bytes. THIS IS THE FIX THAT WAS NEEDED TO MAKE IT WORK
    string myNewText = Clipboard.GetText(TextDataFormat.Rtf);
    byte[] myNewRtfBytes = Encoding.UTF8.GetBytes(myNewText); //This line cost me way too many hours of lost sleep!!!
    //Inserting RTF bytes into RTFBody property
    myNewMailIoI.RTFBody = myNewRtfBytes;
    myNewMailIoI.Display(); //Displays the newlycreated email
    //If this section is uncommented, it will add a properly formatted HTML text to the email
    //myNewMailIoI.BodyFormat = Outlook.OlBodyFormat.olFormatHTML;
    //myNewMailIoI.HTMLBody = "<p>This works for the HTMLbody property!!!</p>" + "<p style='color: green; font-size:10pt; font-family:arial'>this renders properly</p>";

  • TCS4: Hyperlinks in RH10 are broken after an FM text inset. Why?

    Hyperlinks from another FM document of the same FM Book does not work in RoboHelp after an FM inset. But hyperlinks from the same FM document works in Robohelp after an FM inset.
    All the hyperlinks work in PDF.
    Note: The hyperlinks are not within the text inset but outside the text inset. As long as it is after the text inset, from that point onward, the links will not work (if they point to another FM doc).
    eg:
    text inset
    content
    hyperlink broken (from another FM doc of same FM book)
    Please help. It would be a pain if this does not work at all.
    Kai

    I would set up a simple set of files to test this with TCS5 (download a trial on a machine that doesn’t have any TCS products on it) and if you can reproduce the behaviour, report it as a bug and send the files to the TCS Support group. They’re not going to be patching TCS4 now that 5 is out.

  • Text Insets and Cross Reference Links

    When I use text insets to produce a host file from my source file, I have cross reference links that update OK. However, once I produce a PDF of the host file (text inset), my links do not work. I do not even get the little hand icon to indicate they are links. I am producing my PDFs using File/Save As PDF and the first checkbox on the Links tab is checked. Is this a problem using text insets?

    Unfortunately, that's the way insets work in FM. Cross-refs within an inset do not automatically become active. If you convert the inset to text, then the links are made. I believe that Rick Quatro wrote a Framescript to handle this in an automated way.
    The manual way to do this, is to make a copy of the book - using Bruce Foster's Archive utility is the way to go: see http://home.comcast.net/~bruce.foster/Archive.htm
    Then use the Edit > Text Inset Properties > Convert... > All insets to embed the insets into the documents (you have to do this on a file by file basis); regenerate/update the book file and only then create your output.

Maybe you are looking for