Re: space-before in 1.0Dev
From: J.Pietschmann [EMAIL PROTECTED] Chris Bowditch wrote: I'm not sure where Layout Contexts should be instantiated. Any thoughts? The are created in the getNextBreak stuff. Yes they are created in getNextBreak and passed down to getNextBreak of child LMs, but they are not passed to the calls to addAreas (which just creates its own instance), but addAreas needs LayoutContexts for stuff such as space-before. First lets get it working, worry later about memory. The current state of the art is already wasting ressources. I couldnt agree more. Chris _ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger
Re: space-before in 1.0Dev
From: Glen Mazza [EMAIL PROTECTED] Yes, that it what I did. Thanks for your suggestion--space-before seems to work well now. Great-one step closer to a working layout in head. Chris _ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger
Re: (Joerg) Re: space-before in 1.0Dev
Not that I'm a specialist in this area, but won't fo:float also cause an fo:block to be split into multiple areas even if the block itself doesn't span multiple pages? On 11.11.2003 01:30:18 Peter B. West wrote: I've always assumed that the one or more areas are a logical consequence of the fact that generating FOs may overflow a page. Jeremias Maerki
Re: (Joerg) Re: space-before in 1.0Dev
As I read it, no more than normal. If a block contains text, the individual glyph areas will, conceptually, be assembled into line-areas. There is no FO corresponding to a line-area. Where side-floats are introduced, intrusion adjustment occurs, which may affect the placement of text in line-areas, by affecting the appropriate intrusion-adjustment of the block andor line areas. The overall IPDir geometry of the block area is not affected. Peter Jeremias Maerki wrote: Not that I'm a specialist in this area, but won't fo:float also cause an fo:block to be split into multiple areas even if the block itself doesn't span multiple pages? -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: (Joerg) Re: space-before in 1.0Dev
Peter B. West wrote: Recall that the contents of fo:block are defined as (#PCDATA|%inline;|%block;)* and that there are some interesting complications in the contents of inline; which, frankly, I still don't understand in spite of clarifications from the editors. One complication is whitespace because of the unfortunate mix of block level FO and text. There's also the unpleasant problem that fo:block fo:marker... may unexpectedly trigger a fatal error because of the whitespace before the fo:marker. Yeah, unintended consequences of seemingly easy and straightforward definitions. Doh. J.Pietschmann
Re: space-before in 1.0Dev
From: Glen Mazza [EMAIL PROTECTED] That *could* be a solution--I added toString() methods in the LayoutContext to help track the state of values in that class. Glen Thanks to Glen and Joerg for replying to this. Setting FIRST/LAST flags on LayoutContext in the layoutMgr.addArea code isnt enough to solve this problem. I tried it and results were undesirable. With every new page, the Page LM addAreas gets called again, and so FIRST gets set again. So I'm not sure where Layout Contexts should be instantiated. Any thoughts? One possible workaround is for Layout Managers to record this state themselves. Not sure if thats acceptable though as it means greater memory consumption. Chris _ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband
Re: space-before in 1.0Dev
I'm still analyzing the problem at this time. --- Chris Bowditch [EMAIL PROTECTED] wrote: From: Glen Mazza [EMAIL PROTECTED] That *could* be a solution--I added toString() methods in the LayoutContext to help track the state of values in that class. Glen Thanks to Glen and Joerg for replying to this. Setting FIRST/LAST flags on LayoutContext in the layoutMgr.addArea code isnt enough to solve this problem. I tried it and results were undesirable. With every new page, the Page LM addAreas gets called again, and so FIRST gets set again. So I'm not sure where Layout Contexts should be instantiated. Any thoughts? One possible workaround is for Layout Managers to record this state themselves. Not sure if thats acceptable though as it means greater memory consumption. Chris _ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: space-before in 1.0Dev
Chris Bowditch wrote: I'm not sure where Layout Contexts should be instantiated. Any thoughts? The are created in the getNextBreak stuff. I'm sure conditional spaces as well as keeps and proper line breaking will need enhancements, in particular an object holding the cond-space state across the various getNextBreak invocations. One possible workaround is for Layout Managers to record this state themselves. Not sure if thats acceptable though as it means greater memory consumption. First lets get it working, worry later about memory. The current state of the art is already wasting ressources. J.Pietschmann
(Joerg) Re: space-before in 1.0Dev
Question, Joerg, we implement fo:block as multiple Area.Blocks in those cases where an fo:block would consume more than one page (or, more precisely, its assigned region on the page). One Area.Block for each page the fo:block consumes. I am assuming this is just an implementation convenience for us--just to confirm, the spec does allow for an fo:block to consume more than one page, correct? I wasn't able to find otherwise. Glen --- J.Pietschmann [EMAIL PROTECTED] wrote: First lets get it working, worry later about memory. The current state of the art is already wasting ressources. +1 __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: (Joerg) Re: space-before in 1.0Dev
Glen Mazza wrote: I am assuming this is just an implementation convenience for us--just to confirm, the spec does allow for an fo:block to consume more than one page, correct? I wasn't able to find otherwise. Well, the spec always has this phrase one or more areas. It doesn't really explicitely deal with how multiple areas come into existence and whether it is one area per page, although there are the constraints on the area tree which indicate it has to be this way. J.Pietschmann
Re: (Joerg) Re: space-before in 1.0Dev
I've always assumed that the one or more areas are a logical consequence of the fact that generating FOs may overflow a page. The area tree describes laid-out areas to be rendered on some medium, and every area which describes a mark on a page must have a region in its ancestry, we are obliged to consider individual FOs fragmented into more than one area. Peter J.Pietschmann wrote: Glen Mazza wrote: I am assuming this is just an implementation convenience for us--just to confirm, the spec does allow for an fo:block to consume more than one page, correct? I wasn't able to find otherwise. Well, the spec always has this phrase one or more areas. It doesn't really explicitely deal with how multiple areas come into existence and whether it is one area per page, although there are the constraints on the area tree which indicate it has to be this way. J.Pietschmann -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: (Joerg) Re: space-before in 1.0Dev
Thank you both for the clarifications. --- Peter B. West [EMAIL PROTECTED] wrote: The area tree describes laid-out areas to be rendered on some medium, and every area which describes a mark on a page must have a region in its ancestry, we are obliged to consider individual FOs fragmented into more than one area. I see...so there is a parent-child relationship between a region and area, meaning larger fo:blocks will need to be broken up into multiple areas so those areas can be applied to the regions on the following pages. Glen __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: (Joerg) Re: space-before in 1.0Dev
Glen Mazza wrote: Thank you both for the clarifications. --- Peter B. West [EMAIL PROTECTED] wrote: The area tree describes laid-out areas to be rendered on some medium, and as every area which describes a mark on a page must have a region in its ancestry, we are obliged to consider individual FOs fragmented into more than one area. I see...so there is a parent-child relationship between a region and area, meaning larger fo:blocks will need to be broken up into multiple areas so those areas can be applied to the regions on the following pages. That's it. In general, there is an active hierarchy of FOs at any page break. Recall that the contents of fo:block are defined as (#PCDATA|%inline;|%block;)* and that there are some interesting complications in the contents of inline; which, frankly, I still don't understand in spite of clarifications from the editors. Pages can break in the most unfortunate places. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: space-before in 1.0Dev
--- Chris Bowditch [EMAIL PROTECTED] wrote: One possible workaround is for Layout Managers to record this state themselves. Not sure if thats acceptable though as it means greater memory consumption. Chris Yes, that it what I did. Thanks for your suggestion--space-before seems to work well now. Glen __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: space-before in 1.0Dev
--- Chris Bowditch [EMAIL PROTECTED] wrote: Is the LayoutContext object supposed to be the mechanism for checking such state? Currently LayoutContexts in the parent FlowLayoutManager are created with flags=0. Do you think it should be setting FIRST, LAST, etc? That *could* be a solution--I added toString() methods in the LayoutContext to help track the state of values in that class. Glen __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
space-before in 1.0Dev
Hi Glen and other devs, I'm responding to an earlier message where you said: quote Another issue I was working on last weekend--still unsolved--was that in 1.0 layout, fo:block space-before is being added to the top of *each* page that the block consumes (instead of just once at the top of the block). This may take some time to fix--I'll keep working on it. /quote how far did you get with this? I had a spare few minutes and had a look as well. I may be well off base with this as I'm new to the code: The BlockLayoutManager.addAreas seems to be responsible for adding space before/after. Currently there is no check to see whether or not this is the first/last call to addAreas. Is the LayoutContext object supposed to be the mechanism for checking such state? Currently LayoutContexts in the parent FlowLayoutManager are created with flags=0. Do you think it should be setting FIRST, LAST, etc? Any insight would be appreciated, Chris _ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess
Re: space-before in 1.0Dev
Chris Bowditch wrote: The BlockLayoutManager.addAreas seems to be responsible for adding space before/after. Currently there is no check to see whether or not this is the first/last call to addAreas. Is the LayoutContext object supposed to be the mechanism for checking such state? I think so. J.Pietschmann
