Sorry about the delay here. It got lost in my big backlog. I don't know about MIF and PCL (yet) but SVG supports the matrix() function in the transform attribute to directly use a transformation matrix. But since AFP doesn't seem to support it, it may really be best to fall back to the minimum supported by all renderers which will probably be a list of simple transforms like translate(tx, ty), scale(sx, sy), rotate(angle, [cx,cy]). I don't think we need skew. Basically this would be a subset of the functions defined by 7.6 "The transform attribute" in SVG 1.1 [1]. So, the current "ctm" trait could actually be replaced with something like a (scaled-down) SVG "transform" attribute. That shouldn't be difficult to implement. As a nice side-effect, this could even be reused in the upcoming intermediate format to do imposition (rotation, n-ups and such).
I assume you will handle the implementation, right? [1] http://www.w3.org/TR/SVG11/coords.html#TransformAttribute On 23.12.2005 14:04:59 Manuel Mall wrote: > On Mon, 19 Dec 2005 04:50 pm, Jeremias Maerki wrote: > > I see absolutely no problem with creating that special class that > > holds all the information about the setup for the new coordinate > > system established by a viewport. You could argue that the CTM is > > calculated too early in the layout managers. So far all renderers > > were pretty much ok with only working with the CTM. If that doesn't > > apply to all renderers we have to adjust for that. > > > > What I don't quite get is why both of you talk about a new class. The > spec defines all the necessary traits required. What is the argument > against simply adding these traits to the area tree? Given that > Viewports are not appearing very often in the area tree (compared to > line, text, block, space,...) adding a few additional traits shouldn't > be a size/space problem. > > BTW, so far we only have 3 renderers using the CTM (PDF, PS and Java2D). > It remains to be seen if other renderers currently in the sandbox (mif, > pcl, svg) can live with it or require the base properties from which > the CTM was calculated. > > > On 18.12.2005 17:42:01 Andreas L Delmelle wrote: > > > On Dec 18, 2005, at 14:52, Manuel Mall wrote: > > > > > > Hi Manuel, > > > > > > > <snip /> > > > > I think this needs improvement but what is the best strategy > > > > here? > > > > > > I just had an --admittedly very vague-- idea about this, don't know > > > if it is feasible. Jeremias, correct me if I'm wrong... > > > > > > What about creating an object type, especially meant for use with > > > the render-type AFP, that stores the needed info? Something like a > > > mapping from 'viewport with id'->'reference-orientation' (maybe > > > only for orientation other than zero). That way, you wouldn't need > > > to reverse engineer the values from the CTM. In fact, the AFP > > > renderer could bypass the CTM completely and get the relevant data > > > from somewhere else without having to perform recalculation. > > > > > > Not really sure about the how, when or where, though... As I said, > > > very vague. > > > > > > Just a thought. Hope it can be of use. > > > > > > Cheers, > > > > > > Andreas > > > > Jeremias Maerki > > Manuel Jeremias Maerki
