51 Very interesting article

I really like this demonstration of the developing capabilities of CSS. As I see it, there are situations where you want to use CSS + XHTML for multiple presentations ( views ), as when you want to print content that’s mainly aimed at the web browser.

The single source idea is certainly a good one, and solutions like Apache Cocoon uses XSLT for transforming an originating XML document for structure to produce XHTML for the browser or mobile platform and XSL-FO for printing purposes. It can use FOP ( Formatting Objects Processor ) to get PDF for printing.

The XSLT “having Style in it” is a bit confusing, but as you know ( HÃ¥kon was only expert from the start :-), XSL was introduced as “a style sheet for XML/XHTML”, to separate content from presentation. This was taken over by CSS and XSL took on another route. Modern browsers can take whatever domain specific XML document and render it using CSS styles.

XSLT is the XSL for Transformation, using an XSLT engine to transform one document into another, possibility reordering or filtering out parts of the original content.

XSL-FO became the styling part of the XSL standards, better used for printing purposes.

I completely agree that XSL-FO wouldn’t be suitable for sending documents to a browser. Even if the browser could render the document, it’s far too verbose and not easily human readable, and View source has taught us so much.

XSL-FO is complicated, and the possibility to use XML/XHTML + CSS to render print quality documents are good news.

posted at 11:55 pm on December 4, 2005 by Bertil Gralvik

52 Great stuff!

The people who are slagging this approach are completely missing the point, IMO. For me, the good part is not so much the use of CSS to format the book, but the use of XHTML to mark it up. The printing back-end can be ripped out and replaced with whatever works for you — FO (yuck), groff, LaTeX — or load up the HTML in M$ Word or OpenOffice, apply a stylesheet, and print.

We can talk about DocBook until we’re blue in the face, but it’s such an incredibly complex DTD that most writers would give up before finishing the first chapter of the first document. DITA is a step in the right direction, but it’s probably still too complex for non-gearheads without a fair amount of motivation. Just about everyone knows enough XHTML to write a document, and there are plenty of tools — Free and commercial — that provide a pretty GUI for people who need it.

As long as writers have to associate XML with complex large-scale publishing systems with six-figure deployment costs and five-figure support costs, it will be “eXcellent, Maybe Later” outside of Fortune 100 companies. HTML brought on-line publishing to the masses through a simple syntax; now it can bring single-source on-line/paper/PDF publishing to the masses as well.

posted at 06:58 pm on December 6, 2005 by Larry Kollar

53 No Right Niche

Others have pointed out the advertizing. I would also point out that HÃ¥kon Wium Lie has been long known to be an XSL foe (pun intended), so his opinion on XSL should be taken with a grain of salt.

But now to Prince itself—

It seems like a good way of bringing web pages to print. Someone mentioned its applicability to the blog-streaming world. Prince can fill this niche well. But going from web to print has, up till now, been carried out by printing according to a print stylesheet, not downloading a PDF. What Prince has over, for instance, Firefox is that the latter doesn’t support the CSS page model properly. When browsers come up to that functionality, Prince will be out of job.

Mr Lie might answer that the niche isn’t web to casual print, it’s XHTML to books, with the XHTML not necessarily ever being hosted on a web server, and books like the kind we get from Framemaker or Quark. However, that’s a niche Prince, or more accurately an XHTML to PDF tool, can’t fill either. Maybe CSS is already up to the task of heavy formatting (and I doubt that), but XHTML isn’t up to the task of rich markup. XHTML is a limited tagset. You know it when you have to use span tags where in general XML you’d use an element. You know it because the new OpenDocument format for office applications didn’t duplicate XHTML, it was formulated with its own tagset, which is much bigger than that of XHTML. XHTML is suitable for the simplest books, but anything beyond that, like any random book you pick up in the college library, requires a more feature-rich markup language. XHTML for books could only be hobbyists’ fare, and maybe not even that, since hobbyists are far more likely to opt for WYSIWYG tools than textual stuff.

In short, I don’t see Boom finding its niche among any of the possibilities. It’s overkill for simple web to print, and underpowered for professional typesetting.

posted at 06:54 pm on December 9, 2005 by Alan Goodrich

54 Cool Idea

Great idea I will have to read the book to give a better review but excellent job on making it via this method.

posted at 07:13 am on December 12, 2005 by Ashley Bowers

55 OpenDocument: a missed opportunity

HÃ¥kon Wium Lie has been long known to be an XSL foe (pun intended)

:) It’s the «FO» part I have a problem with. Formatting objects don’t have any semantics and should therefore not be represented in XML. It’s just a bunch of font tags. Which is why I once wrote

I can understand why overworked undergraduates think FONT is cool, but I’m very disappointed when a group of highly skilled adults tell kids to stop playing, form a committee – and then come out with a set of supercharged FONT tags

