Arne said:
[...]
and I very much doubt that any of those are callable from .NET.
I assume you mean you doubts they have specific .NET support. A library
that can be called via other means is also callable via .NET. It just
requires a little more work, is all.
AFAIK then neither are libraries - Apache FOP is a Java app and
Altova StyleVision is a native app.
Let me rephrase: if they are usable from one's own code in any scenario,
they are usable from .NET.
I don't know anything about either package; maybe they aren't usable
from _any_ kind of code, including .NET. But then I'm not sure why they
are mentioned as a solution in a programming newsgroup. My assumption
is that the OP is actually looking for something that works in code.
I suspect that the "little" more work is a pretty big little.
For libraries? Or standalone application? If there's a well-defined
way to use them from code, the work shouldn't be all that hard even if
they aren't specifically .NET-friendly, whether they are libraries or
standalone applications.
If there's not a well-defined way to use them from code, then yes…it
could potentially be a lot of work to get them to work from code. But
that would be true no matter what language/platform one was writing
one's code in, making them somewhat impractical solutions to be
suggested in a programming newsgroup.
XML->HTML via XSLT is easy.
True.
HTML prints nicely.
Not always true.
Unfortunately, browsers have a variety of implementation bugs in which
their output, either on-screen or printed, does not necessarily conform
to the specification, and worse, there are often problems when printing
a document that aren't seen in on-screen display (I ascribe that to the
fact that for whatever reason, different code paths are used depending
on the output device, and on poorer testing for printing scenarios).
Even for simple things, I've run into a variety of presentation bugs in
a variety of browser. I can't imagine the headaches someone writing
complex HTML must have to deal with (fortunately, my XSL/HTML/CSS uses
are always reasonably simple).
If the exact formatting is important, then the transformation must
assume a specific browser.
If by "specific browser" you mean "specific version of a specific
browser running on a specific version of a specific platform", then yes.
IMHO that's a serious problem.
It may even be possible to convert the HTML to PDF.
Any platform that includes "print to PDF", either as a built-in feature
(e.g. Mac OS) or using a third-party printer driver (e.g. Windows) can
trivially convert HTML to PDF. But you still have the browser
compatibility issues.
For long-term maintenance, if an exact output is needed, biting the
bullet and implementing output-to-PDF from the outset is really the most
efficient, most practical approach.
Pete