Subject: [Tools-discuss] page breaking - Re: xml2rfc community comments

From: Alice Hagens <[email-masked]>
Date: Tue, 8 Mar 2011 18:28:20 -0500

The RFC Production Center agrees with the following 2 comments regarding page breaking in the text output of xml2rfc.

Christopher Dearlove wrote:
> ... regarding page control issues. Currently tables can
> be split (badly) and captions of tables and figures put on
> separate pages to their table or figure. Less critical, but
> while I'm on a wish list, I don't like section headings at
> the foot of a page while the section starts on the next page.

Similarly, John Klensin wrote:
> better handling of widows and orphans 
> (especially with regard to section title-text and lists with 
> undented headings top my personal list,

Julian Reschke wrote:
> From the practical point of view: I'd simply not worry about where page breaks end up in internet drafts. Let the RFC production center deal with it when the time is ripe.

Currently, the RPC deals with it by converting XML to nroff, then handling page breaks using commands in the nroff.  Historically, the RFC Editor has been encouraged to switch to XML entirely, i.e., abandon the intermediary nroff step; this would be more feasible if the handling of page-breaking were improved.

Perhaps the RFP could include improved placement of page breaks.

Thanks,
Alice
for the RFC Production Center

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Mar 2011 10:41:54 +0100

On 09.03.2011 00:28, Alice Hagens wrote:
> ...

I absolutely do agree that *if* we have a tool that produces paginated 
text, it should work well. Which means, that it should *automatically* 
create page breaks in the right places. This means, that additional 
hints in the source file normally should not be needed.

What I said above was directed at people who waste (IMHO) time tuning 
the page-breaking for temporary documents.

BR, Julian

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 18 Mar 2011 14:56:26 +0100

I think this nails down on one essential issue with respect to nroff and
XML.

What is the best editing format?

XML is an extremely fine markup language. It's great for marking up data
in whatever form you have it. As such it is a perfect format for
transmitting data and providing data to a process.

It is NOT designed to be an editing format. At most it is designed to be
human readable and text based which gives it some advantages over ASN.1 in
some applications.

I feel sometimes that XML is favored by some in IETF as editing language
since it is more modern. Yet we can conclude that Nroff in fact is used
for formatting even the XML edited documents because it simply works
better for controlling formatting.

The simple reason being that nroff, as it is used today, captures not only
data, but also formatting rules better than the current use of XML. I also
assume that brining the use of XML editing to the level of Nroff here,
would negatively effect the editing experience with XML.

The heart of the issue is to provide a good editing experience, which
gives the editor control over formatting as well as text editing. In that
sense it is of minor interest what format is used for internal markup
(XML, nroff, HTML, XHTML, JSON or whatever) as long as the transition from
edit to markup can be don unambiguously.

Editing in pure text unfortunately does not provide what is needed, nor
does currently editing in word. Neither can unambiguously be translated to
markup that can be archived.

XML does work to capture information, but in it's current use can't
capture formatting very well.
Nroff is the only format that currently does it all and at the same time
provides good readability during edit process.

I don't believe the right answer is to try to write tons of code that
figures out what an XML draft with incomplete formatting information
probably should look like, but to give the drafters and editors efficient
tools to shape documents in the edit process.

/Stefan

On 11-03-09 10:41 AM, "Julian Reschke" <[email-masked]> wrote:

>> The RFC Production Center agrees with the following 2 comments
>>regarding page breaking in the text output of xml2rfc.
>>
>>>  From the practical point of view: I'd simply not worry about where
>>>page breaks end up in internet drafts. Let the RFC production center
>>>deal with it when the time is ripe.
>>
>> Currently, the RPC deals with it by converting XML to nroff, then
>>handling page breaks using commands in the nroff.  Historically, the RFC
>>Editor has been encouraged to switch to XML entirely, i.e., abandon the
>>intermediary nroff step; this would be more feasible if the handling of
>>page-breaking were improved.
>>
>_______________________________________________
>Tools-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tools-discuss

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 18 Mar 2011 15:11:58 +0100

I have a question regarding the current tools for document comparison.

It is currently possible to specify a local text file to be compared
against a current draft located through a URL.

http://tools.ietf.org/rfcdiff

Currently it is only specified how you can request such diff check if both
documents can be located using http access.

Would it be possible to request diff check also against a locally stored
file using a URL query-string?

If that is possible, then I would love to incorporate a feature in
NroffEdit that would allow you to check you current edit file towards a
past draft on a single click, e.g. By requesting the default browser to
dereference a URL query-string specifying the local text file and the http
location of a previous draft.

/Stefan

---

From: Tony Hansen <[email-masked]>
Date: Fri, 18 Mar 2011 10:28:37 -0400

If you go to tools.ietf.org/rfcdiff, you'll find that you can upload 
locally stored files using the form there.

That is, in addition to the parameters  url1 and url2, there are also 
optional type=file parameters named filename1 and filename2.

     Tony Hansen
     [email-masked]

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 24 Mar 2011 23:24:45 +0100

Hi,

Maybe I was unclear, or maybe I lack some knowledge here.
I don't want to use the form at the tools webpage. I want to launch the
check from my Java application.

I would like to open a browser from my Java application that not only
opens the rfcdiff webpage, but also, by the means of a URL query string,
provides the name of the local file(s) and the URL(s) to compare and
launches the comparison.

In other word, the click of one button in my app results in the done diff
shows up in my browser.

Is that possible, or did you just tell me that but I failed to understand?

/Stefan

---

From: Tony Hansen <[email-masked]>
Date: Thu, 24 Mar 2011 22:22:11 -0400

What you want to do cannot be done using a GET invocation -- it must be 
done using a POST invocation of the rfcdiff URL. That's because you need 
to send the file as part of the payload.

You would format the POST input using enctype="multipart/form-data" -- 
do a quick search on the web and you'll find lots of information on how 
to send data to a web address using that format and POST, and how to 
write the java code to do so. There are a half dozen parameters than can 
be specified for the rfcdiff tool, including either file1 (the contents 
of the first file) OR url1 (a URL pointing at the contents of the first 
file), and either file2 (the contents of the second file) OR url2 (a URL 
pointing at the contents of the second file). (See the rfcdiff html 
source code to find out what the other parameters are.) You probably 
want to use url1 and file2 for your application. You'll then get back 
the HTML web page showing the diff between the two files. Write that to 
a file (probably with a suffix of .html) and invoke your web browser to 
display it.

     Tony Hansen

On 3/24/2011 6:24 PM, Stefan Santesson wrote:
> On 11-03-18 3:28 PM, "Tony Hansen"<[email-masked]>  wrote:
>