> -----Original Message-----
> From: Eckbert P.Dollhofer [mailto:[EMAIL PROTECTED]
                                          ^^^^^^^^^^^^
                                      Yeah! We like those :-)

Hi,

> So where can I find any hints to do
>
> HTML+CSS+SVG -> XML-FO -> PDF
>                                    |--> HTML with Bitmaps
>
> Or if this is to clumsy create the Layout in XML-FO and do
>
> XML-FO -> PDF
>          |-> HTML with SVG
>          |--> HTML with bitmaps
>

If the above is an option, maybe the following is also feasible (?)

Base XML (plain XML, no FO here)
  + plain XSLT templates -> (via TrAX) HTML with SVG/Bitmaps
  + XSL-FO templates -> (via TrAX through FOP) PDF with SVG

XSLT offers the possibility of outputting HTML (or plain text for that
matter) instead of XML, and it is, generally speaking, very much easier and
more straightforward to implement a transform from XML to HTML than it is to
go the other way around, since the HTML needs to be 'tidied' before it can
be used in an XML app (--unless the input is XHTML, of course...)
On top of that, coding a stylesheet to transform (X)HTML input to a given
XML structure is usually a bit of a pain, since you can basically only
distinguish two <p> elements either by looking at the content, or by looking
at their position in relation to another element. Since in XSLT, one defines
templates for sets of nodes satisfying a given set of conditions, if the
source is XHTML, one generally finds oneself either writing separate
templates for each different <p> element in the source, or writing one huge
template for all of them with a lot
xsl:if/xsl:choose/xsl:when/xsl:otherwise.
In XML *you* have control over what the 'tags' (better: 'element names')
stand for. If you choose them while keeping in mind that you yourself are
going to be designing the stylesheet --if that is the case--, you can avoid
a lot of difficulties and ambiguities in advance (e.g. it becomes much
easier to 'pull' the desired XML nodes you need out of the source and apply
their respective templates to them, as opposed to merely 'pushing' the
source tree as a whole through the templates and hoping that the match
patterns for the templates suffice to sort out the rest)

Countless possibilities, but in the end, all depends on your actual
constraints, I guess... To what extent are the framework, input and output
currently already 'fixed' --in the sense of: 'not permitted to change'?


Greetz,

Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to