41 truly professional

I don’t think that at this point CSS is mature enough to fulfil a truly professional role in book-printing.

Perhaps not. Certainly, one can point to features that are missing (e.g. automatic line numbers). However, most books don’t use any such advanced features. I’d estimate that CSS and Prince could produce 90% of all books published in Latin scripts. I’m happy to leave the remaining 10% to a guy and his Quark.

posted at 06:13 pm on December 1, 2005 by Håkon Wium Lie

42 Print PDF vs Screen PDF

The pages have no corner trims and no bleed; the black text separates into CMYK leaving the black at only 90%. We would not be happy to go to press with this file

Sure. The sample file is optimized for screen use rather than print. Thanks for your partial list of requirements for PDF Prince — feel free to email me your complete list :-)

posted at 06:16 pm on December 1, 2005 by Håkon Wium Lie

43 Converting formats vs. single-sourcing

In documentation management and production, we’ve been trying to get away from the conversion game for years. Tools that convert one format of document or text into another abound. If you’re familiar with help authoring tools, think Doc-to-Help, for example.

Although you’re using style sheets and proper markup, you’re still trying to convert one format (HTML) into another (Print/PDF). In the long run, this is not the way to go. And your PDF will suffer as a result. Try to build bookmarks from that PDF …

True single-sourcing demands that content and format be separated completely. And there are tools out there that do that splendidly, where content is stored in unformatted data blocks and published at run-time using CSS (for HTML/XHTML/XML) or MS Word DOT templates for print. Incidentally, an MS Word DOT file is to MS Word precisely what CSS is to HTML. It only controls a lot more (like headers and footers) a lot better for print – because that’s what it was designed to do.

posted at 01:03 pm on December 2, 2005 by Maritza van den Heuvel

44 converting formats vs. single-sourcing

Although you’re using style sheets and proper markup, you’re still trying to convert one format (HTML) into another (Print/PDF). In the long run, this is not the way to go.

In general, I agree with your views that single source is good and document conversion is bad. This is why CSS has the concept of media types; the same source document (in, say, HTML) should be usable on all sorts of devices. The sample document has style sheets for print and screen and support for other media types can easily be added if you want more control of the final presentation.

The only reason for converting our files to PDF is to send it to the printer. They only accept PDF files, and, as such, PDF works quite well. Until printers accept HTML/CSS natively, using PDF is good solution which doesn’t change the fact that we have a single source.

posted at 02:25 pm on December 2, 2005 by Håkon Wium Lie

45 This Article is an Adverstisement

I have been trying to solve this web-to-print quandary for a project over the past month, and after trying to use RPDF with Ruby on Rails, I am retreating to a simply printable, CSS-styled web page.

So, this article really got me excited! Then after reading it and hopping over to princexml.com to get Prince, I feel like this article is an advert for the $350 Prince software.

It bums me out to read an article on my old favorite ALA, which is all about standards, open-ness & accessibility on the web, only to find out that I have to buy expensive proprietary software to put the knowledge to use.

Håkon, I really appreciate you for all of the standards goodness you bring to us, but this is a TOTAL BUMMER.

posted at 06:33 pm on December 2, 2005 by Mars Hall

46 Untitled

I feel like this article is an advert for the $350 Prince software.

This article is about open standards, namely HTML and CSS. At the time of writing, Prince is the only software that can process our code. Not referring to it would have been negligent. We hope other software will start supporting our code — this was one of the reasons for writing the article in the first place.

Did you notice that you can download and use a fully functional demo version of Prince for free? You can also publish academic works without buying a license. And, if you compare Prince with other standards-based software that produces printed materials (some XSL tools come to mind), Prince is a bargain.

posted at 08:16 am on December 3, 2005 by Håkon Wium Lie

47 When the CSS is insufficient for styling of XML co

Håkon, I think that you will agree with me, that if you want to present some content stored in XML to user, you often need to do two things: (1) transform your document and (2) assign visual characteristic to individual components of the document.

During transformation you can do things like building a table of contents, numbering chapters and figures or adding some fixed content like a word “Figure” in the front of each figure name. CSS is able to do some basic modification to a document like adding figure numbers. More complex transformations like building of ToC must be created by something more powerful. My tool of choice for this task will be XSLT, but you can use any language which is able to read, manipulate and store XML document. You told me previously, that ToC for your book was created with some script.

After (well, yes in CSS this is not after but at the same time) document is transformed, visual characteristics like fonts, colors, spacing, margins, etc. are applied to elements in the source document. If I understand correctly your position, you are advocating CSS over XSL-FO here because CSS syntax is easier and you are assigning properties directly to elements from source XML document. I think that I can agree with your position here… but only as long you are using CSS with some general, document oriented XML format like XHTML or DocBook. Let me explain.

