FWIW, the WebKit guys are also keen on using PDF, generated from the HTML+CSS+whatever via a standard DOM method.
But of course PDF only takes care of the document data transfer - we still need job ticketing and page properties to generate the right document data, and then to get the right hardcopy output...
On 2013-08-21, at 6:28 PM, Paul Tykodi <ptykodi at tykodi.com> wrote:
> Hi,
>> In some of the limited discussion about the workshop on the CSS mailing
> list, which is how I learned about the upcoming workshop back in July, the
> Adobe representative to the CSS workgroup mentioned that they felt PDF was
> the best option to consider as a first step towards bringing something into
> being quickly that would start the W3C down the road towards the long term
> publishing goals.
>> I think their opinion aligns well with Bill's point a) below.
>> Best Regards,
>> /Paul
> --
> Paul Tykodi
> Principal Consultant
> TCS - Tykodi Consulting Services LLC
>> Tel/Fax: 603-343-1820
> Mobile: 603-866-0712
> E-mail: ptykodi at tykodi.com> WWW: http://www.tykodi.com>> -----Original Message-----
> From: sm3-bounces at pwg.org [mailto:sm3-bounces at pwg.org] On Behalf Of William
> A Wagner
> Sent: Wednesday, August 21, 2013 5:49 PM
> To: 'Semantic Model 3.0 Workgroup discussion list'
> Subject: Re: [SM3] Informal minutes of W3C Workshop conference call
>> Comments and questions for Thursday's call. I preface some of these
> statements by affirming that printing from the Web is not in the area of my
> expertise, so that some of my questions, indeed some of my comments, may be
> way off-base. In such case, I request (gentle) correction and redirection.
>>>> 1. I understand that, in France, everyone is on vacation for the month of
> August. That seems to be the case with the W3C workshop personnel since the
> announcement of Agenda, posting of position papers and, it appears, method
> of registering the restricted number of attendees has not yet occurred (so
> far as I can see). Information from Paul is that the agenda "has very few
> position papers being presented, but some panels and open discussion" I do
> not expect that the PWG will need to present its position paper, largely
> because we propose an important component of any overall solution to the
> "The Challenge" (namely a set of elements for defining user processing
> intent in printing products) rather than a specific solution itself.
> However, I echo a previously stated suggestion that it would be beneficial
> to create and post a concise statement of the purpose and importance of the
> Semantic Model and of the PWG Job Ticket that emerges from that model.
> Indeed, I suggest that, in this period of realistically considering out
> projects, such a statement would be of interest to much of the membership
> as well.
>> 2. Referring to the information on the W3C workshop page:
>> "Designers are finding HTML and CSS incomplete when compared
> to XML and XSL-FO, and that in turn is limiting compared to professional
> interactive page design programs.", questions and comments are:
>> a) Although I understand their publishing-based origin in SGML, one
> thinks of HTML (and XML) being used in web pages. I expect that a
> stand-alone or web-based word processor could provide a document coded in
> HTML with CSS reflecting formatting, or in XML with XSL providing
> formatting, but what is the advantage over PDF or XPS in which many of the
> features they ask for already exist? To what extent is HTML or XML currently
> in use for commercial publishing of printed material?
>> b) The PWG has some history with CSS-Print (which was intended to be
> used with XHTML-Print). Presumably XHTML-Print was to describe a document's
> content and structure; CSS-Print was to describe processing and presumably
> could be changed without affecting content. Of course, processing
> instructions often affect formatting, so a clear distinction is not
> possible. It appears that XSL (or XSL-FO) serves a function for XLM coded
> documents similar to what CSS serve for HTML coded documents.
>> c) A reasonable PWG position would not limit the PWG contribution to
> defining a set of print processing elements in CSS, but also for XSL-FO (or
> whatever other content language/formatting pair are proposed. The problem is
> when existing elements in those languages do not align with PWG PJT
> elements. Finding those may not be feasible in available time.
>> 3. Topics (and presumably panels, sessions, etc) identified that may be of
> interest to PWG for contribution and/or understanding are:
>> . Formatting to print using CSS
>> . Print on demand: color management, ink control [?], specifying
> media, binding, trimming, finishing, and perhaps
>> . Multiple output formats: are CSS media queries enough? What about
> alternate content, image replacement, subsetting?
>> (I am surprised there is no XSL-FO session)
>> 1. Are there any others?
>> 2. What is meant by "subsetting"?
>> 3. Are we interested (perhaps particularly for Print on Demand) in
> proposing something other than XML or HTML as the content language, or an
> alternate system
>> 4. If, as the page suggests, "Customers want to buy a printed book, or
> to go to a kiosk and get an eBook printed and have the same quality.", how
> do we propose print process control with documents in the various E-book
> formats?
>> 5. Do we have any suggestions on 'Rights Tracking"?
>> Thanks for plowing though my (partial) dump on this. I think we do need to
> generate and post something that can be referred to as truly representing
> the PWG position. (We might clean up the posted PJT candidate spec too, if
> we want to refer to it.a few little things like status and line numbering).
> I should better understand where this W3C group is coming from, both with
> regard to current in-place print publishing technology and vision for the
> future.
>> Bill Wagner
>>>>>> -----Original Message-----
> From: sm3-bounces at pwg.org [mailto:sm3-bounces at pwg.org] On Behalf Of Michael
> Sweet
> Sent: Thursday, August 15, 2013 3:02 PM
> To: sm3 at pwg.org> Subject: [SM3] Informal minutes of W3C Workshop conference call
>>>> All,
>>>> Here are my informal minutes of today's W3C Workshop conference call. We
> will have another call next Thursday, August 22, 2013 at 2pm ET.
>>>>>> W3C Workshop Conference Call
>> August 15, 2013 at 2pm ET / 11am PT
>>>> Attendees:
>>>> Nancy Chen
>> Daniel Manchala (Xerox)
>> Glen Petrie (Epson)
>> Mike Sweet (Apple)
>> Paul Tykodi (TCS)
>> Bill Wagner (TIC)
>> Rick Yardumian (Canon)
>>>> Notes:
>>>> . Paul: No updates on W3C site yet
>> . Don't know whether we will be presenting
>> . Don't have access to other position papers
>> . Paul got previous notification at 5pm ET
>> . Mike probably won't be able to attend
>> . Bill can and will make arrangements
>> . Proposed presentation:
>> . CSS properties corresponding to SM Job Ticket elements
>> . Review old CSS Print stuff
>> . copies, finishings, media, sides
>> . Proposal: Extend CSS 2.1 Print to office and commercial
> printing
>> . Also review CSS media queries
>> . for printer capabilities (color mode, duplex,
> staple, media, etc.)
>> . Q: Are we doing production printing or ???
>> . A: Certainly light production, print-on-demand,
> book printing, etc.
>> . Q: CSS3 Page Media Module: should we upsell this?
>> . A: Yes, seems important for printing, also useful
> for screen content with headers and footers (very common on web sites today
> using "position: fixed" content.)
>> . Intertwined with job ticket - media and sides,
> staple? might be used in media queries to control paper margins, front
> side/back side, etc.
>> . Alternative CSS
>> . Single CSS property listing job tickets
>> . PWG PJT a required/recommended format?
>> . JDF optional
>> . Maybe still have a few properties to describe the
> important aspects of the job ticket (media, sides, finishings, copies)
>> . Show implementations of CSS Print
>> . What is implemented by the major browsers
>> . What third-party software is available?
>> . Show PWG PJT coverage vs. CSS
>> . Add slide showing level of effort required to
> update CSS 2.1 Print
>> . Most browsers support CSS Print properties/media
> queries
>> . THEAD, position: fixed content support
> lagging
>> . Adding CSS properties should not be a big effort,
> much harder to get rendering changes done
>> . Job Ticket Mapping experience
>> . PPD, MSPS, JDF, AFP, etc.
>> . Why you need standard job tickets/elements
>> . Print Experience/DOM
>> . Selecting a printer
>> . Getting printer capabilities
>> . Standard UI capabilities?
>> . to specify job ticket elements?
>> . but that has been a circular argument for many
> years?
>> . maybe because they are not
> printing-literate?
>> . based on the list of CSS properties we come
> up with?
>> . Also restrictions? Maybe mention but we have no
> solutions...
>> . no print (publications)
>> . no save
>> . only 1 copy (coupons, shipping labels)
>> . always N copies
>> . Presentation length:
>> . Presumably short
>> . Next steps:
>> . Wait for word from W3C
>> . Also review existing position papers
>> . If we present, include backup slides for specific
> details
>> . If we don't present, still do a slide deck we can refer
> to...
>> _________________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>> _______________________________________________
>> sm3 mailing list
>> <mailto:sm3 at pwg.org> sm3 at pwg.org>> <https://www.pwg.org/mailman/listinfo/sm3>
>https://www.pwg.org/mailman/listinfo/sm3>> _______________________________________________
> sm3 mailing list
>sm3 at pwg.org>https://www.pwg.org/mailman/listinfo/sm3>> _______________________________________________
> sm3 mailing list
>sm3 at pwg.org>https://www.pwg.org/mailman/listinfo/sm3
_____________
Michael Sweet