Styler - Break footnote text on multiple pages?

[etienne_derouin]

We have a problem with footnotes containing large amounts of text, the latter wholly and constantly staying on the same page as the corresponding footnote marker. This leads to very unevenly distributed text along some pages (i.e. large blank areas at the bottom of said pages).

I have read all the relevant documentaton provided with Styler and tried everything through the Styler interface, but to no avail...

The vast majority of the formatting rules for the "Footnote area properties" seem to be interpreted correctly, but the "Keeps" rules in the "Breaks" category seem to be ignored by the composition engine (it is set to "No" for keep element together, keep with next element and keep with previous element).

Is it possible to allow (or force) footnote text to span on more tahn one page, through the Styler interface or otherwise?

We are using Styler v. 6.0, composing through the FOSI engine (which we would like to keep) and we use the "Inline" footnote model (as qualified in the Styler documentation).

Any help, clue, idea or lead would be most appreciated...

Thanks in advance,

[GarethOakes]

I can confirm that the APP engine supports split footnotes, but I am uncertain about that feature in the FOSI engine.

-Gareth

[etienne_derouin]

Thanks for the reply Gareth,

I've tried composing the same problematic document (with the same stylesheet, of course), this time with the APP engine, but it yields the same result: extra large footnote text, for any given note, stubbornly refuses to break across pages...

I'm I missing something fundamental here? Do I have to (as a matter of fact, can I) further modify the footnote element rules to reach the goal I'm trying to attain?

In Reply to Gareth Oakes:

I can confirm that the APP engine supports split footnotes, but I am uncertain about that feature in the FOSI engine.

-Gareth

[ebenton]

I don't know anything about your doctype, but it could be that one or more parents of the footnote have a keep-together rule which is forcing the footnotes to stay together.

[etienne_derouin]

Our structure is pretty simple (standard DocBook, in fact...): para elements may contain footnote elements, which contain only one child para element.

Within Styler:

- Footnote's parent para element's "Keep" properties are set to "No" for keep together, keep with next and keep with previous. Widows and orphans control is set to "2 or more" (which behaves "as advertised" for the "normal" para elements: they break across pages according to the aforementioned rules).

- Footnote element's "Keep" properties are also set to "No" for keep together, keep with next and keep with previous. In the same fashion, widows and orphans control is set to "2 or more". Even though these properties should flow (or cascade) from the parent para element, I also tried to explicitly specify them for the footnote element... To no avail... It simply doesn't work as it should!

- Footnote's first child para element (explicitly contextualized within the stylesheet) is set to "Inline" (which is normal and the only way to do it to keep the prefixed footnote marker and the footnote text together) and the "Keep" properties in this "Inline" context are not editable (but should again cascade from the parent footnote and/or ancestor para elements).

I've been working with the XSL:FO/FOP combo (Open source solution, mind you...) for years and never encountered such a situation... In fact, the aforementioned pair's default behaviour is to indeed break long footnotes across more than one page in order to preserve some balance within pages in the formatted output.

I'm at my wits' end to resolve this issue... Should I log a bug report with PTC? Did any of you ever went that way in the past and can I expect a resolution in the near future?

Thanks again,

[GarethOakes]

A support call with PTC may be save you some gray hairs 🙂 I would have expected lengthy footnotes to break at some default location (say 1/3 or 1/2 page tall), and they are obviously not in this case. Perhaps Styler itself sets some incorrect default, not sure, I haven't done footnotes with Styler for a while now sorry!

Just a quick thought – have you tried with "out of the box" stylesheets? Eg. take the basic Docbook sample and try making a really tall footnote of "lorem ipsum" text.

-Gareth

[etienne_derouin]

Good reflex, Gareth... 🙂

I have already tried using the "axdocbook" sample application shipped with Styler (both with the APP composer (enabled by default in the stylesheet) AND with the FOSI engine), with dummy data which should reproduce the aforementioned result AND with data from my own book... To no avail: the same problematic behaviour is encountered...

My only hope now resides in submitting a ticket with PTC and see what will be the outcome.

Thank you (and Ed) for your time: it is very much appreciated!

Etienne

In Reply to Gareth Oakes:

A support call with PTC may be save you some gray hairs 🙂 I would have expected lengthy footnotes to break at some default location (say 1/3 or 1/2 page tall), and they are obviously not in this case. Perhaps Styler itself sets some incorrect default, not sure, I haven't done footnotes with Styler for a while now sorry!

