Hi all, As you may have noticed I've been quite sllent for a while now. It's not for lack of interest but as usual for want of time. I've started a project at work which is going to be eating most of my time and energy for at least a couple of months more.
I'm happy to see that we seem to be getting some new blood in the group and I applaud Keiron's "Understanding ... initiative". Perhaps you'd like me to write a bit about the current property handling in that series? I've actually (finally!) done a bit of work on FOP so here's an update. I've just committed some stuff into the main branch. I put a class called CTM (coordinate transformation matrix as in Postscript/PDF) into the area package. It's currently set up when the page master is making regions. The idea is that it will transform writing-mode relative coordinates into media-relative coordinates. For now media means standard 1st quandrant coordinates as used in the default PDF or PostScript coordinate system, where origin is at the lower left of the page. The CTM accounts for both reference-orientation and writing mode on reference areas. There is a CTM at the page-reference area level which is used to transform writing-mode relative region coordinates into media coordinates. Similarly the CTM at the region level should transform writing-mode relative coordinates for its child areas into media coordinates. The layout managers should then generate Area objects whose position and size is expressed in writing-mode relative values. So if "x" = start, "y" = before, "width" = ipd and "height" = bpd, the CTM should turn that into actual x, y coordinates on the page. The CTM class itself just does the basic math functions. I've put most of the logic of setting up the CTM into the PropertyManager which may not be the right place, but at least it's central. The method "getCTMandRelDims" is called both from SimplePageMaster and Region (in fo/pagination). The RelDims business is sort of a hack, but I wanted to set inline and block-progression dimensions and I already had the info from the CTM calculations... I'm sure one of you will have a better idea! The logic is certainly incomplete and the CTM currently has no effect on the rendering logic. It may well be buggy too, but it compiles and runs the "hello world" test. I will try to write some test cases, but I'm not promising any dates. I'm not sure what the best way to hook this in with rendering is. It may well depend on the renderer. In PDF or Postscript the obvious easy solution is just to set the CTM when entering the reference area, but for other renderers this will probably not be possible. I'm happy to answer any questions on this (if I can). The other thing I've worked on is in the actual LayoutManager logic. I've got this concept of a "BreakPosition" and have some code written at the inline level (text, inline, line). The idea is that instead of an LM calling generateAreas on its child LM, it repeatedly calls "getNextBreakPosition". It then uses the returned BreakPosition information to decide on the best break. Only then does it ask the child LM to actually make the Areas necessary to break at the point. My goal is to try to get this stuff ASAP into a state where it will at least compile and can be put into the current code base. Sorry for not being more active, Karen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
