Re: [xml2rfc] Page break controls (Was:#311 (Version 2 cli): ability to suppress author org on first page)

[Julian Reschke <[e-mail]>]

On 2017-05-31 17:53, Henrik Levkowetz wrote:
> Hi Julian,
> 
> On 2017-05-31 16:31, Julian Reschke wrote:
>> On 2017-05-31 16:08, Henrik Levkowetz wrote:
>>> Hi Julian,
>>>
>>> On 2017-05-30 15:42, xml2rfc issue tracker wrote:
>>>> #311: ability to suppress author org on first page
>>>>
>>>>
>>>> Comment (by [e-mail]):
>>>>
>>>>    I may sound like a broken record, but still...: we shouldn't add new
>>>>    functionality to PIs, in particular *not* when asked by the production
>>>>    center. If this is required functionality, it *has* to be added as a new
>>>>    v3 feature.
>>>
>>> Changing the subject a bit, triggered by the comment above and recent
>>> experience:
>>>
>>> So, I don't see any consideration given in v3 to how to better control
>>> orphans, widows, and page breaks.  That's an area where either better
>>> PIs or vocabulary support would be needed.  With the current official
>>> PIs there's no way to ask for a page break before the ToC, and the way
>>> to ask for a page break before a section or paragraph is very obscure.
>>>
>>> I don't personally really care whether it's done via PIs or vocabulary
>>> options, but I do care about having it.  I suspect that there are people
>>> who very much would like to get rid of the PIs -- well, in that case,
>>> I think it's necessary to provide knobs in the vocabulary which does
>>> what's needed.  Just ignoring page breaking isn't an option if we want
>>> to produce PDFs and paginated text that looks good.
>>> ...
>>
>> We had epic discussions about this topic, and IMHO the general feeling
>> was that paginated output really isn't that important.
> 
> I think the design group needs to accept that there are other people with
> legitimate needs which ask for this.  It really doesn't matter if you as
> a user don't see it as important, if there are users of the tool who does ...

Well, the audience in this context really was the RFC production center, 
FWIW.

>> Even the
>> attribute you're referring to didn't get a real consensus.
>>
>> Why would we ever want to control whether the ToC starts on a new page
>> or not? (yes, that's a serious question).
> 
> Because the ToC might fit on one page, and doing a page break before it
> would give a much nicer reader experience than getting a break in the
> middle of the ToC, when that can be avoided.

Then a formatter should just do that automatically. Why does it need a 
hint for that?

>>> (When I was poking at the IAB no-author-org-names-on-front-page issue,
>>> I used the draft xml for RFC 7754 as a test case, and wanted to see if
>>> I could make the xml2rfc output look exactly as the published RFC.  In
>>> order to do that, I had to insert <?rfc needLines="-1" ?> in a number
>>> of places, and also introduce a new PI "tocpagebreak" to trigger the
>>> needed page break before the Table of Contents.  Needing manual insertion
>>> of page break points because there are no proper orphan and widow controls
>>> is sad.  I don't see why we should not provide tools which will let the
>>> RFC Production Center staff easily produce documents that actually look
>>> the way they think they should look ...)
>>
>> Apparently you're looking at this from a different angle than I do. My
>> proposal is to entirely get rid of the "we control vertical whitespace"
>> topic. It's - again IMHO - an entire waste of time.
> 
> But then, as a user you're perfectly free to not care, and not use it --
> but you're blocking people who care from being able to write tooling which
> treats this right, when you refuse to listen to the request to include
> support for this.

If you feel strongly about this, raise tickets.

> The result will of course be that since there's no vocabulary support, there
> will be PIs (which I think you want to avoid).

And per RFC, these PIs will have zero effect on the final RFC production 
as they get removed by the preptool.

>> Yes, the defaults should be sensible - thus, under normal conditions, we
>> shouldn't see orphans or windows anyway.
> 
> There are defaults, which are set for 2 lines on each side of the page break.
> And for RFC 7754 the RFC-Editor staff seems to have done post-processing
> which instead used a value of 3.  3 is a perfectly legitimate choice, which
> cannot be provided by today's xml2rfc.

Why do we need to support both? Seriously? Isn't it a goal to have a 
consistent look for all RFCs?

Best regards, Julian