Table Footnote

Report · Jul 22, 2011

How do I add space above the first table footnote? In other words,

I want space between the table and the footnote. Thanks.

Report · Jul 22, 2011

Susan,

http://help.adobe.com/en_US/framemaker/using/WS6C3D24E6-2965-48bb-B6CF-50D1439AEB01.html#WSd817046a44e105e21e63e3d11ab7f7561e-7f4d

In the footnote options you specify the name of a paragraph format to be used for the footnote. On a Reference Page you create a graphic frame with exactly this name. This frame is positioned above the first footnote.

All this applies to footnotes and table footnotes.

- Michael

Report · Jul 22, 2011

How do I add space above the first table footnote?

Default FM7, and presumably later FMs, have paragraph format "TableFootnote" predefined. They also have an empty graphics named "TableFootnote" on the Reference Page "Reference". However, this frame is not, by default, enabled in the Advanced > Frame Above properties of pfg fmt "TableFootnote".

You can turn it on, but it appears to apply to all TFNs below that table, not just the first.

I haven't had to deal with this specific issue in table footnotes, but others that are similar (lack of control). Some approaches you can use are below:

Add an empty row to the bottom of the table. Set the text point size to, say, 4. Use Custom Ruling and Shading to make it borderless and unfilled. This provides extra spacing to just the first TFN. Unfortunately this screws up the automatic bottom-of-table border, so you'll need to set the top of the final borderless row to mimic the desired final border.
Don't use TFNs. Use superscript Xrefs by pgf# to a custom numbered pgf fmt that is normal Flow A below the table (aka the EndNote trick). Caveat: this may not "keep" with the table.
Use a borderless final row and put the Xref hacks in there. You can use normal tricks to put space above the first Xref line (empty pgf, etc.). Final border caveat applies.

__________

It would be nice if Frame's "space above" had an option to actually work at top of column, or you could have an anchored frame position of "above current line".

Report · Jul 22, 2011

Error7103 wrote:
How do I add space above the first table footnote?
Default FM7, and presumably later FMs, have paragraph format "TableFootnote" predefined. They also have an empty graphics named "TableFootnote" on the Reference Page "Reference". However, this frame is not, by default, enabled in the Advanced > Frame Above properties of pfg fmt "TableFootnote".
You can turn it on, but it appears to apply to all TFNs below that table, not just the first.
I haven't had to deal with this specific issue in table footnotes,

[snipped]

The reference page Table Footnote frame works automatically to separate the first table footnote from the bottom of the table. It's not necessary to specify it in the Frame Above Pgf property of the TableFootnote format's Advanced paragraph settings; as you noted, if you do specify a frame above, it applies to all instances of the TableFootnote paragraph format.

To adjust the space above the first table footnote, adjust the size of the Table Footnote reference page frame. You can insert a graphic, text line (the A tool), text frame (miniature page icon), or graphic frame (the single icon below the A tool and miniature page icon), into the reference page frame, with tools on the graphics tool panel. One example of this is the separator line in the regular footnote reference page frame.

HTH

Regards,

Peter
_______________________
Peter Gold
KnowHow ProServices

Report · Jul 23, 2011

To adjust the space above the first table footnote, adjust the size of the Table Footnote reference page frame.

Naturally, if I open Help, and search on "Table Footnote", this fact appears in the text of the first result. Probably a worthwhile step before posting replies here

... as you noted, if you do specify a frame above, it applies to all instances of the TableFootnote paragraph format.

It would also be doubling it for the first instance below each table.

Since the basenote poster is likely unfamiliar with these Reference Page objects, they might merit a few words.

The graphic frames on Reference pages are unusual in that they have names. The name is prompted for when you create one, and can be examined and modified with Graphics Properties.

The graphics Text Line nearby, by custom, has text displaying that same name, but is not linked to the frame name. The frame works with or without a Text Line name reminder (or even with an incorrect TL reminder).

I'd guess, however, that the "Footnote" and "TableFootnote" frames work only if they have those exact names. So change the height and content, but not the name.

Report · Jul 23, 2011

Error7103 wrote:
To adjust the space above the first table footnote, adjust the size of the Table Footnote reference page frame.
Naturally, if I open Help, and search on "Table Footnote", this fact appears in the text of the first result. Probably a worthwhile step before posting replies here

Yes!

I've been using FrameMaker since '89, and teaching it since '94 - IOW, since last century - and I've found many times that if I hadn't checked Help and/or tested before instinctively posting something...

I'd guess, however, that the "Footnote" and "TableFootnote" frames work only if they have those exact names. So change the height and content, but not the name.

Testing guessing before posting works for me.

HTH

Regards,

Peter
_______________________
Peter Gold
KnowHow ProServices

Report · Jul 23, 2011

... tested before instinctively posting something...

Well, I was pretty confident that the guess was correct,

but since you've pushed that button, I tested it (FM7WinXP32).

If you change the name of the TableFootnote frame on Reference

Page "Reference", the space that frame used to provide collapses

to zero.

Curiously, if you change the name of the paragraph format from

TableFootnote, (whether also changed in

Document > Footnote Properities or not),

the "TableFootnote" space frame still works. If it's a table

footnote, it gets the TF frame from the RP.

Report · Jul 24, 2011

Error7103 wrote:
... tested before instinctively posting something...
Well, I was pretty confident that the guess was correct,

That's my signal to stop and test.

If you change the name of the TableFootnote frame on Reference

