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

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 1 Jun 2017 09:51:18 +0200

Hi Nico,

On 2017-05-31 18:19, Nico Williams wrote:
> On Wed, May 31, 2017 at 04:31:03PM +0200, Julian Reschke wrote:
>> We had epic discussions about this topic, [...]
> 
> We'll all agree to that!
> 
>>                                    [...], and IMHO the general feeling was
>> that paginated output really isn't that important. Even the attribute you're
>> referring to didn't get a real consensus.
> 
> It's easy to say we're divided on this so there's no consensus, but I
> think that's just lame -- this isn't an Internet protocol we're
> discussing, but a document format and tools.  The real question is
> whether *implementors* are going to implement this, and so far the
> answer is "no", leaving users who want this to submit a PR as they
> (naturally) cannot force implementors to do it -- that seems fair
> enough.

Umm ??

I started the discussion about having page break controls in the v3
vocabulary because I'd just added a PI to break before the ToC in
xml2rfc 2.6.0, which I released yesterday.

Am I misunderstanding what you mean when you write 'implementors'?

	Henrik

>> Why would we ever want to control whether the ToC starts on a new page or
>> not? (yes, that's a serious question).
> 
> When the abstract runs long and causes the ToC to be split weirdly
> between two pages, it looks ugly.  Especially to the reader who reads a
> printout.  Whenever the ToC fits on one page, it is very, very nice to
> have it be on one page when you print the doc -- you can more easily
> find it.
> 
> How often do you print I-Ds/RFCs?
> 
> Nico
>

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Thu, 1 Jun 2017 11:58:18 +0200

On 5/31/17 4:31 PM, Julian Reschke wrote:
>> 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. Even the
> attribute you're referring to didn't get a real consensus. 

Hi all,

Consensus on pagination was indeed rough. If you would like a refresh on
the discussion, you can read the rfc-interest archives that hold that
thread here:

https://www.rfc-editor.org/pipermail/rfc-interest/2015-February/thread.html

Additionally, the design team discussed widows and orphans, and
pagination in general, as we worked on the underlying principles for the
work. We captured some of this discussion on the following wiki page:

https://www.rfc-editor.org/rse/wiki/doku.php?id=design:formats&s[]=semantic

I'm not sure if the above information helps this particular discussion
today, but I'd like folks to take a look at it and let me know if you
have new information that informs the format work rather than having us
end up rehashing what was already discussed.

Thanks,

Heather

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Thu, 1 Jun 2017 12:08:31 +0200

On 5/31/17 8:30 PM, Julian Reschke wrote:
> On 2017-05-31 20:02, Henrik Levkowetz wrote:
>> ...
>> Ok.  And hmm.  ... And the IAB has pronounced that mailing list
>> discussions
>> on the topic are to be ignored, as long as there is no ticket?
>> ...
>
> No. I just don't think that the authors of the v3bis spec actually are
> reading this.

Indeed, several of the authors are not on this list. That doesn't mean
we shouldn't have discussion here (or on rfc-interest; it does rather
depend on what type of people you want to engage - implementors or
authors). I support the idea of a github issues list as the easiest way
I know to actually keep track of the requests and outputs for each -bis
doc, but the discussions are perforce going to split between there and a
mailing list. Rather typical IETF community behavior at the moment.

-Heather

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 1 Jun 2017 13:36:44 +0200

Hi Heather,

Trying to sum up the realisation that grew out of this discussion, for
me, in one paragraph:

Not having any support in the v3 vocabulary for attributes that would affect
page breaking will, given the PI-stripping done by the preptool, essentially
take all editorial control out of the hands of the RFC editor for paginated
output produced from RFCs published in XML form.

Best regards,

	Henrik

On 2017-06-01 11:58, Heather Flanagan (RFC Series Editor) wrote:
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc
>

---

From: Ned Freed <[email-masked]>
Date: Mon, 05 Jun 2017 08:23:22 -0700 (PDT)

> Hi Tony,

> On 2017-05-31 20:01, HANSEN, TONY L wrote:
> > On 5/31/17, 1:37 PM, "xml2rfc on behalf of Julian Reschke" <[email-masked] on behalf of [email-masked]> wrote:
> >
> >     On 2017-05-31 19:30, Henrik Levkowetz wrote:
> >     > ...
> >     >> Then a formatter should just do that automatically. Why does it need a
> >     >> hint for that?
> >     >
> >     > Because there might be a judgement call here.  But certainly, if the RFC
> >     > Editor makes a request for such a feature, it can be added!
> >
> > There are two different things that have been getting discussed here:
> > 1) orphan+widow control, and 2) having some way to ensure that
> > certain larger blocks are kept together.
> >
> > The v3 PDF spec requires that the processor does proper orphan and
> > widow control. This is a given, at least for PDF output.

> But it doesn't provide for any settings related to that.  And as I just
> discovered for one RFC, the desired number of lines kept together on
> each side of the break may differ between what a human finds optimal,
> and what's encoded in a tool.

> > The current v3 text spec removed all discussion of pagification. If
> > you dislike that, be a squeaky wheel.

> I'm definitely objecting.  And I thought it was and expressed desire to
> get feedback on the specifications, as work on implementation got done?

FWIW, I object as well. The ability to control pagination would be
quite useful.

> Was I wrong in that?  If so, and if the IAB is willing to say that the
> deficiencies I observe should be ignored, then, I won't feel there's
> much sense in saying anything, of course.

I share your doubts that there's any point to objecting. Again, FWIW:

This argument about pagination control has been going on at least since
the days of DEC-10 RUNOFF (1975?) and likely predates that.

It's but one front in the never-ending war between abstact and device markup.

The abstract markup folks point out, correctly, that device markup is
inherently nonportable, so when you render on a device other than the
intended one it's going to look like crap.

The device markup folks point out, also correctly, that layout is a subtle
and complex business, and no program has ever been designed that does
it as well as humans do. And indeed, most programs do a surprisingly poor
job.

I could go on and talk about the counterarguments, compromise proposals, the
various skirmishes in the development of various tools, and so on, but I see no
point in rehashing all of it.

The bottom line is that we usually end up with something that makes
nobody happy: Device-specific positioning controls, if any are provided,
are usually badly designed and inadequate.

But at one point I realized something: I actually spend more time looking at
the input source than I do looking at the output. So during the document
production process any time I spend on prettying things up is applied to the
source even though that's not something anyone else other than my coauthors is
going to see.

And in the case of Internet Drafts, I'm afraid I no longer look at my own
xml2rfc output at all. I also don't bother giving aesthetic feedback to the RFC
Editor during the final steps of document production.

As for drafts from other people, I use the datatracker. And while there are
cases where it would be really convenient to print something out, I no longer
bother because I know what I'm likely to get.

> > However, the v3 vocabulary does not have a way to say “keep this
> > block together if at all possible”. If you want something along those
> > lines, be a squeaky wheel.

> I think that whoever is supposed to be in control of this specification
> (and Julian's comment about 'raise tickets' makes me feel that exactly
> who that is, is somewhat obscure) should care when deficiencies are
> pointed out.  Even if in some ears it sounds as a squeaky wheel.

Channeling my inner Brian Reid, another thing I no longer care about is what it
sounds like when I talk about this stuff.

				Ned