On Jan 16, 2008, at 08:15, Jeremias Maerki wrote:
Hey, I don't like doing stuff twice or more times. Each output format
has its own specifics and there are limits to what extent
can be extracted. For example, some formats don't support free-form
transformations. In PCL, it's impossible to write a Graphics2D
implementation that doesn't end up using bitmaps instead of native
commands to paint the individual elements. Actually, that fact is
exactly the point what's concerning me most if I think about a new
intermediate format which will result in a different kind of
for the rendering components.
Hmm... So it seems like it does not only depend on the renderer, but
also on the type of resource (graphic, font, XMP metadata packet...).
Maybe separating into an AbstractRendererResource would be an idea:
a PDFFontResource could easily share logic with an AWTFontResource or
AFPFontResource, or even PDFGraphicResource.
Point being that their interface towards the AbstractRenderer remains
uniform, while the behaviour can still be dedicated to one specific
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.