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."
I agree. CSS is definitely better... but when you have to rely upon IE to update itself to the latest standard (much less a standard that is 5 years old) it becomes a bit tedious.
Frankly, I think the W3C should act like supreme overlord and take a bullwhip to all browser developers who can't stay up to standard.
I can just see Bill Gates bent over and bare assed in a W3C hazing ritual saying 'Thank you sir! May I have another?'
This is my sig. There are many like it but this one is mine.
This wasn't inspired by a post on Daniel Glazman's blog was it?
Prince...
Nooo! not the 80's again. argh!
Free for any purpose eh? This will go well for the interface to my baby mulching machine.
A series of point-counterpoint covering a bunch of things that everyone else consider irrelevancies.
Don't these people have any actual work to do?
Is XML with CSS better than TeX, or Postscript for that matter? Can it be? I have never seen a high quality print from anything other than *TeX, and that includes XML/XHTML/HTML, so I figured out that (XHT|HT|X)ML is not a typesetting system. Is that not the case?
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
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
From TFA:
More recently, a W3C Candidate Recommendation (called CSS3 Paged Media Module) added functionality to describe headers, footers, and more...
The big difference is that XSL provides the tools to perform this transformation - from XHTML to a printable layout - without needing to change the standard itself. The same goes for the argument made about page sizes, which are built into the latest CSS and which have to be handled manually with XSL.
Now, once you have wide support for the latest CSS (and who knows how long that will take), I would wholeheartedly agree that it would be a better choice for printing as shown here. The fact of the matter seems to be that they're comparing what you can do today, with a little work, using XSL transforms, to what you may be able to do tomorrow with a proposed dedicated language. I'd be pretty surprised if the latter couldn't do what its designed to do better than a general purpose language.
At least, that's the way I see it. So, there's some good stuff coming down the pipe with CSS. That's worth knowing about. But until it has wide support, there's XSLT. And that's worth knowing about as well, and a damn sight more useful - for now.
You're special forces then? That's great! I just love your olympics!
Does XSL suffer the same cross-browser incompatibilities? This I don't know, and while I love CSS, if XSL was better at cross-browser homogenity(sic?) I could see that being a big feature.
As a previous poster noted, though, a better solution would be for Microsoft to fix IE so it supported the wc3 recommendations....
philcrissman.com.
As the old saying goes ... those who do not understand TeX are doomed to continually re-invent it ... badly.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
Except perhaps having your flesh ripped off with pliers. That's pretty sucky. But honestly XSL is a piece of garbage. Pour gasoline over it and toss a match on it.
Forgot to edit that out before I posted - the size selected is relaly a paper size, which the CSS already knows about. But the point abou tthat value remaining hard-coded in the CSS remains.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The same argument could be applied to RDBMS: "Stored Procs are harder to use, so move the logic into the PHP code!!!" or Languages: "Pointers are hard to use, so VB.NET r0xx0rs over C!!!!"
My experience with the whole mess is that, yes, XSL-FO->PDF is harder to set up, but I get the same output every time. We tried to use CSS, and all it took to screw up the works was have somone set their browser margins or font size differently. Or use a non-CSS-compliant browser. We don't have control over the user's browser, but if we output to PDF, we have total control. Oh, but it is harder to use the latter, so forget it.
Q: How can you tell if a website was designed by a know-nothing monkey? A: "This site best viewed in 800x600, 1024x768, etc."
Yeah, right.
XSL is supposed to take in semantic content and transform it into presentation for the web. If you're going to make gross generalizations, one ought to compare XSL to templating engines. The two technologies are meant to work in tandem
XML + CSS?
There is a spark in every single flame bait point.
I've done a lot of stuff with XSL in the past, and know from experience that XSL does soffer some pretty annoying cross-browser unpleasnantness. That's why generally XSL is done on the server before the user sees it, though technically you could send the user an XML document and point them at a XSL file for transform. If you do anything tricky different browsers can break (even between different versions of IE, but then what else is new?)
Something like the XSL:FO described I would say would be more generally used to generate a PDF for the user that they would then print. I was at a seminar held by a guy who used it for a whole medical text book that was to be printed, and the reslts were fantastic. If you have a lot of data and need to produce a nice looking document XSL:FO (Formatting Objects) can work really well.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I mean /. topics usually contain several links, but that is just link overload...
Taco ignores all emails about his beloved $20K-a-year staff
Is that all they make? References? Really, it's not worth getting out of bed for that.
Trolling is a art,
Big inkjet plotter at work. Not great quality for photos being a kind of old printer, but wonderful for huge charts or sequence diagrams for complex code flows.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Basically - sure the XSL is longer, but also more flexible in terms of use.
That's the whole point of the article, that for many (most?) uses, the extra flexibility is not needed and the features offered by CSS is more than up to snuff to get the job done. I mean sure, instead of using Project you can use Excel with a boatload of macros and have a more "flexible" system, but the point is that Project encapsulates most of what people want to do. After all, this is the exact same argument that deals with why we now generally program in C++ or Java vs assembly right?
No, I didn't hear you.
There's already a lot of discussion here about how IE's XSL transforms (and CSS support in printing) both suck, and how a proper workflow for XSL involves a server-side transform.
The authors of their CSS Rocks article are imagining that you're going to use software like Prince, (software that one of them created) to apply CSS3 rules to XML and get PDFs out of them.
Another way to say this is that they're not talking about how to fix the browser -> print workflow in this article (although one of the authors works for Opera, so I imagine he's thinking about it). They're talking about easy ways to transform XML to PDFs, and discussing why you might use CSS to do such a thing.
This courteous and friendly rationalizing of the slashdot editor's inflammatory post has been brought to you by my company, which is paying me for the time I use to write this. The opinions, of course, are mine only.
You are right that XML (and kin) are not typesetting systems.
However, there is a language called XSL:FO (Formatting Objects) written on top of XSL that can be used to describe typsetting for XML documents, as printing is just one sort of transform. People usually use it to produce PDF's of data, but I have seen it used to produce a book of medical images.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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!".
Let the hair pulling and the name calling begin.
I have looked at XSLT code and its pretty horrible.
Its much easier to write a Perl script to read in the XML, "transform" it and write out new XML.
6. Most TeX distros [like tetex] are FREE and open source.
And there lot of OSS tools that support TeX. My favorite is using PARI/GP to do some math, and then using the TeX output to copy-and-paste into a document (like a journal submission). I did this for my last paper, and it worked well. The paper had to be submitted in Word format, though, so I made my editor re-enter all of the equations. :)
(S(SKK)(SKK))(S(SKK)(SKK))
i love css, it has made my life much easier. yet it still has been the cause of many nights of frustration. centering blocks, floating images appearing sparadically, poor.. yes i say poor documentation! bad browser support, etc. css is much better than xsl but we still need something more universal and sensible.
Later,
Phil
If a program uses XML to store something that is meant to be printed, use that program. For example, I use AbiWord to print AbiWord documents, which are XML. Whatever AbiWord uses to convert the XML so the printer can understand it is not something I care about unless I am an AbiWord developer.
Whatever works best to print XML that represents foo is irrelevant if foo wasn't designed to be printed.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Do not answer that question. My client wishes use the "German Library Copying" defense.
Please stop trying to build up this markup language, which annotates documents with suggestions as to how they might be displayed, into a typesetting system. Please get a typesetting system instead, and use formats such as eps and latex that are relevant to the task.
Thank you.
Also please stop using XML to represent arbitrary data. It's a markup language. It annotates and divides text. It does not extend easily to representing all data in all contexts, and when you try and make it do that, you wind up with syntax like '[CDATA['.
Thank you for your co-operation and enjoy your day. This has been a Public Service Rant brought to you by Diet Coke.
Whence? Hence. Whither? Thither.
At the end of the article, the authors say this:The point is that both CSS and XSL can be used to output to PDF. The authors state that CSS wasn't made to be a Turing-complete language, rather a layout language. They aren't saying CSS can do everything XSL can, rather that most of what you can layout with XSL can be replicated in fewer lines, and more readably, with CSS.
In nice, big text. Way to hold the the XSL fort, guys!
Jeremy
Looking for a Python IRC bot?
XSL wasn't meant for formatting and printing. It was meant for converting XML into other XML formats (such as XHTML + CSS helloooo???)
Comparing XSL vs. CSS is like comparing Table-based design with Table AND CSS-based design.
(X)HTML's Document Object Model has default styles ("default" CSS if you prefer) assigned to each element. Of course using CSS is necessary.
And the reason many XSLT stylesheets are so long is because of the stupid design imposed on them (non-changeable variables, result-tree-fragments, inability to eval an xpath expression... ok who was the genius who came out with these ideas, anyway?)
Unfortunately, current browsers cannot do ALL the formatting. Try turning off IE's header and footer using CSS. Or customizing your own header and footer, or print landscape instead of portrait.
Let's hope that CSS3 solves these problems - but until then, server-side PDF generation is the solution.
Anyway if browsers had supported XSL, it would be a mainstream component of the web today. We would have marvelous things like client-side inclusion (I've done it with XSLT alone, _NO_ javascript!), bandwidth savings... (imagine that with Google!)
In the end it became a pipedream due to the lack of browser support.
Doesn't XSL convert XML to HTML (or any other document) anyway?
In my world I use both. XSL when I need something really robust; CSS when I need to reuse css styles.
Both have their place. Arguing whether one or the other is better is really moot. You can use CSS with XSL to render XML anyway.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
It doesn't matter which standard (CSS or XSL) an author uses for styling pages for print if there aren't many widely-used applications (e.g. web browsers) that have good support for printing. Even Firefox, which arguably has the best standards compliance, has a lot of bugs in its print layout subsystem.
Though I do have to agree with the article, in principle, that CSS is fully capable of doing the job when it comes to producing printable page layout, if we're going to be banging on a drum, let's bang on the "let's get these damn browsers to support printing better!" drum first. Because even if I create a CSS stylesheet that should produce beautiful printed pages, it doesn't do me a lot of good if I can't actually print them that way.
Despite what EULAs say, most software is sold, not licensed.
This whole debate is a joke. Neither CSS or XSL is even remotely adequate for reliable printing. Currently, the only way to ensure printouts will look the way they should is to use PDF. I wish it weren't true, but it is.
Any man who afflicts the human race with ideas must be prepared to see them misunderstood. -- H. L. Mencken
The bottom line (at least for me): if you can do it with CSS, do it with CSS. But there are some cases where you will need XSLT.
Everyone knows print technology peaked with troff.
I stop reading when I saw that XSL examples are XSL:FO examples. XSL:FO is set of XML definitions on top of XSL to address the PRINT world's requirements. As such, it contains ALL the tags and attributes needed by this industry and provides EXTREME flexibilty, at a price: verbosity. However, the article does simple CSS formatting vs XSL:FO where XSL:FO is obviously not needed for that usage. So it's basically taking a hammer to kill a fly, maybe drop a nuke on it. Nonsense...
And Prince only costs $2,000 per server!
... is TeX or Postscript better for storing more-or-less arbitrary data in an easy-to-parse format? Because that's the real point of XML. The advantage of something like XML:FO is that you can then take this nicely formatted data and convert it directly into something printable.
And before you say it, no, there's no point converting to TeX or something else... if you're going that far, you might as well go straight to PDF, which is what XML:FO facilitates.
I think that generally the other compelling point is that you would probably use XSL:FO server side, and generate a PDF of known quality.
If you use CSS you are at the browsers mercy as to quality of output and it can lead to many annoyed customers calling you...
There is no way to test all users of CSS, but it's very easy to test all the XSL:FO cases that would be used.
I also think it unfair to compare XSL:FO and CSS to the grouping of Project vs. Excel. Actually in that comparison I would have to say that CSS is the Excel - a tool that CAN do many things, but should it? XSL:FO is built to handle typesetting operations, just as Project is made to handle the specifics of project managemnent and scheduling.
I'll all for CSS for many uses but printing does not strike me as a very good one for that tool.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Is it the size that matters, or how you use it?
Yeah, yeah, yeah. The story is a dupe, the topic is boring, the facts weren't checked. WE GET IT!!
they should start by infiltrating the developer's ranks at the major companys first. No need for a whole army!
but could somebody show me how i would actually use that CSS example in my HMTL page?
Everyone seems to be confusing XSL-FO (formatting objects) with regular XSL (what used to be called XSL-T). Formatting objects are admittedly more complicated than CSS. But "regular" XSL, which transforms XML to XML, (X)HTML, or even text, is incredibly useful, flexible, and fun! The work I do takes XML files, transforms them using XSL into XHTML, and then formats that with CSS. Simple!
When the SVG spec was first published, I combed over it pretty well. This was when basically no renderers were active enough to cover the whole spec. Yet, the W3C had screenshots. They had screenshots for some rather confusing or unclarified attributes of certain elements. These were things you couldn't explain in words well, but moreso with illustrations.
Having been at the very least an HTML tinkerer since 1996, and also having parlayed a hobby into a career, I've spent a lot of time with cross browser compatability. In 2002, I learned a whole new level of cross browser grilling when I went to work for an ad agency with clients such as Dell, HP, 3M, etc.
My message to web developers is this:
For the love of God, stop using CSS for anything more than text formatting. Outside of that, not much else is 100% cross browser compatible, and I define 100% cross browser compatible as being more than vaguely similar from one browser to the next. Certain things like spacing and borders when defined in CSS get rendered differently from one browser to the next. I don't care if it looks great in IE or Mozilla. It should look great in both.
Until the browsers converge on CSS, (which is great in theory) please use nested tables for your layouts. They work great all the way back to Netscape 4, which is all you can ask for these days.
What I do for a living now, is even more dependent on other people writing clean, well commented, cross-browser code than the last job. I take websites for non-profits and put them into a CMS with an emphasis on preserving the look of their original site. Since the pages get split up into itty bitty pieces and put into a generic CMS that must cater to most types of site designs, I've lowered my tollerance for bad HTML and shoehorning designs into CSS.
http://zengarden.20megsfree.com/
As well as the relative merits of FO and CSS, in choosing between them you need to look at the relative merits of the tools that apply them (to generate PDF, normally).
For XSL:FO there is FOP from Apache. It works, but when I used it (2002) it had too many bugs to enjoy. I presume that it has improved since then. But it is free.
For XML+CSS there were no good tools at that time. Now we have Prince as linked from the article. But if you want to use this on your server it's going to cost you $2000!
Hard choice.
It's enough to create TOC, list of figuires, footnotes, what have you. Enjoy: CSS3.
Correct me if I'm wrong, but it appears that the CSS version is using non-standard functionality provided by a non-free software package. This software package obviously has some of the logic of those 1000-lines of XSL hard-coded into it, probabably in tens of thousands of lines of C++ code.
Vastly. XML is just a solution looking for a problem. XML without user agreements is so useless. You could achieve the same results, with the same effort using COBOL file discriptions.
"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."
You mean he moonlights as an XML + CSS formatter now? Selling 5 million records isn't enough to keep food on his table with those nasty, evil P2P criminals ripping him off, even with RIAA having everyone who looks like they might enjoy his music arrested on grounds that they crave it. Is he at least good at formatting? I wouldn't want him to starve...
BTW, doesn't he want to be called <weird symbol> now?
As a developer, I have used XSLT in combination with CSS, so that you have the best of both worlds. XSLT doing transformations and spitting out CSS classes based on the XML document and its criteria. I didn't think they were mutually exclusive, but more like they compliment each other.
God where are my mod points when I need them.
evil is as evil does
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
$20K? That's what I get for making tacos.
True enough. I presume some of the editors have day jobs and perform their "editorial work" on someone else's dime.
Or $0 per individual for a personal license. $2,000 per server for a business really isn't that much.
And THANK YOU to the grandparent! I was getting annoyed at all the long discussions about how IE does or doesn't support whatever. It's irrelevant!
Thinkin' Lincoln - a web comic of presidential proportions
You mean, I can hand IE an XML+XSLT combo, today, and it will turn out a beautifully printed document?
Your 20,000 line Java code can be replaced by my one line C code... beat that! Clearly one line doing the same thing as 20,000 lines means C is superior...
I mean, sheesh... line counts make things better? pleeeze...
---
Programming is like sex... Make one mistake and support it the rest of your life.
Håkon Wium Lie - one of the authors of the CSS Rocks article, is also was co-creator of CSS - or at least he co-wrote the CSS specifications that are available at W3C.
Not to say that's bad, I've got his CSS book (The one with Bert Bos) and it really is a good book - and accurate, since the authors of the book are the authors of the specification.
Apache/1.3.9 (Unix) Debian/GNU PHP/4.0.3pl1 mod_ssl/2.4.10 OpenSSL/0.9.4
thru Catchcom
is better than
Apache/1.3.33 (Debian GNU/Linux) mod_python/2.7.10 Python/2.3.4 PHP/4.3.10-2 mod_ssl/2.8.22 OpenSSL/0.9.7d
thru Charter Communications
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
Okay, I have a silly question: Say I'm using XML to store structured data but I want the printable output I get from LaTeX. Why not use XSL to translate the XML to LaTeX and generate the printable version from that?
The only thing better than Counter Stike: Source is the Half Life 2 deathmatch, anyway!
At the server side I'll use a proper programming language and DOM, and do it in about 1/50th of time and LoC count.
XSL has two parts: transformations (XSLT) and formatting objects (XSL-FO). XSLT by itself is not meant for formatting, but XSLT and XSL-FO together are meant for exactly that.
I suspect that most of the compactness of the CSS solution is that CSS has built-in knowledge of HTML. The XSLT stylesheet will have to implement that from scratch. So CSS may be a win if you are using XHTML, but less so if you are using your own XML vocabulary. In the latter case, a common approach is to have an XSLT stylesheet that converts to HTML, and use a short CSS stylesheet with that. It's only in the more complicated cases that the flexibility of going via XSL-FO is worthwhile.
This is just another example that the best way to get proven wrong is to claim that something is impossible or to claim that language X can NEVER do Y.
We see this time and again.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Two competing technical ideas so that everyone can line up behind one or the other and argue which is better.
I'm really tired of seeing everyone here just politely agreeing with one another in such a single-minded way.
Ever since the debates over vi/emacs, linux/windows, tastes great/less filling, etc. were all settled, there just haven't been any good arguments here.
Hey, I remember working with you. Weren't you the guy who used to pick your asshole and then sniff your finger? Oh man, how you stank up the fscking room!
I didn't read the article yet but I just got through my first experience with XSL. I used XSL to turn XML into HTML and used CSS to format that HTML.
http://greggman.com/headlines/2005/2005-01-16-xslt -rss.htm
Why is there an argument?
Why am I seeing so many bad reactions on here? Responses like "show me the browser support"? You don't need browser support for print! You need another program capable of it. So what that the first one to do it is commercial -- commercial businesses quite often outpace open source, truth be told.
Show me the browser support for XSL? The article is displaying an example of why CSS3 will solve most of the same problems 1000x more elegantly. XSL is Perl's (I like Perl, I don't like XSL) ugly kid brother -- got beat twice as hard with the ugly stick.
When XSL came out, where was the tool support for it? Nonexistant. Because it was just a standard first. The tool support even now, years later, is only partial.
So yes, CSS3 will take time to implement in the real world, but it's a clearly superior solution. Shortcomings? Probably more than a few. But if we WORK on them, we can overcome them, probably also 1000x more elegantly than the atrocity that is XSL.
So instead of bitching about someone getting it right for a change (now that we've wasted how many years trying to work with XSL), why not start up an open source project to build support for the new spec? This sounds like a good side-project for Mozilla.org or the KHTML folks (since they already have a rendering engine).
putfwd.com - 1GB Free file storage with a twist
Now I'm not one of them, and don't know if I'll ever be, but it's rather odd that they're comparing apples to oranges again. Repeat after me, every task can be accomplished with the appropriate tool. CSS is for Style (in case you forget), what's the point of having it do anything else. XSL (I never used it, so you'd know) FTFA XSL contains loops, conditionals, etc... Hmm... a tool for a DIFFERENT job perhaps? The only things that dissapear are things without purpose. Clearly, that is NOT the case.
You can use it to write man pages. It's better than texinfo anyway.
I agree, troff ain't bad. Although I suspect you were joking.
I guess today is a passable day to die.
Then you have to write COBOL.
Phil
I guess today is a passable day to die.
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.
Comes up fine for me. That sounds like your browser kacking on the XSL, trying to parse it -- which makes sense, because you'd really run the XSL server-side and output a PDF or something (as SuperKendall pointed out), and your browser wouldn't normally even see this. So this may just be a case of user confusion.
and I'm supposed to beleive what he says?
Are you a Candy Addict?
Get with the program... you goal would be better served with standing behind standards based development and yet you preach embedding presentation with content.
" I've lowered my tollerance for bad HTML and shoehorning designs into CSS."
This comment alone shows how out of touch you are with modern CSS based development...
Check out the zengarden, the CSS vault and CSS beauty for a lesson.
The scope of XSL (XSLT + XSL-FO) ist completely different from CSS. CSS makes sence with HTML or XHTML. But it is not useably on XML-documents like books written in docbook-XSL or a finance report in some other weired XML-language.
comparing CSS with XSL is like comparing C with regular expressions...
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.
What I really need is a programmer who understands the binary language of XSL . . .
. . . XSL?! Sir, my first job was programming XML, very similar to your XSL in most respects.
Do you program Perl?
Of course I do, sir, I must type some for you.
Alright, shut up. --He'll do. Luke! Take these two programmers and get them cleaned up.
What those who want activist courts fear is rule by the people.
In fact, there isn't even any graphical web browser that I know of that can fully render HTML 4.01 Strict.
Can anybody list some software?
testing out my trending skills
To handle transformations (as a separate issue from styling) the new XQuery language has some advantages over XSLT. The syntax is a lot more readable and more concise, and it's actually a reasonable programming language. It's a superset of XPath, which may people (including XSLT users) are familiar with. On the other hand, it doesn't have XSLT's "template processing" model, which simplifies writing transformations, and it's not a finished standard yet (though it's close). My article discusses and illustrates using XQuery to transform XML for presentations. It's about generating web pages, while the parent is about generating PDF, but it does suggest it might be worth trying XQuery for generating XSL-FO (or even XHTML+CSS).
Printing XML will require you to first convert XML (in some arbitary format) to (X)HTML - this is something CSS cannot do.
You need XSL to convert XML to HTML/PDF or any other format for printing.
Except that an Adobe employee confirmed my statement that InDesign's H&J is based on TeX's by way of URW's HZ algorithm --- you really don't think Adobe licensed HZ from URW to not use it?
As regards Unicode --- while it's true Omega has gone dormant there're two viable successors:
- Aleph - a direct combination of Omega and e-TeX
- XeTeX - a Mac OS X-specific variant able to use OpenType and AAT fonts
William
Sphinx of black quartz, judge my vow.
XML, TeX, and PostScript are all designed for slightly different purposes. XML is good as an interchange format for structured data. Its main strength is that it is easy to transform XML into other formats. XHTML can be used to store semantic information which can have a specific presentation applied to it using CSS. There is no theoretical reason why this couldn't look as nice as that produced by TeX, but practically it usually doesn't since it is usually typeset by browsers which require their layout engines to run in real time.
TeX and PS are both Turing-complete languages with slightly different purposes. TeX is usually used with the LaTeX macros as a semantic markup language. The advantage of this is that it is much easier to type than XML. \section{This is a section heading} would be the equivalent of <h2>This is a section headong</h2>. I also find LaTeX code to be more human-readable. PS (and it's non-Turing-complete little brother PDF) are specifically designed to produce page layouts - they do not contain semantic information at all. It is relatively easy to convert between LaTeX and HTML, and it is also relatively easy to render either as PS or PDF. Converting in the opposite direction is more tricky.
I am TheRaven on Soylent News
First off *slaps the story poster* call it XSL-FO, not XSL which tends to infer XSLT which is perfectly good and often used in combination with CSS.
Now *slaps the person who wrote the post*, if youre not going to write a fair comparison don't bother writing one at all, the XSL-FO shows a page-size selector which will work for any size page, and he compares this to a one-size A4 CSS definition, I stoped reading at that point, if your going to argue Hello World is better than A cellular automota because it's got less lines of code in it, I don't want to hear any more of your arguments.
Support for XSL wasn't bad a few years ago, and it even better now, maybe not of you sub XMLSPY's quite good and it runs under wine.
thank God the internet isn't a human right.
Diverging more generally to the topic of XML...
I'm not sure it's fair to compare a 100 line straight text file to a 1000 line XML file and say that one is inherently superior. Having worked with XML, crafting it by hand, running in to all sorts of parsing errors, I've come to one conclusion:
XML was never built to be written by hand, or to be read with the human eye.
After all, these are text files, and it's not like we're using systems with only a few hundred kilobytes of storage anymore. I can see a distinct advantage to enforcing a schema on data, even if it is a total pain in the ass to enforce it.
I can craft 100-200 line XML files in the manner that we all craft HTML by hand, and my patience *just* holds out through all the parsing errors.
What we do need is a good (ideally open source) XML editor that's as natural and intuitive to use as Notepad (or more ideally Textpad) is to edit text files.
I haven't seen one yet. I keep going back to really good text editors and using my brain and lots of iterations checking that the XML matches the schema to keep me from going insane.
Some of them are out there, but they're all so *fiddly*. Fiddly enough to scare off a data content author, who isn't a programmer. Given a schema, editing XML should be Microsoft Word easy (sans Clippy). I've not seen it there yet.
Then again I'm an old bastard (30) who wants to edit everything by hand no matter what. It's hard to break that habit.
Doesn't everyone who scratches thier ass smell thier finger afterwards? I don't think it's that odd of a thing to do.
As for public nose-picking, that's all fine and well (I do it myself), but eating the booger? That's just gross (or possibly shock value).
They're talking about what can be done with a program like prince (which one of the author's wrote).
In other words, we're all reading a Slashvertisement. I for one cannot afford a single user license for Prince.
Current browser incompatibility is totally irrelevant.
What residential user or small-business user can afford to purchase and install anything but a "current browser"?
CSS may be better than XSL, but it still can't render fonts as well as book printing technology practiced 500 years ago. The whole question of rendering fonts and default fonts needs to be resolved.
Si tacuisses philosophus mansisses. If you had kept quiet, you would have remained a philosopher.
In most projects of scope I've seen in large companies, projects have taken on many flavors of languages - from Java to C# to JSP (which I consider another language really) to HTML to Javascript - and more.
While generally I would consider it smart to try an coalese on one primary lange (say, Java...) you will undoubtledy end up working with other languages on the pereriphiary anyway - like SQL or HTML or XSL or whatever. So I would agree that good developers can work with a lot of languages.
I would say probably the best mix on a project would be one language with a deep library (like, say Java!) and then other supporting languages around it to do what they do well.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I can't beleive slashdot just posted a link to a piece of software which quite obviously abuses the principles of the open source software which it uses.
A quick strings on the Prince execuatable reveals that it uses libxml at the very least. Googling for some of the error messages such as "parser error : Entity 'Ouml' not defined" confirms this.
I hate to be a snitch, but the author should atleast acknowledge the use of FOSS software in their product, even if it is under the MIT license.
Well to render CSS and Javascript, just about any browser will do.
This is my sig. There are many like it but this one is mine.
Do you really use raw TeX or LaTeX?
:).
I've never really used much TeX, mostly LaTeX.
I think the CSS versus XSL discussion is almost a bit like TeX versus LaTeX: TeX is a full programming language, giving you 100% flexibility to do the most crazy things. However, it is so complex that almost noone can use it directly. LaTeX provides the default settings and macros that 99% of users can live with, and saves them all complexity and details.
The difference between TeX/LaTeX and CSS/XML is, however, that while using LaTeX you may occasionally descend to the TeX level if you need to do some obscure thing not possible in LaTeX. With CSS there is no such fallback possiblity. If it isn't in CSS "level" X, you'll have to wait for the next version
Everyone I know doing CSS uses it client side. Everyone I know using XSL uses it server side. Often both are used at the same time, with XSL used to transform the XML into XHTML, and the CSS used for pretty presentation.
I'd rather see it compared to other templating solutions. It seems to me that XSL is like a functional language compared to other templating engines acting more like an imperative language (I said like, it's not a great analogy). It would appear to me to be a bitch to render XSL pages real-time if, as I see in many tutorials, the transforms are an extensive list of recursive <xsl:apply-templates>. How fast are the XSLT parsers these days?
Phillip.
Property for sale in Nice, France
In the comments at the foot of the article, the author says that using both is advantageous. Do your complex transformations in XSL, then hook in CSS for presentation, and you're playing to the strength of both languages.
Vino, gyno, and techno -Bruce Sterling
I'd much rather use Skribe.
"You missed my point. Writing TeX is programming a computer. You have to learn a whole new language. There's no excuse for that."
Typography is different than "just puting marks on paper".
You want to put "marks on paper"? Use a wordprocessor.
You want to do typography? Use a markup language.
You get out, what you put in.
I found stylus studio (tried it a few years ago) to be very good for hand-crafting xml. I think it's the best XML-tool for programmers (or at least it was then).
For an open source alternative, JEdit doesn't totally suck.
And if this a "troll bite" than it is an equally good one, since it reads like an honest answer. Apparently certain moderators cannot see a difference between a question and a link to goat sex pornography. Don't worry about them, they will grow up one day, I'm sure. Meanwhile, thanks for your answer.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
I do. It can be a very enlightening experience, and once you learn how to think backwards--e.g. /x a b c d add sub mul def means x = a*(b-(c+d))--it can be quite entertaining. And it is very funny to use the random number generator to make your page slightly different each time it is printed, and watch the faces of people who try to correctly adjust the CMYK plates in the printing press!
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
$20K? That's what I get for making tacos.
Making Taco's tossed salad?
I know better than you do what font sizes I can read comfortably. Stop trying to control me. Just give me the content, and I'll display it in a manner which suits me.
The point is that you want the good results without putting out the matching effort.
But can Mozilla Firefox take an XHTML+CSS+JavaScript document and render it to PDF without having to start X and without any user interaction other than passing a URL and a PDF filename on the command line?
This comment alone shows how out of touch you are with modern CSS based development
Microsoft is the one out of touch. A lot of the CSS tech demos I've seen on the web do not work in the latest version of Microsoft Internet Explorer, and until there's an official way to install the Mozilla ActiveX control over the Internet...
because it does something completely different?
And THANK YOU to the grandparent! I was getting annoyed at all the long discussions about how IE does or doesn't support whatever. It's irrelevant!
Don't bother sending me your resume until you grow up, kid.
Are you kidding me? You can't afford the free personal license?? And you really don't think a small business can afford a 300 dollar program?
Thinkin' Lincoln - a web comic of presidential proportions
Are you kidding me? You can't afford the free personal license?
I can't afford the EULA restrictions that often come with the no-charge version of a program that also has a version sold for three figures USD. It could be that one is not permitted to distribute documents prepared withe the no-charge version, or it has a huge-*** watermark over every page. Is the EULA posted online where I can read it separately from downloading the program?
In addition, which major platforms is the no charge version available for, and if fewer than two, how much does the platform's emulator cost?
Yes, and furthermore browser incompatibilities would be irrelevant in a XSL vs CSS discussion anyway. Incompatibilities, in the sense of two browsers rendering the same document differently, isn't resolved by XSLT. The outcome of XSLT would be another document, usually (X)HTML, and surprise! browsers render that document differently.
If the outcome is to be presented by browsers you will always be dependent on those browsers, the number of transformation steps you have done before rendering won't help. (X)HTML has had very few if any rendering requirements. CSS is more stringent. If two browsers differ you can usually tell if one (or both) browsers are wrong. Wrong is contextual however, it may well look different on a phone than with a printout with a user style sheet.
It's called client site scripting.
What's the JS code to make Firefox 1. not crash if it can't connect to an X11 server, 2. load a URL, 3. print its contents to PDF, and 4. exit? Are you talking about setting the DISPLAY environment variable to an Xvfb?