XSL-FO Image Scaling

To render images in PDF documents I stepped over the problem of image scaling. If an image is too big to fit within the page width, it should be scaled down, otherwise it should stay in its original size.

With we get an image small enough to fit on a paper page, but smaller images are zoomed to 10cm width as well :( . So I could determin the image size for the meta information within the cosmos and then use the values to explicitly specify the content-width only if needed. With the small ImageInfo class I could even get the information without building an AWT dependency.

Then I've found this in the Google Cache (the site seems to be offline):

----

by G. Ken Holman

>Is it possible to scale images so that images that would run off the
>page are scaled to fit, while smaller images retain their existing
>size.

The pattern I've seen used is:

width="100%" content-width="scale-to-fit"
scaling="uniform"
content-height="100%"/>

or, if you want to limit by height instead of by width:

height="100%" content-height="scale-to-fit"
scaling="uniform"
content-width="100%"/>

When images are smaller than the dimension changing specification of the content dimension using "scale-to-fit", the image is considered to already fit. If the image is larger than the given dimension, that dimension is reduced to fit to the viewport (defined by height= or width=, in the above examples, the use of 100% specifies the viewport to be the full dimension available, you have to choose one of height or width to be the governing dimension since specifying both won't result in proper scaling).

The scaling="uniform" ensures that the other image dimension is relatively scaled so as to not disturb the aspect ratio.

Finally, the explicit specification of the other image dimension to 100% ensures that the governing content dimension specification does not distort the content's other dimension ... so images that are smaller than the governing dimension do not get stretched to 100% of that dimension's available size.

I hope the explanation can be understood, and I would welcome anyone else's wording of what I've tried to say above ... all I know is that I learned the pattern from somewhere and I understand what it is doing and it has worked for me ... but I have to wave my arms to convey my thoughts on this.

----

Default Namespace in XPath

To access the different nodes within the cosmos with an XPath I use an XPath processor. Unfortunatly XPath 1.0 does not allow to specify the default namespace. To distinguish cosmos object nodes from other, more general content within the objects I like to put them into a specific namespace. So either all the IDs (tag names) of the cosmos objects need to be prefixed (eg. 'c:livcos.org/c:test/c:TestDocument' or we are restricted to XPath 2.0, which allows to specify the default namespace.
Since JAXP 1.3 only offers XPath 1.0 this implemention becomes dependent on the processor implementaion (Saxon 8.6.1B for now). The default namespace can be set with net.sf.saxon.xpath.StandaloneContext.setDefaultElementNamespace().

XSLT read on demand

With the prototype org.livcos.prototype.xslt.read_on_demand we test different XSLT processors about which elements are read from the source for a transformation. We transform a subnode with a stylesheet only matching certain elements.

Report:

• Xalan reads the complete tree rooting at the source node.
• Saxon reads the owner document of the source node.
• Saxon ignores unneeded parts of the tree.
• XT handles only Stream- and SAXSources. The later are streamed into the internal object model completely.
• Oracle XDK handles Stream- and SAXSources.
• Oracle XDK handles DOMSources only with their properitary object model.
• The Oracle XDK object model is based on abstract classes, therefore a customized implementation needs to be build on top of it.

With all the processors reading only the tree below the source node, only the Saxon Processor would reduce the amount of data being read, by ignoring the parts not matched in the stylesheet.
A DOM-to-SAX event producer allows to feed a copy in the internal format of the individual processors object model.

Cosmos Nodes

The simplicity of the all-nodes approach has lead me to give it a try. All the objects within the cosmos can be accessed by a simple XPath. For XSLT transformations the sources can be also specified by an XPath. Being aware of the huge dimension of the entire cosmos this should allow to specify the smaller parts a working context is interested in.

Cosmos Basic Structure

I'm working on a cosmos-domain-container-entity hierarchy to implement the first cosmos object model. Entities offer an XML interface for read and modification access and serve as a kind of XML document.
A friend of mine is working on the JSR-170 specification and has planted the idea of a cosmos being a huge, virtual node-tree. There are just nodes and only one document, the cosmos itself.

Intro

This blog captures thoughts to the LivCos project.