Paranum missing when p's Display attribute set to 'None'

[tomthemoth]

Hi Flare Forums,

Tried to perform my due diligence in searching the forums before posting, but couldn't find this precise issue articulated, so here goes:

The motivation is as follows: I'm building out a project to serve as a template for a technical manual for the products my company sells. These manuals feature a number of figures, where the image always appears above the caption. The captions live inside an auto-numbered <p> tag [ mc-auto-number-format: CF:{b}Figure {chapnum}-{n}: {/b} ] to keep them dynamically numbered in case we insert new ones, move them around, etc.

Initially, I used these caption paragraphs to generate a Table of Figures via a List-Of Proxy. This works fine, but the in-PDF-links 'jump' you to the caption, requiring you to scroll up to see the figure itself, since it's technically the captions which you're creating a list of. Despite this being the completely correct behavior, it was not the desired outcome. My next idea was to add additional <p> that always goes above the image, and since it comes first it also does the incrementing of the figure number counter [ mc-auto-number-format: CF:{b}Figure {chapnum}-{n+}: {/b} ]. If I use these 'bookmark' paragraphs (for lack of a better term) for generating the List-Of proxy, the links generated by the proxy drop me exactly at the top of each figure- good! This has the added benefit of allowing the author to define a short caption for the proxy list, so that a single wordy caption doesn't disrupt the visual flow of the list.

The final touch here is to make the 'bookmark' paragraph content disappear from the print output, since it would be odd to see the figure numbering repeated above and below the image. This is most cleanly accomplished by setting display: none for the 'bookmark' paragraph. At this point, everything works just as I would like, with one exception: cross references.

Even though the Table of Figures functions as desired now, it should also be possible to dynamically reference these figures in the text (ie: "The doodad internals are shown in Figure X-X.") My cross-ref format is simple: {color #8b0000}{paranumonly}{/color}, but when I point it at a 'bookmark' paragraph, there appears to be no paranum value to pull from. If I turn the display styling of the 'bookmark' paragraph back to the default, then the cross-ref will generate correctly.

I suppose the crux of my question is: why can the List-Of Proxy correctly extract the auto-numbered information from my display:none paragraphs, but the cross-ref cannot?

(I'm also completely open to alternate suggestions of how to accomplish the stated goal which sidestep this problem, but none of the alternatives I've tried my hand at have worked...)

Thanks in advance!

[robdocsmith]

Hi,

I think the variation between proxy and bookmark link is probably due to when in the build process the various links are formed. One probably before the paragraphs are removed, one after. Why they might be done at different times is possibly a quirk of how Flare has evolved. All speculation on my part.

*edit*
After watching my builds endlessly today troubleshooting other issues, it can be seen that proxies are resolved into pages before the rest of the document is paginated. Cross references come after this process. So after pagination, your reference no longer exists on the page and the cross reference can't be found.

For me I couldn't find a way around it and decided that it wasn't such a big deal to have captions above figures instead of below.

The only thing I can think of is to have the caption in the text, but make it invisible, through small font size and paper-coloured. That way it still gets registered by the bookmarking part of the build, but can't be immediately seen in the output. Of course, if someone highlighted the text and copied it, they'd see the hidden bookmark paragraph. Is that workable?

Rob

[Nita Beck]

Your idea to have figure titles be above illustrations instead of below is exactly where my clients and I have evolved the last few years. We didn't see the need to stick with a paper-based practice.

[tomthemoth]

It was my suspicion that there was some sequencing at run-time that caused this strange behavior. I had the same though as Rob, to just hide the text with some more trivial technique (coloring it 'transparent', for instance), but then it's equally difficult to see in the editor! It seems onerous to expect authors to tweak the style just so they can see the text to update/edit it, then set it back so it builds properly for 'hiding' these elements.

I've not yet quite solved this to my satisfaction, but I'm glad for the confirmation that I've not missed any glaring error or obvious solution.

Thank you both, Rob and Nita, for the input.