If you have book in XHTML you can easily add ToC into this document, because XHTML contains general markup for paragraphs and lists and ToC is nothing else then list of chapter titles with links.

But you can’t do this with more specific XML formats. For example imagine a simple invoice:

<invoice> … invoice metadata here … <item> <description>Pilsner Beer</description> <qty>6</qty> <unitPrice>1.69</unitPrice> </item> <item> <description>Sausage</description> <qty>3</qty> <unitPrice>0.59</unitPrice> </item>
</invoice>

You probably would present it as a table.

During document transformation you need add new row with table header, new column with subtotals and finally new row for total. But XML schema of invoice doesn’t allow you to specify such informations.

This example clearly shows that there are classes of documents which must be transformed to some more general markup prior assignment of visual characteristics. XSL-FO is a such intermediate markup. I can imagine that you can also use XHTML+CSS for this purpose. But you are loosing big advantage of CSS then — your CSS rules are no more working against original markup, but against intermediate XHTML code.

So my conclusion from this is: CSS can be used for formatting documents that are written in some very generic, free text oriented vocabulary like XHTML. For more rigidly structured XML formats CSS can be used, but it is no longer easier to use then XSL-FO.

The difference in complexity is mainly caused by fact that all XHTML elements have some default formatting behaviour. Once you are not using XHTML, there is no big difference between:

CSS:

… { display: block; color: red; font-weight: bold; }

and XSL-FO:

<fo:block color=“red” font-weigh=“bold”>…</fo:block>

It is just matter of syntax, because basic formatting model of XSL-FO and CSS is very similar and many XSL-FO properties were directly taken from CSS.

But if there is a way how to handle my invoice example using only CSS without introducing another intermediate format, I would like to know.

Jirka

posted at 12:45 pm on December 3, 2005 by Jirka Kosek

48 Price of XSL-FO formatting engines

And, if you compare Prince with other standards-based software that produces printed materials (some XSL tools come to mind), Prince is a bargain.

I use XSL-FO toolchain for print production, namely XEP from RenderX. It’s even little bit cheaper then Prince and feature list is more complex IMHO. For example hyphenation is done directly with XEP. Hyphentation patterns are weighted, because some places inside word are more appropriate as hyphenation point. This is something you can’t acheive with soft-hyphens placed into document. Other XSL-FO implementations offer similar functionality for similar price.

But it is good to have more competition on the XML formatting market.

posted at 12:58 pm on December 3, 2005 by Jirka Kosek

49 Generic XML shouldn't cross the wire

If I understand correctly your position, you are advocating CSS over XSL-FO here because CSS syntax is easier and you are assigning properties directly to elements from source XML document. I think that I can agree with your position here… but only as long you are using CSS with some general, document oriented XML format like XHTML or DocBook.

Yes, this is an important part of the argument. CSS is well suited for structured document formats where the content comes roughly in the order of presentation. I believe content should be in this near-presentation state when it “crosses the wire”. Styling should be applied as close to the reader as possible, i.e. in the client.

The other argument for using CSS in printing is that one can reuse many of the CSS style sheets written for the web.

This example clearly shows that there are classes of documents which must be transformed to some more general markup prior assignment of visual characteristics.

I agree completely. And CSS hasn’t been designed for that purpose. XSLT has, and is perfectly fine to use. It’s Turing-complete and can perform the computations needed to calculate your columns. My only problem with XSLT is that it has “Style” in its name.

You told me previously, that ToC for your book was created with some script.

Yes, we use Bert Bos’ multitoc to generate a TOC. There have been proposals for how to handle this in CSS, but it’s probably too much of a transformation thing to make it into the CSS standards.

XSL-FO is a such intermediate markup. I can imagine that you can also use XHTML+CSS for this purpose. But you are loosing big advantage of CSS then—your CSS rules are no more working against original markup, but against intermediate XHTML code.

I don’t see any problem with working against ‘intermediate code’. I think the XHTML code is what you should offer on the web since it uses well-known semantics. Your invoice example uses tag names not universally known. That’s fine as an internal format, but shouldn’t be published on the web. Also, I don’t think XSL-FO should be published on the web — but that’s a different debate :-)

posted at 06:26 pm on December 3, 2005 by Håkon Wium Lie

50 Transparency

Does anyone know how to set a background color to have alpha transparency using CSS? I know this isn’t supported yet until CSS 3.0, but I believe some browsers already support the feature.

posted at 06:40 am on December 4, 2005 by Anonymous Blogger