What does
That's unlikely, because a properly configured server would send
application/pdf as content type for "real" PDF. :-)
That mean exactly?
I believe the comment was made one workaround could be that you could
have the client associate "text/pdf" with a fo engine and then have
your server have the in the content header it was were returning a
"text/pdf" when your server was returning xsl-fo documents. The next
poster was made the point that as soon as the user hit a properly
configured server, it would lead to an error since the xsl-fo engine
would be expect a fo (xml) document but would be receiving a pdf
document. This was corrected by J.Pietschmann, who said that the
client should only associate actual pdf files with "application/pdf".
I'd be wary about using this workaround anyhow. Also, it makes more
sense to me to return something like "text/fo" if you were really
going that route anyhow. I'd double check those standards before
doing so of course ;).
I looked at a few PDF docs I have on my local system, they look very
"binary"
Ummm, guessing what a PDF looks like inside from looking at random
pdfs is rather difficult. Why not just look at the specs?
http://partners.adobe.com/public/developer/pdf/index_reference.html
I think there's some more confusion here.
Most people start out with an XML source, transform it to XSL-Fo, and
then use a FO engine/translator/processor to transform that into PDF.
that is:
XML -> XSL-FO -> PDF
Where the first -> could be transformed via XSLT, SAX, or some other method.
The second -> is done by something like FOP or XEP.
It was my impression that you were interested in going directly from
XML to the PDF. It might be possible to do this for a simple case,
although if I recall correctly for pdf you'll need to keep track of
byte placement, which might be possible with use of extensions in XSLT
(but I kinda doubt it).
But if your source is going to be in XSL-FO, this would require you to
essentially write your own XSL-FO engine in XSLT. Even if It is
possible you essentially end up with the same steps.
Notice that FOP and XEP are actually just transforming fo files into
another document format. It's entirely feasible they could do other
outputs besides pdf (I know some have some basic RTF support). It's a
bit like a gif could probably be converted to a png or a jpeg.
1) can I get started without the fo engine?
like I said, it might be possible, but it's very hard. The larger the
range of your possible source xml files the less I'd recommend even
considering a direct pdf generation from XML source. And I really
wouldn't recommend very much in any case.
2) will the xsl:fo namespace work without the engine (local) - so, the
namespace is valid and the transformations take place accordingly
Errr. No clue what you mean by this. If you create a fo document,
it will be a valid fo document. But there are no magic
transformations in XSLT that are associated with fo. It's just like
any other xml format. You need an engine to convert fo to PDF, Word
etc.
3) does someone have a simple "hello world" -- or, depending on your
up bringing -- a "foo bar" sample?
A simple direct to pdf example? Never seen one, not entirely sure
it's possible. I have toyed around with the notion, but unless i feel
like getting far better acquainted with the pdf standard I probably
won't. In fact, one of the only real good reason I could think of
such a project would be to get more familiar with the PDF format. The
other possible would be seeking some sort of universal client-side
rendering, but the performance penalties would most likely be extreme.
well, hopefully my long email hasn't caused any more confusion.
Jon Gorman
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--