Resources like graphics, fonts and XMP are not really the problem here.
Graphics are still referenced by URI or embedded as foreign XML. Fonts
need to be handled by the IFHandler anyway, the fonts are only
referenced by name plus additional properties. XMP is handled the same
way as foreign XML. Some other extensions may have more impact here.
Furthermore, the renderers handle resource management themselves,
based on what they support (PDF has objects which makes it easy, PS
requires rewriting the whole PS file to factor out resources used
multiple times, Java2D doesn't do any resource optimization).

The main point I wanted to make here is differences in the fundamental
approach of the different output formats. An example:

PDF, PS and Java2D can all handle free-form transformation à la
AffineTransform (translation, free rotation, skewing). PCL, however,
only allows rotation by 90 degree steps, no scaling (you can only scale
by modifying font sizes and line widths), no skewing. If you switch from
PCL to HP/GL you can do some more but you still stay way behind the
first three formats. I'm not sure about AFP but it may have some
restrictions, too, but probably not as many as PCL.

If we did what you propose, we'd actually have to incorporate
renderer-specific code in the IFRenderer which I absolutely want to
avoid because it splits the logic between two components which doesn't
help us.

On 16.01.2008 23:13:56 Andreas L Delmelle wrote:
> 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  
> > commonalities
> > 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  
> > abstraction
> > 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  
> renderer.
> 
> 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.
> 
> 
> Cheers
> 
> Andreas
> 




Jeremias Maerki

Reply via email to