Views
Also, when there is a reference entry with a page break in the middle of it, putting a needLines before the <? rfc include="reference.RFC.XXXX" ?> or whatever xml is creating the reference entry, it doesn't help. (I ran into this when I first started using xml2rfc in June, so it might have been fixed in the August version.)
Probably not fixed --CharlesLevert?, Mon, 19 Dec 2005 04:05:41 -0800 reply
I don't remember doing anything to effect that, so unless it got fixed as a byproduct of something else, it should still be like that.
A sample document would help testing the problem.
Should this be made into systematic behavior? I.e., should each single reference be kept in a single page automatically?
I have a sample file --BillFenner?, Thu, 12 Jan 2006 06:11:10 -0800 reply
I just included a bunch of references until they split across a page; note that RFC 4118 breaks whether the needLines="4" is there or not. http://rtg.ietf.org/~fenner/tmp/needLines.xml
property change --BillFenner?, Thu, 12 Jan 2006 06:14:08 -0800 reply
Name: 'IssueNo0012? needLines doesn't work before included reference?' => 'IssueNo0012? needLines doesn't work before included reference'
now that it's verified, call it a bug. --BillFenner?, Thu, 12 Jan 2006 06:45:26 -0800 reply
Category: general => formatting bug
call it a difficult one... --CharlesLevert?, Thu, 12 Jan 2006 12:43:07 -0800 reply
I just looked at this and it's not going to be easy to solve.
The whole <references> element in the <back> matter is not processed “synchronously”. Furthermore, the <reference>s themselves can be reordered so that the whole thing should be looked at as being more declarative data than sequential instructional data. I would bet that error (and input line number) reporting is affected as well by this.
One alternative, mentioned in some previous discussion, would be for xml2rfc to be smart enough to prevent page breaks within any <reference> by itself. But that would either require an additional fourth pass, which we want to avoid, or some sort of “divert” mechanism, which doesn't exist at the moment.
What about <annotation>s? --CharlesLevert?, Thu, 12 Jan 2006 16:20:48 -0800 reply
Assuming we would go with automatic page break prevention with <reference>s, what should be done if one contains one or more <annotation>s? Each one is already separated from the principal (generated) <reference> text by a blank line. It's a pretty safe bet that any needLines rfc-PI directive won't work for these (and for <texttable> cells and rows as well, which share part of the same internal mechanism). The questions are: should only the principal text be protected as one block, should the principal text and each annotation's text each individually be protected, or should the whole <reference> (principal text and all annotations) be protected as a whole? Or, should every one of these circustamces each trigger a check for an early page break? Keep in mind that a single <annotation> can be a fairly long paragraph if whomever prepared the <reference> so chooses. A whole <reference> might not fit in a single page (so no early page break would automatically be taken on account of that) but each of its parts is likely to.
Assuming we instead go the needLines way, should I work on a mechanism to memorize those somehow, for their argument to be available when the <references> or <texttable> output is actually generated?
My point of view as a hypothetical user of these things is to keep clear of the needLines approach as it's too low-level for my taste. Also, it can't be specified by authors as easily for orphans as it can for widows. I mildly dislike the fact that it's an rfc-PI directive, as opposed to a first-class DTD element or attribute, as well. As an implementer, both approaches will be difficult to achieve given the current program structure.
Given any mechanism we implement, sooner or later, someone is going to ask that it be extended to something else they might need at some point. E.g., with so many contributors (each with an individual description of their contribution) that they don't all fit in one page, it would be natural to prevent some page breaks there as well. The <author> element in <front> is another example of content whose output (one of them) is deferred to the back and that cannot currently be controlled by rfc-PI directives.