Subject: [TOOLS-DEVELOPMENT] Developing an SoW for a CSS

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Fri, 19 Feb 2016 11:46:34 -0800

Hi all,

We don't currently have an SoW drafted for the CSS described in
https://datatracker.ietf.org/doc/draft-iab-rfc-css/.  I've made a first
pass at it, pointing at the detailed requirements in that draft.  I do
think that a professional designer is a better way to go than the
bikeshed that will ensue if we make this a community-sourced thing.  Any
thoughts or feedback?

-Heather

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Fri, 19 Feb 2016 13:02:27 -0800

Significant correction to the word doc

On 2/19/16 11:46 AM, Heather Flanagan (RFC Series Editor) wrote:
> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Fri, 19 Feb 2016 21:35:16 +0000

Should the SoW be extended to cover PDF as well? (The PDF doc essentially follows HTML+CSS with various "tweaks".)

Tony

From: TOOLS-DEVELOPMENT <[email-masked]<mailto:[email-masked]>> on behalf of "Heather Flanagan (RFC Series Editor)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 19, 2016 at 4:02 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TOOLS-DEVELOPMENT] Developing an SoW for a CSS

Hi all,

-Heather

_______________________________________________
TOOLS-DEVELOPMENT mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/tools-development

---

From: Russ Housley <[email-masked]>
Date: Sun, 21 Feb 2016 14:36:01 -0500

Heather:

I would not know how to bid on this task.  It really just says to work with the RSE and the community to come up with a CSS.  I think you need to give an expected sequence of events.  Maybe something like:

	- vendor comes up with a strawman CSS,
	- RSE review,
	- revise strawman CSS,
	- community review, and then
	- produce final CSS.

Russ

---

From: Julian Reschke <[email-masked]>
Date: Mon, 22 Feb 2016 09:07:23 +0100

> bikeshed that will ensue if we make this a community-sourced thing.  Any

I'd expect that bikeshedding will happen no matter who comes up with the 
CSS. So I wouldn't take that as argument in favor of getting 
professionals to do it.

Best regards, Julian

---

From: Bob Hinden <[email-masked]>
Date: Mon, 22 Feb 2016 05:56:25 -0800

> On Feb 22, 2016, at 12:07 AM, Julian Reschke <[email-masked]> wrote:
> 
> I'd expect that bikeshedding will happen no matter who comes up with the CSS. So I wouldn't take that as argument in favor of getting professionals to do it.

