On Jan 17, 2008, at 09:55, Chris Bowditch wrote:
Andreas L Delmelle wrote:
Those components/resources that apply to all types of renderers,
can be handled in AbstractRenderer.
AbstractRenderer could provide a generic createResource() method,
which can be overridden or re-implemented in the specific
renderer types to handle the renderer-specific stuff.
Coming to the Intermediate Format: that document should, as you
mentioned earlier IIRC, ideally be renderer-agnostic. So, if all
is set up well, the resources can be embedded/referenced in the
intermediate document as abstract <resource> nodes, with a
reference (attribute?) to the applicable renderers. Some
resources may have to be inserted multiple times for different
renderers? So be it. The IFHandler should probably be made
intelligent enough to ignore/ disregard any nodes that do not
apply to the current output format, so they get excluded real
early in the game. When the document is ultimately rendered, the
eventual renderer type will determine what needs to happen with
the embedded resource.
The downside to including a resource node for each possible
renderer is the space occupied by the Intermediate Format.
Wouldn't be much, if we precisely aim at keeping them in the document
The major problem with the current IF XML is how verbose it is.
This verbosity is what makes the performance of FO->IF->PDF so
slow. This is the main driver for re-working the current
Qua processing, when the eventual IF XML is read back in, the
resource nodes that do not apply to the output format for that run
should generate only very little overhead, since we would ignore
them. If the goal is to have one and the same IF XML that can be
transparently rendered to either PDF, AFP or PCL, then including
separate resources for separate renderers may turn out to be a
necessary evil... If some renderers can be made to share resources
(or logic in handling specific resource types), all the better, but I
think Jeremias precisely hinted on that having its limits.