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.

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

  • 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

  • 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

  • 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.

  • Cross reference markers are deleted for content in text insets

    Cross reference markers are deleted for content text insets. I currently have a chapter that is built from several Import by Reference files. I added an introductory paragraph with cross reference links to heading 2 titles in these text insets. Everything works and saves normally, although the cross reference markers disappear from the chapter when files are checked out a few days later. An extra Heading 2 is also added to the end of the document.
    Steps to reproduce:
    1. Create a chapter composed of several text insets.
    2. Create a list of cross references to headings in these text insets at the beginning of the chapter.
    3. Check in/check out the files from a source control product.
    What went wrong?:
    The cross reference markers are gone, resulting in broken cross references. An empty Heading 2 is also added to the end of the document following the final text inset
    What should have happened?:
    The markers should remain and the heading 2 tag should not be applied to the document.
    Product version:
    Product: FrameMaker
    Version: 7.2
    Platform information:Windows XP
    Hardware: Dell Latitude D620
    OS Version: Windows XP Professional Version 2002, Service Pack 3.
    RAM: 1GB

    Thanks for the information, Van. We did try several techniques including adding the insertion point immediately after the text inset before the normal paragraph tag, but none seemed to consistently work. I will investigate this scenario futher, though, in light of your comments.
    We have managed to determine a workaround for this issue by avoiding a string of text insets. For some reason, using multiple text insets without separating them with normal text causes most of the problems after we add the files to our source control system. The situaton is not ideal, but it does work for the time being anyway.
    Steve

  • 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.

  • Changing relative folder structure with text insets

    (FM11 on Win7)
    What will make the end result maintainable and the make the transition easy?
    A set of project files has the following structure:
    *.book // some for deliverables; some are "workbench" books for managing content
    *.book-generated files, such as *TOC.fm and *IX.fm
    ch_*.fm // These are chapter files that are part of the book. They include ch_*TOC.fm files as insets.
    ch_*TOC.fm // these are the chapter TOC files
    _Graphics // a folder that contains graphics files
    _Insets; a folder of text insets. Some point to files in the _Graphics folder
    To "clean" the top level of the master folder so that it is easier for multiple authors to share, we are considering repositioning:
    The book files and their generated files to a _Books folder, or maybe a different _Book folder for each type of deliverable. We will create more books in the future.
    Chapter and chapterTOC files to a new folder. We will create more chapters in the future.
    The proposed structure is:
    _Books // contains that .book file from above, plus its generated files
    _Chapters // contains the following from above
    ch_*.fm // These are chapter files that are part of the book. They include ch_*TOC.fm files as insets.
    ch_*TOC.fm // these are the chapter TOC files
    _Graphics // unchanged from above
    _Insets // unchanged from above
    Apparently FM11 does not enable a change of relative references to text insets the way it does graphics. If it does, I don't see that feature in the GUI. What am I missing?
    To enable the _Chapters change concept, do I need to MIF each chapter file with a text editor, such as Notepad++, and replace the old relative references with the new one? Something like this?
    WAS <TiSrcFile `<c\>_Insets<c\>filename.fm
    BECOMES <TiSrcFile `<c\>..\_Insets<c\>filename.fm
    Moving the book files does not look as complex. Is this the simplest way?
    Move the chapter files.
    Move the book file.
    Open the book file. Its chapter references fail.
    Add the chapter files from their new _Chapters folder and delete the old broken references.
    Update the book.

    Just be certain to not start the folders at the root of the drive, i.e. C:\Books. This is the "root" level of the drive. Start your entire structure one-level down, e.g. C:\Projects\Books. FM has a nasty habit of converting all relative file references to absolute ones if any of the path to a file traverses the root of the drive. This will will really bite you if you ever have to move your collection to another location.
    Text insts behave differently, in that FM actually stores the entire content of the inset internally as well as maintaining a pointer to the file. Unfortunately, you're going to have to either re-import the inset or tweak the path in the MIF <TiSrcFile....> entry.
    In your current structure, you have the graphics and insets one-level down from the FM files and books (child relationship). In the new structure, you're proposing to move them to a folder at the same level (sibling relationship).
    It probably would be simpler and less error-prone to create new book files after you re-organize your files and ensure that there are no broken file references.

  • 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.

  • Text-inset cross-reference PDF bug ever fixed?

    We're using FrameMaker 8.0 and Acrobat 8.1.
    Has Adobe ever fixed the bug where cross-references in text insets aren't converted to valid links in PDFs? In other words, do we still need to work around that bug by using newlink / gotolink hypertext markers in text insets?

    Robert:
    As far as I can tell, FM8 still exhibits the undesirable behavior...
    Cheers & hope this helps,
    Riley

  • Unresolved cross reference - unresolved text inset

    Is ti possible having at a book all crosses unresolved just because of file renamig??
    it's hard to understand the philosophy of resolving crosses, any knowledge would be welcome

    Cross-references and text insets are links between two different places. An important part of defining the location of each place is the file name. If you change one of those filenames, FrameMaker can no longer resolve the link.
    Using the methodolody that Van outlines, you can safely rename files. This is because FrameMaker watches what you do and automatically makes the necessary updates within the book. If you make changes outside of FrameMaker, though, it has no knowledge of the changes and simply cannot resolve the original links in the future.
    Russ

  • How do I cancel the open method if there's an unresolved text inset in the doc?

    According to the FDK reference guide, the open parameter FS_RefFileNotFound means "Document imports another file that isn’t available." One of the supported values for this parameter is FV_DoCancel, which cancels the open operation. So before calling the open operation, I specifically set this parameter's value to FV_DoCancel. I assumed that if i did that and the document has an unresolved text inset, then the document would not open. But it does. What am I missing?
    Code is as follows:
       var vFileName='C:\\testing\\test.fm'
        var vOpenParams=GetOpenDefaultParams();
        var vReturnParams=new PropVals();
        var index;
        index=GetPropIndex(vOpenParams,Constants.FS_RefFileNotFound);
        vOpenParams[index].propVal.ival=Constants.FV_DoCancel;
        var vDoc=Open (vFileName,vOpenParams,vReturnParams)  
        if (FA_errno!=0)
            if (CheckStatus (vReturnParams,Constants.FV_CancelReferencedFilesNotFound))
                Err ('ERROR: '+vFileName+' was not opened because the document imports files that cannot be found. Verify there are no unresolved text insets in the document. \n')

    What bar are you talking about? Is it part of an add-on?
    If so, open the Add-ons Manager and disable it.
    Type '''about:addons'''<enter> in the address bar to open your Add-ons Manager.
    Hot key; '''<Control>''(Mac:<Command>)''<Shift> A)'''
    Separate Issue;
    Your System Details shows;
    Installed Plug-ins
    Adobe Shockwave for Director Netscape plug-in, version 12.0.5.146
    Adobe Shockwave for Director Netscape plug-in, version 12.0.7.148
    Having more than one version of a program may cause issues.
    Grab the uninstaller from here:
    '''[http://helpx.adobe.com/flash-player/kb/uninstall-flash-player-windows.html Uninstall Flash Player | Windows]'''
    '''[http://helpx.adobe.com/flash-player/kb/uninstall-flash-player-mac-os.html Uninstall Flash Player | Mac]'''
    Then reinstall the latest version.
    Flash Player '''Version 17.0.0.134<br>https://www.adobe.com/products/flashplayer/distribution3.html'''
    Shockwave Director '''Version 12.1.7.157 http://get.adobe.com/shockwave/'''

  • Is it possible to control the order that text flows appear when using them as text insets?

    I want to create multiple flows in a FrameMaker file which I can then insert as text insets. I would like to choose the inset using the Body Page Flow: dropdown list. However, there seems to be no order, alphabetical or otherwise, in which these flow appear in the drop down list. Is it possible to control this order, or is there a particular reason it appears the way it does?
    Cheers,

    IIRC, the flows are displayed in the order that they were created.

  • How can I add dots after text to fill the remaining space in a table cell?

    What is the most efficient way to add dots after text to fill the remaining space in a table cell? I know it is possible using tabs but is this possible using a table?

    You can put a tab inside a table cell using Option+Tab
    Then just set the right-aligned tab stop and the right edge of the table cell and add the leader.

  • Which event dispatched after text selection done on spark text area in Apple iPad using Adobe Flex 4

    I need to know which event triggered after text selection done in Apple iPad. This way i have done in desktop air app code (mouse events)
    protected function txtEditor_mouseUpHandler(event:MouseEvent):void
                if(txtEditor.selectionAnchorPosition != txtEditor.selectionActivePosition){
                    showNoteToolBar(event);
                    txtEditor.focusEnabled = true;
                    txtEditor.setFocus();
    But in Apple iPad how to achieve through "Touch Event" ? And also i need how to hide all context menu on Spaek TextArea?. Why Touch.End event is not fired after place cursor on text area ?
    Please help me !

    Ok, so I finally got it working but this is not ideal at all. Adobe really needs to give us some direction on how to properly deal with font embedding and TLF now that the release build breaks all functionality with loading runtime fonts and TLF.
    Problem:
    I am embedding collections of fonts (faces) into single family classes. Each individual face is registered with Font.registerFont(). I need to do this because I have to have mixed fonts within text flows - at least according to Alex H's recent blog post.
    Fonts do not display in TLF without doing the following:
    1. GlobalSettings.resolveFontLookupFunction = null;
    2. editor.textFlow.flowComposer.swfContext = ISWFContext(this.getFontContext("AnyFamilyNameFromAnyFontEmbedded", false, false, FontLookup.EMBEDDED_CFF));
    3. Instead of #2, use editor.textFlow.invalidateAllFormats();
    Either #2 or #3 need to be performed. If I have a spark richEditableText control in MXML with defined familes from the loaded fonts. I even tried placing the control into a separate state so it wasn't created until after the fonts were loaded... I still needed to invalidate the formats or set the context.
    The "AnyFamilyNameFromAnyFontEmbedded" does not need to be all of the embedded family names. It only needs to be one of them. Once one is used, all embedded fonts work. Also, I have to use the internal namespace to even get access to getFontContext, another oddity that, in my humble opinion, should never be necessary to create mixed style TLF content.
    My questions are then:
    1. Why am I required to use ISWFContext if I am using Font.registerFont()?
    2. Why is GlobalSettings.resolveFontLookupFunction = null; also required for this to work?
    3. What is the recommended workflow to embed fonts from multiple SWF files into the release build and have it work without having to jump through all these hoops?

Maybe you are looking for