Braniac

Question

PDF bookmarks showing hidden text

Forum|Forum|6 years ago
April 17, 2019
8 replies
5843 views

For purposes of creating xrefs, I have added "hidden" numbers at the end of several paragraph tags. By hidden I mean that they are in a 2-point font, the text is set to a special color (white, but named "zhidden_numbers" and set in the color view to Invisible), and the background is set to white.

Up until the beginning of this month, those numbers did NOT show up in the bookmarks panel when I generated a PDF.

Now they are. I don't want them there. What changed, and how do I fix it?

(NB: I am cross-posting this to the FrameUsers list.)

This topic has been closed for replies.

LinSimsAuthor

Braniac

Arnis: I still use Save as PDF. Old habits, y'know?

Amitoj: The color view is the same in both Sherlock 1 and Sherlock 2. White is set to Cutout, zhidden_numbers is set to Invisible. The autonumbering does not appear in the text in either case (desired). The zhidden_numbers color definition is identical to FrameMaker's definition for White.

For Section 1: Sherlock, the character tag uses White for both Color and Background and does not appear in the bookmarks panel. (desired)

For Section 2: Sherlock (also Section 3), the character tag uses zhidden_numbers for both Color and Background and does show up in the bookmarks panel. (very much not desired)

Technically, I suppose, it is a bug that the autonumbering in Section 1 doesn't show up in the bookmarks panel, but since that's what I wanted I can't complain about it.

I'm not sure if it's a bug that the autonumbering is showing up in the bookmarks panel when the color view defines the custom color as Invisible and the color definition defines the color as Don't Print, though. Personally I'd say yes, because if I don't want it visible in the text, then I also don't want it visible in the bookmarks. YMMV.

LinSimsAuthor

Braniac

More confusion! But your comment has actually opened my eyes to something, so ...

In most places I've worked, you'd see the chapter title formatted on one line as "Chapter #: Chapter Title". But where I work now, the chapter # (Section 6) and the chapter title (Monitoring Battery Health) are on separate lines with different tags.

In those earlier jobs, we weren't using the <$chapnum> variable, we used <n> in a single compound series for resetting various counters. In this job, I designed the formats to use <$chapnum> and I'm not using a single series but multiple ones (it's a whole saga, but it's the only way to reset some counters), but I was so accustomed to using a single series with embedded counter resets that despite substituting in <$chapnum>, I thought there needed to be an autonumber associated with the H1 Heading 1 tag in order for the chapter number to show up in the xref.

That screen shot doesn't show a number on the line containing "Monitoring Battery Health", but in fact the tag associated with Monitoring Battery Health does have autonumbering and always did (see the screenshot for the H1 Heading 1 tag in an earlier post). It's just in a 2-point font that's colored White, so of course it isn't visible on the screenshot. And as long as the font was White and not my custom color, it also didn't show up in the bookmarks panel.

Now I realize that using <$chapnum> in the xref definition means I don't need to have an autonumber in the H1 Heading 1 tag for the xref to pick up, so it's all good. And that also means I can clean up similar tags I have for Figure Captions. Yay! Simplification is good!

I'm curious, though, that it's not doing for you what it does for me. Because I promise you, it does this for me. It really does.

This screen shot shows the bookmark panel from a book that was generated from three files that are identical except that the character tag applied to the autonumbering information for H1 Heading 1 in the first file is set to use White for the font color and background (as highlighted), and the same tag in the next two files is set to use the zhidden numbers color. First file, no number. Next two, numbers.

Is there any chance at all that it's an Acrobat setting? I have never dug into Acrobat settings. If you like, I can send you the 3 files and the book file and the PDF, along with a PDF that shows how all the tags are used.

S

Stefan Gentz

Community Manager

Okay, now I got you. It was not clear to me, that you are talking about paragraph autonumbering. You were just writing in your posts:

For purposes of creating xrefs, I have added "hidden" numbers at the end of several paragraph tags.

and

Those are the <$chapnum> variables (…)

which made me think, you had manually added a chapnum variable in the text itself at the end of a pgf. However, I now understood, that you are talking about the autonumbering feature with autonumbering set to position "End of paragraph".

Now I can also reproduce your issue. It does not matter if the autonumbering is at the end or at the start of a paragraph. As soon as you assign a character style to it with the font color set to FM's internal color "White", the numbering does not appear in the bookmark. Interesting. And from my point of view a bug, although I guess it was explicitly made like this some long time ago for a specific reason.

