It might be helpful to take the renderer programmer's view: - A meaningful renderer interface has to be specified now, i.e. the representation of pages either in memory or serialized. More supported XSL properties lead to bigger storage requirements.
- Renderers take over pages consisting from some graphic objects with absolute sizes and positions. Anything between FO input and these graphics is completely irrelevant to renderers. - Layouters and area tree builders may produce fantastic documents on an extremely efficient way, conforming to specifications etc.: but what, if renderers are not able to render graphic objects, to handle orientations and directions - as it's the case with the PCL renderer nowadays? - Testing, validation is another topic. Java2D is the reliable rendering system unless you want to use the Adobe product as benchmark. When it comes to a Java2D renderer (former AWT renderer), there are these facts regarding text rendering, font support: o Java supports TrueType, OPI and Type1 fonts o XSL properties : Java TextAttribute's = 1:1 - TextAttribute maps give a binary object representation for XSL font properties in Java (more Float's than int's) - Java2D 1.4 does not process stretch and weight properly (hopefully fixed in Java 1.5), variant is not supported - font face picking by Java 1.4 is funny: a static font mapping is required to get predictable results o Java2D supports font metrics, i18n, bidi and Unicode well o Java2D does not support - word and character spacing: may be programmed by inserting white space - kerning: info not available in font metrics Similar observations apply to Java2D strokes, rectangles and images. Hansuli Anderegg