Anyway, your main argument is not CSS vs. XSL-FO, it’s against the use of HTML as the basis for our markup. You write:

XHTML isn’t up to the task of rich markup. XHTML is a limited tagset.

Indeed, the tagset is limited, but HTML has a wonderful extension mechanism: the «class» attribute. Using the class attribute, you can convert any XML document into HTML and back — without losing information.

You know it because the new OpenDocument format for office applications didn’t duplicate XHTML, it was formulated with its own tagset, which is much bigger than that of XHTML.

I think this was a big mistake. By basing OpenDocument on HTML (much the same way Bert and I did Boom on HTML), the format would have had a huge installed base from the beginning: 1 billion browsers.

posted at 02:27 pm on December 12, 2005 by HÃ¥kon Wium Lie

56 XML/XSL is like XHTML/CSS, only with more capabili

Formatting objects don’t have any semantics and should therefore not be represented in XML.

Why not? In the letters that make up the initialism XML, I don’t see anything that stands for Semantics. XML is just a toolchest for building any markup language you wish, and one of those happens to be the page layout language called XSL-FO. And it isn’t “just a bunch of font tags� anymore than CSS is—I think we both know XSL-FO is to be generated from XSLT rather than written by hand, and when generated from an XSLT script it’s equivalent to a CSS stylesheet in separating content and presentation.

Indeed, the tagset is limited, but HTML has a wonderful extension mechanism: the «class» attribute. Using the class attribute, you can convert any XML document into HTML and back—without losing information.

Doesn’t the use of a kluge indicate the inappropriateness of the format? And, um, talking about semantics, are you aware that class attributes are style directives, containing no more semantics than I or B or TT tags? You’re like proposing the use of such constructs as divs with style attributes instead of H1/H2/H3 tags, which Ian Hixie complained about on his blog, but on steroids!

This isn’t the right tool for the job. Anyone who so much prefers CSS to XSL can use CSS to style XML, and that would be better. I shudder to the thought of using HTML, with kluges and all, for preparing a college grammar book. But even CSS isn’t wholly satisfactory—you’ve had to write an external script to generate the TOC, while you can do it with XSLT, and then style with FO in the same gulp. Looking at it that way, the XSL approach could be said to be more deskilling than the HTML/CSS one.

I think this was a big mistake. By basing OpenDocument on HTML (much the same way Bert and I did Boom on HTML), the format would have had a huge installed base from the beginning: 1 billion browsers.

But OpenDocument is for office applications, not for browsers. You seem to be very Web-centric. Additionally, even if ODF were based on HTML, the type of HTML that office applications generate approaches the elegance of Frontpage’s output.

posted at 06:33 pm on December 14, 2005 by Alan Goodrich

57 Untitled

Personaly I am more familiar with css than with Microsoft word. Now I can type my esseys in Dreamweaver :)

posted at 01:43 am on December 15, 2005 by Marko Petkovic

58 Everything old is new again

How novel, using a language based on SGML (Standardised Genral Markup Language) to make a printer paint a page instead of a browser.

Ah yes – my first program documentation (1983) was generated using IBM DCF on a 3090 mainframe. And our documents had strange markup like <h1>, etc etc – and it had ‘stylesheets’ to add ornamentation (other than bold or underline) etc etc when IBM released its first advanced function printers (3800-3 and 3820s).

IIRCit was a superset(or was that a subset?) of SGML. It even generated tocs, indexes etc etc

Amazing its still around … http://www.printers.ibm.com/internet/wwsites.nsf/vwwebpublished/dcfhome_z_ww

Kim Mihaly

posted at 05:06 am on December 16, 2005 by Kim Mihaly

59 Just give me...

Just give me the needed CSS print functionality, and a web browser that supports it. Then all I’ll need to do is File -> Print to Postscript/PDF. Even better:

% firefox —print http://www.alistapart.com/print/me —output ala.pdf

posted at 04:21 pm on December 16, 2005 by James Earl

60 Printer-friendly, that's what would like to see

TeX is different thing. I wrote a number of papers, and even a whole book using it. These days I use XSL and produce PDF. This is XML based and more flexible. Still I personally like TeX much more. But PDF and TeX are about actually printing content in high quality.

The point of this article seems to be, that using XHTML/CSS can be used to publish a real book. It’s a prove-of-concept by the persons who created CSS – and that’s nice.

Printing web-pages is always a pain. And I hope that’s what this is about. Printer-friendly pages are never really what the claim to be. XHTM/CSS can not compete with PDF. But it can complement it. And make it easier to import web-pages into publishing systems.

posted at 03:06 am on January 3, 2006 by Martin Benkert