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

["Joe Hildebrand (jhildebr)" <[e-mail]>]

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







On 2/22/16, 3:02 PM, "TOOLS-DEVELOPMENT on behalf of Julian Reschke" <[e-mail] on behalf of [e-mail]> wrote:

>On 2016-02-22 21:15, HANSEN, TONY L wrote:
>> On 2/22/16, 1:27 PM, "Julian Reschke" <[e-mail]> 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.
>
>Absolutely.
>
>In particular, it should be a goal to have as much code in common as 
>possible for both formats.
>
>Best regards, Julian
>
>_______________________________________________
>TOOLS-DEVELOPMENT mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tools-development