However, it's clearly something that would need to be fixed. I do not see, why an autonumbering with color "White" should not go into the bookmarks, while all other colors do.

Especially not, as it's a totally valid construction that I can perfectly imagine being used, like in this example, that I have just created:

But anyway: As we have figured out now, for the specific purpose you need to address you can just use FM's internal color "White" for now to get the effect you want to have (autonumbering not showing in bookmark). However, you do not need this construction of a "hidden autonumbering" anyway as we have also worked out (→ chapnum in xref definition):

Now I realize that using <$chapnum> in the xref definition means I don't need to have an autonumber in the H1 Heading 1 tag for the xref to pick up, so it's all good. And that also means I can clean up similar tags I have for Figure Captions. Yay! Simplification is good!

That's the way to go. It's a more stable and more "best practice" / "common use" construction. And more future proof, considering that "White autonumbering not appearing in PDF bookmarks" is a bug.

S

Stefan Gentz

Community Manager

Forgot to answer your question on Acrobat settings: No, it’s not an Acrobat setting. If at all it might be a setting in the PDF library. But my hunch is, that it’s some that FrameMaker drives.

LinSimsAuthor

Braniac

I don't know what to tell you, Stef. I agree that, logically, the number is there in the tag and it should show up in the bookmarks panel. But if it's a bug that the numbers don't show up in the bookmarks panel when the color is White, I don't want it fixed!

This is the house style that was established long before I was hired. I don't like it, but I have no choice in the matter. We're unlikely to ever move out of unstructured, though, unless our company grows by an order of magnitude and/or the techwriting department does. There's only two of us.

This is how the heading in question appears in the document.

If I want to see the section number preceding the name of the section in an xref, I have the choice of inserting two separate xrefs (which annoys the hell out of me), or I can add autonumbering to the text part of the section title that is "invisible", which is what I've done, to give me this:

If Adobe "fixes" this in the future, I guess I'll have to go to the "insert 2 xrefs to the same damn place" strategy or edit all the bookmarks once the PDF is created. I don't really like either choice.

xref format in question:

There are screenshots of both the paragraph and character tags shown above.

I did copy and paste the text from the bookmark into a Notepad file. No number showed up.

S

Stefan Gentz

Community Manager

Hi linsims,

thanks, this was very helpful. I think we have found the cause of the "confusion" now.

Because: What you show here, is a completely different scenario:

This is how the heading in question appears in the document:
Xref in some other place:
xref format in question:

This scenario is, of course, working in the way you expect it and it is so to say "best practice". I would do it the same way:

The heading "Monitoring Battery Health" has just this text (without a number (and from your screenshot, I doubt there is a "hidden one")) and in the xref you are referring to this heading with the definition "<xref>Section <$chapnum>, <$paratext><Default ¶ Font>".

Result: The PDF bookmark will just show "Monitoring Battery Health" (without a number) and the xrefs shows additionally "Section 6", because you have definied that in the xref definition.

My hunch here is, that the change in behavior you noticed, comes from what you started to do differently recently: Now you started to add the chapter number in the heading itself and then tried to "hide" it. But in the scenario, you showed here now, there is no need for that. Just don't put the chapter number in the headings. You can pull them into the xref exactly like you have it there already: "<xref>Section <$chapnum>, <$paratext><Default ¶ Font>".

By the way, I have just tested this on my machine, and I cannot reproduce the effect of "Numbers formatted with FM internal color 'White' do not show up in Bookmarks". Independent of the color, the numbers always show up in the bookmark as they should. So, there is no bug.

LinSimsAuthor

Braniac

I had it set to Invisible first, which is why I was REALLY surprised to see it in the bookmarks panel. I moved it to Cutout to match the definition for White. Just to be sure I hadn't misremembered, I tried it again just now.

I created the custom color by bringing up the definition for White and giving it a new name.
In the color view, I set the custom color to Invisible.
I updated my character tag so that it used the custom color for both Color and Background.
I created 3 new documents, created a book, and ran Save As PDF.

The numbers are in the bookmark panel.

I did also try using the Publish pod (still learning my way around that) and got the same results.

It's weird.

S

Stefan Gentz

Community Manager

linsims, it's not sooo weird – it's actually very logical :-)

Again: Just because you format the numbers on the page in a certain way (like white, 2 points, whatever) with the result being that they are not visible, they are still there. The bookmarks are generated from the whole paragraph text and do not show this formatting. Therefore you see the numbers in the bookmarks.