I suppose might be best to avoid having to pay someone $$/hour to deal with the “bikeshedding” :-(

Bob

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Mon, 22 Feb 2016 09:27:33 -0800

Taking a given XML file that transforms into particular HTML and PDF
formats (as described in the requirements drafts), we want a page design
for CSS and PDF that will take into account accessibility and follow a
responsive design. The expected output of this RFP will be a single CSS
file that will be embedded in the rendered HTML and PDF. Note that the
HTML and PDF files must be rendered from the XML; the PDF will not be
generated through an HTML transformation.

Is that clearer/more accurate?

-Heather

On 2/19/16 1:35 PM, HANSEN, TONY L wrote:
> Should the SoW be extended to cover PDF as well? (The PDF doc
> essentially follows HTML+CSS with various "tweaks".)
>
> Tony
>
> From: TOOLS-DEVELOPMENT <[email-masked]
> <mailto:[email-masked]>> on behalf of "Heather
> Flanagan (RFC Series Editor)" <[email-masked]
> <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
>> [email-masked]://www.ietf.org/mailman/listinfo/tools-development
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 22 Feb 2016 19:27:53 +0100

> Is that clearer/more accurate?

Since when do we have a requirement that the PDF can not be generated 
via the HTML version?

Best regards, Julian

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Mon, 22 Feb 2016 10:47:04 -0800

> Since when do we have a requirement that the PDF can not be generated

We talked about that on the design team, though I don't believe the
design team entirely agreed with me on it.  The output formats should be
generated from the XML; I think it lends more equivalence to the
outputs, and it (probably) shortens the path to possible issues in the
tool chain. Yes, I know there are tools that already exist that easily
convert from HTML to PDF. There are also tools that convert from XML to
PDF. I think this should be more about clean process than tools.

-Heather

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 22 Feb 2016 20:15:22 +0000

>Since when do we have a requirement that the PDF can not be generated 

Yeah, I was going to jump on that one also. That last sentence needs to be struck; it's an implementation detail on how the PDF generation should be handled and does not belong in this statement. Perhaps the best method of generating the PDF is doing a transformation on the HTML and perhaps it is not. For the purposes here, we don't care.

	Tony

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Mon, 22 Feb 2016 13:33:39 -0800

On 2/22/16 12:15 PM, HANSEN, TONY L wrote:
> On 2/22/16, 1:27 PM, "Julian Reschke" <[email-masked]> wrote: > > >> On 2016-02-22 18:27, Heather Flanagan (RFC Series Editor) wrote:
>>> Taking a given XML file that transforms into particular HTML and >>>
PDF formats (as described in the requirements drafts), we want a >>>
page design for CSS and PDF that will take into account >>>
accessibility and follow a responsive design. The expected output >>> of
this RFP will be a single CSS file that will be embedded in >>> the
rendered HTML and PDF. Note that the HTML and PDF files must >>> be
rendered from the XML; the PDF will not be generated through >>> an HTML
transformation. >>> >>> Is that clearer/more accurate? >> >> Since when
do we have a requirement that the PDF can not be >> generated via the
HTML version? > > Yeah, I was going to jump on that one also. That last
sentence needs > to be struck; it's an implementation detail on how the
PDF generation > should be handled and does not belong in this
statement. Perhaps the > best method of generating the PDF is doing a
transformation on the > HTML and perhaps it is not. For the purposes
here, we don't care. >

I am not sure I agree. This particular implementation detail will signal
a potentially significant amount of work. If a bidder comes in with the
assumption that they will create the PDF from the HTML, and I expect it
from the XML, that might be a problem and an issue with the vendor.

-Heather

---

From: Robert Sparks <[email-masked]>
Date: Mon, 22 Feb 2016 15:41:53 -0600

On 2/22/16 3:33 PM, Heather Flanagan (RFC Series Editor) wrote:
> > On 2/22/16, 1:27 PM, "Julian Reschke"<[email-masked]> wrote: > > >> On 2016-02-22 18:27, Heather 
> Flanagan (RFC Series Editor) wrote: >>> Taking a given XML file that 
> transforms into particular HTML and >>> PDF formats (as described in 
> the requirements drafts), we want a >>> page design for CSS and PDF 
> that will take into account >>> accessibility and follow a responsive 
> design. The expected output >>> of this RFP will be a single CSS file 
> that will be embedded in >>> the rendered HTML and PDF. Note that the 
> HTML and PDF files must >>> be rendered from the XML; the PDF will not 
> be generated through >>> an HTML transformation. >>> >>> Is that 
> clearer/more accurate? >> >> Since when do we have a requirement that 
> the PDF can not be >> generated via the HTML version? > > Yeah, I was 
> going to jump on that one also. That last sentence needs > to be 
> struck; it's an implementation detail on how the PDF generation > 
> should be handled and does not belong in this statement. Perhaps the > 
> best method of generating the PDF is doing a transformation on the > 
> HTML and perhaps it is not. For the purposes here, we don't care. >
>
> I am not sure I agree. This particular implementation detail will 
> signal a potentially significant amount of work. If a bidder comes in 
> with the assumption that they will create the PDF from the HTML, and I 
> expect it from the XML, that might be a problem and an issue with the 
> vendor.
I don't see what kind of potential issue with the vendor you're seeing.

I agree that this is an implementation detail, and we should look at the 
proposed implementations.
I understand you want a clean path from XML to PDF and that you don't 
want to pre-constrain it to go through HTML first. I also don't think 
you should pre-constrain it to _not_ go through HTML first.

---

From: Bob Hinden <[email-masked]>
Date: Mon, 22 Feb 2016 13:52:41 -0800

Heather,

> 
> > Yeah, I was going to jump on that one also. That last sentence needs
> > to be struck; it's an implementation detail on how the PDF generation
> > should be handled and does not belong in this statement. Perhaps the
> > best method of generating the PDF is doing a transformation on the
> > HTML and perhaps it is not. For the purposes here, we don't care.
> >
> 
> I am not sure I agree. This particular implementation detail will signal a potentially significant amount of work. If a bidder comes in with the assumption that they will create the PDF from the HTML, and I expect it from the XML, that might be a problem and an issue with the vendor.
> 

Is the issue that while PDF could be produced from XML or HTML, we don’t want to have to support both ways of doing it and to have to deal with any differences in the PDFs.

Bob

---

From: Julian Reschke <[email-masked]>
Date: Mon, 22 Feb 2016 23:02:10 +0100

> Yeah, I was going to jump on that one also. That last sentence needs to be struck; it's an implementation detail on how the PDF generation should be handled and does not belong in this statement. P…

Absolutely.

In particular, it should be a goal to have as much code in common as 
possible for both formats.

Best regards, Julian

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 22 Feb 2016 22:29:12 +0000

I agree with Julian.  Doing a completely new implementation of the PDF generation from scratch without reusing any of the HTML rendering bits is going to both be REALLY complicated as well as consistently out of alignment with the HTML version.  It is quite important to me that the HTML (which I believe most people will use in practice for implementation) and the PDF (which we're planning on giving to lawyers) be as similar as possible, including whatever interesting CSS we come up with for HTML.  I don't want them "pretty close, because I was looking at the HTML trying to force my PDF tools to do that".

If we *insist* on separate implementations, I want to ensure that we have budgeted for ongoing support to keep everything aligned.  However, if I was the person bidding on the project, and know that we've got a bias toward complexity, it might be tempting to skew the bid toward milking the support contract for years to come.

I suggest we leave the implementation detail out, and judge the responses on the chance for success of their suggested approach.

-- 
Joe Hildebrand

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Mon, 22 Feb 2016 15:17:14 -0800

> I suggest we leave the implementation detail out, and judge the responses on the chance for success of their suggested approach.

Joe and I took a few minutes of voice time to sort out my issues on this
topic.  Here are the requirements we agreed to:

The PDF and HTML must look as similar as possible
The PDF and HTML must stay in sync going forward
All of the PDF features that have been called out in the PDF draft need
to be in place in the CSS (for example, we need to make sure that index
and ToC are in there correctly)

I can live with this, and it's that last one that I was giving me
particular difficulty as I was trying to preserve the transformation to
be as good a PDF as we require. Does anyone have any concerns that those
requirements go into the SoW as stated?

-Heather

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 22 Feb 2016 23:19:12 +0000

That looks right to me.  I wonder if we need to get one or more of those requirements into the other docs?  For example, the CSS that I'm using for HTML is much more useful on-screen than it would be in the more static world of PDF.

-- 
Joe Hildebrand

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Tue, 23 Feb 2016 14:05:15 +0000

>requirements go into the SoW as stated?

The exceptions to the "as similar as possible to HTML" are laid out in the PDF draft, mostly in section 3.1.9. In addition to the ToC and index tweaks, they include removing pilcrows, adding running headers and footers, and page number hyperlinks/tags.

I'm fine with what you wrote.

	Tony

---

From: Ray Pelletier <[email-masked]>
Date: Tue, 23 Feb 2016 09:55:20 -0500

Heather,

Will the programming support the use of the Streams Logos on the HTML and 
PDF versions of the RFC?

Ray

> On Feb 23, 2016, at 9:05 AM, HANSEN, TONY L <[email-masked]> wrote:
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Feb 2016 18:04:33 +0100

On 2016-02-23 15:05, HANSEN, TONY L wrote:
> ...

- pilcrows should only become visible when hovering over the object, so 
they wouldn't affect this

- running headers and footers should be in the HTML as well (via CSS 
paged media), if they aren't they should be added in the HTML draft

Best regards, Julian

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Sun, 28 Feb 2016 10:40:46 -0800

> PDF. I think this should be more about clean process than tools.

A revised draft of the SoW is attached. I've tried to offer more
background, and included the list of requirements as discussed on the
list earlier this month.

-Heather

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 29 Feb 2016 03:55:26 +0000

>background, and included the list of requirements as discussed on the

Thank you Heather. It looks much better.

Nits will be sent separately.

	Tony