A couple of remarks below: Keiron Liddle wrote: > > Hi Karen, > > Welcome back. > Yes it would be great if you could write about the property handling stuff > if you have the time.
Done. > As for the CTM stuff. > For PDF there is a class PDFState which keeps track of pdf graphic state > information. Maybe this could be useful. I think the only way to deal with > any transform is to start a new state (q, Q). Currently it is used by the > PDFGraphics2D for SVG drawing. It helps to not need to put every drawing > instruction into a new graphics state and colour etc. is only changed when > needed. PDFState currently is not used at all in the PDFRenderer. Maybe we could integrate it in there too? For now, however, I've put some minimal code in the renderer to handle the CTM. Basically I've bracketed the region viewport code with start and end methods. The start method takes the CTM, so the renderer can set it up. In PDF, I just save the current context (q) and concatenate the CTM which seems to work. Then when I end the reference area, I restore the previous state with 'Q'. All coordinates in the reference area should be relative to that reference area origin where the "x" coordinate is the position along the "start" axis, whatever that is, and the "y" coordinate is the position along the "before" axis. Note however, that the viewport rectangle which I'm storing on the RegionViewport is actually in absolute Page coordinates (ie, origin at top-left of media rectangle). I set a CTM at the page level in PDF which inverses the y coordinate and subtracts it from the page-height. Because of that I also had to inverse the y coordinate in the text matrix (Tm) otherwise my letters were upside down... But it actually made a PDF file :-) Also just realized that CTM is the same thing (more or less) as java.awt.geom.AffineTransform (except the way they write their matrices). Maybe I'll see if I can substitute that in. > I was also wondering if instead of the call "LayoutManager > getLayoutManager()" it might be better to use "void > addLayoutManager(LayoutManager parent)". So in cases, for example wrapper, > where the element does not have an layout manager but there could be > multiple children that have a layout manager it will be easier to handle. > It does change how the parent layout manager handles its children. Yes that sounds good to me. Note also that I have some special handling at the Block/Line level to make the LineLayoutManager. > From the brief description of the "getNextBreakPosition" it looks like it > might be a good idea. > Keiron. > > On 2002.02.17 23:24 [EMAIL PROTECTED] wrote: > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