Just a quick thought – have you tried with "out of the box" stylesheets? Eg. take the basic Docbook sample and try making a really tall footnote of "lorem ipsum" text.

-Gareth

[ptc-1908075]

Etienne,

The FOSI engine does not break footnotes across pages. Keeps settings are irrelevant.


I don't know if it can be done with Styler, but with a native FOSI stylesheet, I would suggest trying bottom floats in place of ftndesc functionality, and experiment with pagetype settings (same, forward, afterref). If this approach is possible, it could be fine tuned with page layout tags, a .layout file, and a little scripting to cause the first footnote on a page to use pagetype=same.

FWIW:FOSI formatting has four configuration files (uniform, aesthetic, dense, and rigid) which specify different weights and priorities for determining page breaks. With a native FOSI stylesheet, you could try the different settings and see if that helped a little. However, I am not finding a way to do that in Styler.

Formatting changes would help a little:

Increase the leading in the flowtext to help spread the footnotes onto more pages and take up less space on any given page.

Use a slightly smaller font size and leading for footnotes so they consume less space.

Just a thought: If footnotes are so long they fill up pages and require more than one page, maybe end notes make more sense than page footnotes. Pages with lots of footnotes tend to interrupt the reader's concentration.

Hope this helps!

Good luck!

Suzanne Napoleon
www.FOSIexpert.com
"WYSIWYG is last-century technology!"

[etienne_derouin]

G'day Suzanne,

Lots of interesting ideas/leads in your last post...

Native FOSIs (i.e. standalone extractions from the ".style" master stylesheet, thus severing the active link between Styler and the composition stylesheet) are unfortunately out of the equation for this particular project, since I will ultimately have to internaly "pass along the knowledge" in creating/modifying/maintaining stylesheets. My successors' profiles would not fit with that kind of learning curve.

I have also already "tweaked" the basic documents' formatting properties to their fullest (I think...) in order to alleviate the long footnotes issues: footnote font size 8pt (80% of 10pt "base" font size), 2pt space between individual footnote elements, optimized line spacing specifications for both container and footnote elements, etc. Unfortunately, endnotes are also out of the question for my sponsors (eventhough it would definitely be a good idea...).

BUT...

The FOSI resource description (rsrcdesc) edit (which fortunately can be modified directly within Styler) has me thinking... I have already tweaked it in order to the change the default hyphenation rules for the specific language (French) I'm working with (i.e. 3 characters instead of the default 2 for the minpush and minleft values).

I will play around with the 4 different "dftlayoutconfig" attribute values of the main rsrcdesc element and see if the various composition behaviours eliminate (or alleviate) the problem...

Thanks again and I will post the outcome,

In Reply to Suzanne Napoleon:

Etienne,

The FOSI engine does not break footnotes across pages. Keeps settings are irrelevant.


I don't know if it can be done with Styler, but with a native FOSI stylesheet, I would suggest trying bottom floats in place of ftndesc functionality, and experiment with pagetype settings (same, forward, afterref). If this approach is possible, it could be fine tuned with page layout tags, a .layout file, and a little scripting to cause the first footnote on a page to use pagetype=same.

FWIW:FOSI formatting has four configuration files (uniform, aesthetic, dense, and rigid) which specify different weights and priorities for determining page breaks. With a native FOSI stylesheet, you could try the different settings and see if that helped a little. However, I am not finding a way to do that in Styler.

Formatting changes would help a little:

Increase the leading in the flowtext to help spread the footnotes onto more pages and take up less space on any given page.

Use a slightly smaller font size and leading for footnotes so they consume less space.

Just a thought: If footnotes are so long they fill up pages and require more than one page, maybe end notes make more sense than page footnotes. Pages with lots of footnotes tend to interrupt the reader's concentration.

Hope this helps!

Good luck!

Suzanne Napoleon
www.FOSIexpert.com
"WYSIWYG is last-century technology!"

[etienne_derouin]

No luck...

Eventhough Styler allows (and correctly interprets upon composition) the inclusion of customized hyphrule child elements within the rsrcdesc element, it doesn't allow (and preserve) modifications to the rsrcdesc element's attributes themselves...

My guess is the FOSI DTD used with Styler probably uses a #FIXED attribute type for the rsrcdesc element's attributes' values...

Oh well... Time to log this issue with PTC, I guess...