I like nroff. How do nroff commands relate to xml2rfc?
.bp <?rfc needLines="100" ?>
With xml2rfc.tools.ietf.org, experience is that any value > 49
is ignored when converting to txt format.
Example: create artwork e.g.: 45 lines long, 47 with title.
When using value of 100, no page greak happens. When using
value 47, page break will happen.
Problem 2: Illogical behavior
Maximum size of artwork including two lines for title converting
to txt RFC tht fits a page seems to be 48. When trying to
use an artwork 49 or more lines, the hard to troubleshoot behavior
is that no page break happens at all.
It would be a lot easier to troubleshoot for a user if
nonwithstanding the size of the artwork (or any other
xml object) following, needlines would insert a page break
if there are fewer lines available for rendering on the current
page than the requested needLines. With an artwork too
long, it would then start on the next apge and overflow from
there, so immediately obvious what the problem is.
Issue migrated from trac:344 at 2021-10-20 18:26:06 +0500
component_Version 2 cli
resolution_overtaken by events
type_defect
| by tte@cs.fau.deProblem 1: Incorrect documentation and/or incorrect behavior
https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html
With xml2rfc.tools.ietf.org, experience is that any value > 49 is ignored when converting to txt format.
Example: create artwork e.g.: 45 lines long, 47 with title. When using value of 100, no page greak happens. When using value 47, page break will happen.
Problem 2: Illogical behavior
Maximum size of artwork including two lines for title converting to txt RFC tht fits a page seems to be 48. When trying to use an artwork 49 or more lines, the hard to troubleshoot behavior is that no page break happens at all.
It would be a lot easier to troubleshoot for a user if nonwithstanding the size of the artwork (or any other xml object) following, needlines would insert a page break if there are fewer lines available for rendering on the current page than the requested needLines. With an artwork too long, it would then start on the next apge and overflow from there, so immediately obvious what the problem is.
Issue migrated from trac:344 at 2021-10-20 18:26:06 +0500