Just image you would format the numbers in the paragraphs in a different way: Let's say your page background would be black, your paragraph text white and you format the numbers in black. You will not see the numbers (black on black), but they are still there and will therefore also go into the bookmark.

Also, as you mentioned you are using this construction for the purpose of creating xrefs (to the paragraphs with the numbers), I assume that you expect the numbers to appear in those xrefs? If so, and if they do: Same logic.

Can you give us the xref definition that you are using to reference the headings? I'm curious to see this definition (and maybe a screenshot of the text where the xref is).

On Frameusers you mentioned yesterday:

If I use FrameMaker's predefined color White, the autonumber does NOT appear. If I use a color I create that has everything the same except for the name, it does.

This is interesting. I tend to say, this is a bug. The numbers should be there in the bookmarks, even if you are formatting them using FrameMaker's build-in color "White".

I would like to recommend to think about a different construction. This kind of "hack" is not something I would like to rely on. It might work now, but it might no longer work in the future. Also, it might not work in other scenarios (e.g. HTML5 output), migration to XML or other possbile future scenarios.

Oh, and by the way, can you please try someting: In the scenario where it works (with FM built-in color "White"), please select a bookmark and press F2 to edit the bookmark and then ctrl+a to select everything in the bookmark, and then ctrl+c to copy it. Then paste it into a plain text editor like Windows Notepad. Is the numer there and you just do not see it in the bookmark?

LinSimsAuthor

Braniac

The only difference I can determine between the document where it still works and the new document where it doesn't is that the document where it works uses Frame's pre-defined color of White for the character tag and the new one uses a color definition I created which is a duplicate of White except for the name.

Guess I'll put it back to White and delete the custom color. Seems odd that one would work and the other wouldn't when every single setting is identical.

Arnis Gubins

Inspiring

Lin,

Have you tried setting your custom colour to "Invisible" using the Color Views option prior to creating the PDF? FM should never output any item with a colour set to "Invisible". Using White, the (auto-)number would still be there if you do a copy&paste from the PDF (as Stefan indicatea), you just don't see it in the PDF. With the "Invisible" setting, the number should never get to the PDF in the first place.

S

Stefan Gentz

Community Manager

Makes sort of sense to me … The numbers might not be "visible" due to special formatting, however they are actually "there." The bookmarks however do not show formatting, but just the unformatted string (which includes the numbers). Try to copy and paste the whole paragraph text to Notepad or any other plain-text editor, and you will see them as well. And this is exactly what the "(unformatted) plain text bookmarks show.

Also, as you write that you are doing this construction for the purpose of creating xrefs: Am I correct in assuming that those "hidden" numbers appear in the xrefs pointing to these headings? If they do – why should that be different in the bookmarks?

However, strange is, that this is new behaviour in your scenario (I would have actually expected it to be there always). So your question "What changed?" [at the beginning of this month] is a good one. Or maybe the question other way around is be: Why did the numbers did not show up in the bookmarks before? (I think they should have had!)

W

Winfried Reng

Braniac

Hi Lin,

Did you create these numbers with automatic numbering?

Or did you add these numbers as regular text, but with a special formatting?

When automatic numbering, yes, depending on your cross-reference format the numbers will not show.

I also do not understand why the numbers had not been copied into the bookmarks some weeks before. As Stefan said the numbers should always be copied to the bookmark text. Whether regular text or autonumbering should not matter.

Did you update your FM version?

Best regards

Winfried

LinSimsAuthor

Braniac

I just noticed I hadn't answered this.

It's Frame 2019, update 3. My employer pays for a subscription to the Creative Cloud, and Acrobat was updated earlier this week.

As I've said elsewhere in this thread, though, even with the latest updates applied, if the font color in the character tag that is applied to the paragraph's autonumbering is set to White, as opposed to the custom color, it does not show up in the bookmarks panel. I retested that this morning. Acrobat is not picking it up the trailing autonumber, at all, as shown when I performed Stefan's test opening the bookmark text for editing, copying the entire text, and pasting it into Notepad.

LinSimsAuthor

Braniac

Oh, yes, and if anyone can help me figure out how to get the bookmarks to read as "Section 1: Evelina", etc., even though the "Section 1" and the "Evelina" are two separate tags on two separate lines, that'd be lovely. I hate having to go in and edit bookmarks.

LinSimsAuthor

Braniac

If anyone is wondering what this looks like, you see those numbers circled in red in the bookmarks panel? Those are the <$chapnum> variables that are supposed to be invisible in the text (and are) but they are showing up in the bookmarks, where I definitely don't want them and where they were never showing up before.