Slashdot Mirror
Printing XML: Why CSS Is Better than XSL
An anonymous contributor writes "XML.com just published an article titled Printing XML: Why CSS Is Better than XSL written by Michael Day and Håkon Wium Lie. The article was written in response to Norm Walsh's claim that CSS will never fix [printing]. Did you hear me? CSS will never fix it!. The article shows how a 100-line CSS style sheet gives you the same formatted version of W3C's Webarch as the 1000-line XSL style sheet by using Prince."
If you check them out, at least one savings in the CSS is that it hard-codes the page size for a single size.
If you look at the XSL, it selects different text sizes for different page sizes.
Thus I would have to say - have they tried printing both examples using different page sizes? Because I am pretty sure the CSS version will be a postage stamp in the middle of an A0 page.
Also from quick examination it looked like the XSL is more flexible in other ways, you can pass in all sorts of parameteres like margins.
Basically - sure the XSL is longer, but also more flexible in terms of use. Since you are only going to write it once (that is unless you want multiple page sizes in which case you are going to have many CSS files) what does it matter if there is a little code-size increase?
Furthermore the XSL could itself be transformed in various interesting ways for special modifications, a task harder to do with CSS. And you could include things like the paper-size->font-size mapping in seperate files to keep the size down and the file more readable (though I find the XSL perfectly readable - after having used XSL for a while, admittedly!).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Are there any apps that fully support CSS to the last detail? I often see all too often "can't render CSS".
Is it like SVG where there is/was no single 100% compliant renderer, yet the w3c had something magical to make their few sample screenshots?
Its certainly ironic when I see one of the best "built in" SVG parsers, present not on a computer, but on a Mobile Phone (SonyEricsson S700i), yet all the viewers i see in IE seem to have some faults here or there.
Have a nice day!
Lyx... http://www.lyx.org/ is my favoite.
It's the reason I switched to linux.
It's the reson I bought an iBook.
It's the reson I passed some tough courses.
Down with WYSIWYG!
-=fshalor
Caveat: I don't like XSL. It's too verbose and even simple logic steps tend to take a while to implement. I want a better solution. However...
So while both have their uses, CSS in combination with Javascript (or any scripting language for that matter) has far more functionality and flexibility.
In presenting documents with a web browser, yes, I agree. But traditionally, XSL was a server side headless operation for producing print quality documents.
Where is the commandline CSS and javascript engine? In the article they mentioned Prince, but that's XML+CSS and not free software. Sure there's a perl API to access spidermonkey, the mozilla javascipt engine. There's Apache's Batik CSS engine. Is there an integrated solution out there in the OSS realm? Not when I looked a couple years ago, when I choose to implement a reporting engine in XSL.
Therefore it still depends on the task you are doing. CSS+Javascript tackles a narrower problem set than XSL. Does it do it well? Yes, but your assertation is still apples and oranges. Have you even used both?
Why, o why must the sky fall when I've learned to fly?
In retrospect, my comments about CSS and printing seem snarky and sound like hubris. My apologies. I'll take a closer look at the XML.com article and try to post a more reasoned reply. Not that I expect that'll get slashdotted :-).
--norm
The article boils down to: XSL (FO) is harder to use than CSS, so CSS r0xx0r5!
Actually, the article boils down to: CSS is easier to use by those who must lay out both the electronic and printed page, so CSS r0xx0r5.
This is very true since those who spend time designing and laying out readable pages are generally NOT programmers and may not have the desire or aptitude to decipher/code hundreds of lines of XSL prose.
Basically, it's a matter of using the right tool for the right job. The article fully admits that XSL is much more powerful than CSS and can certainly overcome CSS's deficiencies, but the overall simplicity of CSS might be more suitable for this particular job.
Well, except for the fact that TeX is about three million years behind the state of the art in typography.
And if you think QuarkXPress is worth using, no offense, but you're about three million years behind the state of the art, too. It's InDesign or nothing today.
You do realize that InDesign's typesetting engine is based on TeX, don't you?
Ahh, the delicious irony.
Free Mac Mini. Yes, I'm
He is not only using a lot of CSS3 in his examples, but he is using things that does not even look to become parts of CSS3. For instance the content:target-counter was in a working draft of the css3 paged module, but have been withdrawn from the latest version.
First off, it's Quark XPress.
Second, it's only recently that Quark has been able to use anything other than a lousy bitmap preview for placed art. The majority of XPress users never upgraded from v4, and so get cruddy bitmaps (unless they license an XTension which then litters their HD w/ preview files) and a weird shift from nice anti-aliased type to blocky bitmaps when editing text at certain sizes).
Thirdly, Quark is incredibly limited in terms of the glyphs which it can access, so What You See Is All You're Going to Get, and you ain't gonna automatically get spiffy ligatures in it from OpenType and AAT fonts (manually inserting ligatures pulled in from ``Expert fonts'' is _so_ 20th century (and something I found tedious immediately after purchasing Adobe Garamond back in 1989) and fixing them by search-replacing in XPress Tags is a poor solution).
And lastly, Quark still has a brain-dead, one-line at at time H&J algorithm --- at least Adobe had the sense to make use of TeX's algorithm when they developed InDesign.
William
Sphinx of black quartz, judge my vow.
XeTeX is very interesting and a good project. However, it is extremely limited to the Macintosh due to being hardwired to the OS X font engine (making it somewhat useless to most of the world). Also, it suffers from the TeX problem that there is no consistent approach to development at all that would encompass larger parts of the toolchain beyond the mere engine. If you need Unicode and additional tools, even similar ones like BibTeX, you'll quickly find out that they are either 8-bit, that the non-8-bit versions are quick undocumented hacks done by persons who are now unavailable, or that it's hell of a lot of work to get sensible output. It's possible, but the way there is long and thorny, and it feel like being in the 1980's again. While the TeX world is certainly better off with XeTeX than without it, it is really quite a limited solution.
TeX is a shining example of how not to do a large open-source software project; the complete lack of coordination has made development somewhat difficult and frustrating. If you look at those parts of TeX where coordination is taking place (ConTeXt, for example), it's evident that it could have been different. With LaTeX, the only reasons that keep it alive are inertia, the relatively large user base and the somewhat futile development efforts of some uncompromising developers (whom I admire for their commitment) that are struggling against fifteen years of uncoordinated development. Myself, I'm using ConTeXt now, it simply has less compatibility problems, is less frustrating and gives better layout.
As a state gets corrupt, its laws multiply; the most corrupt states have the most numerous laws. (Tacitus, Annales 3:27)