Re: REDESIGN: where I have been hiding
Peter B. West wrote: I'll try to explain the algorithm a bit for line-building; maybe that will help to clarify what I meant. The TextLayoutManager generates a BreakPosition for each possible line break (not including hyphenation at first). This means breakable spaces or other possible line end characters like hard hyphens (maybe some UserAgent list of what constitutes a reasonable linebreak??). The parent of the TextLM is either an InlineLM or a LineLM. If it's an InlineLM, it just wraps the BreakPosition from the Text by adding any extra space at the inline level (space-start, space-end, padding...). At the LineLM level, the manager knows how much space it has available for the LineArea. It looks at each BreakPosition to see if it still fits in that space. When it sees one that doesn't fit (ie, the BreakPosition is beyond the end of its available inline-progression-dimension), it will then go into hyphenation mode to try to find a break between the previous BP (which still fit) and the new one. This is where it may decide on various options, such as more or less stretch in the white-space, vs hyphens in succeeding lines vs keeps etc. At the block level, the analogous logic is in the Flow LayoutManager. It will look at various BreakPositions which express how many Lines or other block-stacked Areas can fit in the current Flow Area. It makes its decision based on keep conditions and white-space stretch. Regards, Karen [EMAIL PROTECTED] wrote: 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. Karen, I like the idea of BreakPosition being constantly updated (see my notes on co-routines). What do you mean by decide on the best break? What sort of things do you see going into that decision that cannot, in essence, be decided by the child? Are you thinking about the resolution of ambiguous situations which require knowledge of partial results from a number of parallel area subtrees? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: REDESIGN: where I have been hiding
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
Re: REDESIGN: where I have been hiding
[EMAIL PROTECTED] wrote: 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. Karen, I like the idea of BreakPosition being constantly updated (see my notes on co-routines). What do you mean by decide on the best break? What sort of things do you see going into that decision that cannot, in essence, be decided by the child? Are you thinking about the resolution of ambiguous situations which require knowledge of partial results from a number of parallel area subtrees? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [PROPOSAL] linebreak was Re: REDESIGN: where I have been hiding
-Original Message- From: ewitness - Ben Fowler [mailto:[EMAIL PROTECTED]] Sent: February 18, 2002 9:36 PM To: [EMAIL PROTECTED] Subject: RE: [PROPOSAL] linebreak was Re: REDESIGN: where I have been hiding This would be useful in writing addresses exempli gratia: ?xml version=1.0 encoding=UTF-8? fo:root text-align=justified font-size=12pt font-family=serif fo:block Bilbo Baggins,fo: newline / Bag End,fo: newline / Underhill,fo: newline / Hobbiton,fo: newline / Westfarthing of the Shire. /fo:block /fo:root At present, I can get the effect I want with tables. Ben. -end of Original Message- I guess the reason nobody thought fo:br/ or fo:newline/ would be required is because a U+000A will do the trick. Thank you. I had assumed that that character would count as white space, and would be normalised away. I will try it. Ben. - My answer was so terse that maybe it sounded snippy, which was not my intention. I also can't say that FOP is up to spec with whitespace handling. I'm thinking that it's not, but I'll have to check myself. So my comments are related to the spec only. In any case, a linefeed (LF) must be honoured, and result in a linebreak. _If_ the conditions are right. What that means is, the initial value for linefeed-treatment is treat-as-space, which _does_ do a conversion of U+000A to U+0020 (space). So you would want to specify linefeed-treatment='preserve' on an ancestor flow object (possibly fo:root) and allow it to propagate to the FOs of interest, as it is inheritable. The whitespace-* properties do not affect the linefeed, and suppress-at-line-break can also be left as it is. But essentially the LF is there to accomplish what you want to do. The initial setting of linefeed-treatment acts to give us LaTeX-like behaviour, but unlike LaTeX we can switch to something different in this regard, rather than use new markup. Regards, AHS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
REDESIGN: where I have been hiding
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]
Re: REDESIGN: where I have been hiding
Karen, It's good to hear from you. In answer to your question, Yes please, personally speaking. I would like to hear, inter alia, about the timing of property resolution. Peter [EMAIL PROTECTED] wrote: 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? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