Page "Reference", the space that frame used to provide collapses

to zero.

Changing its name is like deleting it, isn't it? Isn't it logical that if it doesen't exist, it couldn't occupy space below a table?

Curiously, if you change the name of the paragraph format from

TableFootnote, (whether also changed in

Document > Footnote Properities or not),

the "TableFootnote" space frame still works. If it's a table

footnote, it gets the TF frame from the RP.

This isn't logical, according to FrameMaker's rules. All paragraph formats should behave alike. This reveals that the table footnote mechanism breaks or ignores the rules. It's a good thing, if you believe that authors should be able to tag table footnotes with any format name, but the space above should always honor the reference page frame.

If you think the inconsistency is a bug, or the table footnote feature should behave differently, consider filing a bug report or feature enhancement at wish.

Have you tried changing the name of the reference page frame to match the name of the table footnote paragraph format that you specify in Document > Footnote Properties, to see if its space is honored?

HTH

Regards,

Peter
_______________________
Peter Gold
KnowHow ProServices

Report · Jul 24, 2011

That's my signal to stop and test.

If you want fully tested responses on this forum, you need to upgrade your subscription to the Fontmonger Gold level.

This isn't logical, according to FrameMaker's rules.

I just got a different, but more logical result from a slightly different test:

I left pre-defined RP frame "TableFootnote" as is.
I created a new ¶format named "TableFootnoteB", spun off from "TableFootnote".
I changed Format > Document > Footnote Properties ... [Table Footnote]
to Paragraph Format: [TableFootnoteB]
With no RP frame named TableFootnoteB, there was no space-above on a test table footnote. In particular, it did not use the pre-defined "TableFootnote" frame, unlike my previous test of changing the ¶format of an existing footnote.
Upon creating RP frame "TableFootnoteB", and returning to the Body page, the space-above appeared. Tables are now using TableFootnoteB and getting frame TableFootnoteB.

There may be some peculiar behavior in the darker corners of all this, but I don't plan to further explore them.

You can have only one named TF ¶format, named by default "TableFootnote", so there's little point in messing with it unless there's a major issue with the name itself. I can think of some scenarios where that might arise, but they never have in my work (and in general, using the default FM names wherever possible creates documents that are substantially more maintainable than the legacy junk I inherited in my day job).

Report · Jul 24, 2011

Error7103 wrote:
That's my signal to stop and test.
If you want fully tested responses on this forum, you need to upgrade your subscription to the Fontmonger Gold level.
This isn't logical, according to FrameMaker's rules.
I just got a different, but more logical result from a slightly different test:
I left pre-defined RP frame "TableFootnote" as is.
I created a new ¶format named "TableFootnoteB", spun off from "TableFootnote".
I changed Format > Document > Footnote Properties ... [Table Footnote]
to Paragraph Format: [TableFootnoteB]
With no RP frame named TableFootnoteB, there was no space-above on a test table footnote. In particular, it did not use the pre-defined "TableFootnote" frame, unlike my previous test of changing the ¶format of an existing footnote.
Upon creating RP frame "TableFootnoteB", and returning to the Body page, the space-above appeared. Tables are now using TableFootnoteB and getting frame TableFootnoteB.
There may be some peculiar behavior in the darker corners of all this, but I don't plan to further explore them.
You can have only one named TF ¶format, named by default "TableFootnote", so there's little point in messing with it unless there's a major issue with the name itself. I can think of some scenarios where that might arise, but they never have in my work (and in general, using the default FM names wherever possible creates documents that are substantially more maintainable than the legacy junk I inherited in my day job).

Probably the only reason that you created the "TableFootnoteB" experiment to see how it retained or lost logic, is because your earlier assumption didn't match how FrameMaker's behavior. That's how most great discoveries happen, isn't it?

As long as you've already documented the behavior and variations, it's trivial to go the extra step to post them at wish, either as a bug or feature enhancement request, so the developers can benefit from your research, and pass it on to future users.

As to rules and logic: FrameMaker's almost 100% safe to use without unintentionally or unbeknownst losing content.

* The major obvious exception is the limited undo, even with the recent improvements and alerts. Manual saving or saving to new names before performing any risky and undoable action is the best method. Automatic timed backup doesn't help much, and creating backups when saving manually risks overwriting a good backup with a newer bad one.

* The minor non-obvious exception occurs with table title content. Changing a table title's property in the Table Designer, from enabled to not enabled (not checked,) performing Update All, and then performing an action that clears the undo memory, loses the table title in all instances of that table format in the current document, with NO WARNING. It's only the loss of a line or two of text, usually, but it can seriously disrupt a document, unless the user knows to verify table instances that aren't on the currently-visible pages, and doesn't see text visible text reflow.

HTH

Regards,

Peter
_______________________
Peter Gold
KnowHow ProServices

Report · Jul 24, 2011

I fully concur with the backup observations. I'd take a journaled file system over a multi-level undo anytime.

As to rules and logic: FrameMaker's almost 100% safe to use without unintentionally or unbeknownst losing content.

Disagree (for FM7,1 anyway). About once a month I find that the document I've been working on has some text, many pages away from where I'm working, changed to garbage. Last week I found a table that had a cell containing a copy of the last 20 pages of the document (fortunately, it was a copy, and not a move).

If we're luckly, we get an Error 7103 instead. And we get a lot of those. It seems to have something to do with our two-column format and right-run-in anchored frames. I have not had time to test FM9 to see if it's any more stable on our layout.