Re: Tasks - layout
On Wed, 2002-08-21 at 23:29, Karen Lease wrote: > Hi Keiron, > > Keiron Liddle wrote: > > > > > > The line height calculation and alignment is only very basic at the moment. > > The idea is that the LineLM gets certain information to find the offset to > > baseline and total line height and when the InlineLM add areas they use this > > information to set the position of the inline areas. > > > > > Yes, I noticed that you'd added this as well to the information returned in the >BreakPoss. I worked out some alignment and ipd adjustment things. This look like it can work in a similar way. There is one tricky part, the ipd of the text parts accumulate. This means that to find the total ipd of a line break it needs to add the last ipd of each layout manager. > Now that it looks like things are heating up, we probably do need to do > some cleanup before we get too much more code written. I agree with > Joerg that we could simplify the inheritance now that we are only using > the BP stuff. It wouldn't be so much work at this point to fold the BP > versions back into the original interface and AbstractLM and to rename > LineBP and TextBP. What do you think? I agree, the BP letters don't really add much information now anyway. > The other thing I have been thinking about is how to structure the > information we are returning in BreakPoss (besides the actual position > part). In fact, it's really the same (more or less) information which > we'll end up putting on the final Area we create, since a BreakPoss is > really just a potential Area. I was wondering a while back whether we > should just encapsulate an Area directly in the BreakPoss and use that > to store the size information. On the other hand, some information won't > be needed on the final areas (once they are positioned) such as the > MinOptMax space around the area, the keep constraints etc, which are > only used by the LayoutManagers while decided which BreakPoss to > actually use to create the Area. I think this needs to come out from the functionality. If there is too much on the area tree it will need to cleared at some stage. > Another general LM issue involves at which level to take into account > the stacksize limit. For the inline stuff, I only used it at the LineLM > level. I just had the lower level LM return each possible line-end and > then let the LineLM decide whether it fit or not. When it got a > BreakPoss which was too big, it could then decide to hyphenate, which > means going into a kind of mode where it examines less optimal breaks. > > The equivalent of that logic on the block stacking level could be to > have all block-level LM except the FlowLM return fairly large chunks > (between block-level FOs for example) and then have the FlowLM ask them > to break the block into smaller pieces when it gets a BreakPoss which > overflows the current column size. I was originally thinking of having > the block-level LM return on every Line, but that makes a lot of work > and a lot of object creation, so it would probably be slow. I was thinking that it could return a break only if it is better or the same or if past the end. This way a block would only have one break position most of the time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Karen Lease wrote: > ..., since a BreakPoss is > really just a potential Area. Just nitpicking: It is the state of a LM tree, and in that sense certainly a bit more than a potential area. > The equivalent of that logic on the block stacking level could be to > have all block-level LM except the FlowLM return fairly large chunks > (between block-level FOs for example) and then have the FlowLM ask them > to break the block into smaller pieces when it gets a BreakPoss which > overflows the current column size. I was originally thinking of having > the block-level LM return on every Line, but that makes a lot of work > and a lot of object creation, so it would probably be slow. I'm not sure whether a lot of object creation has to take place. Anyway, why not pass the stack size to the block and let it return if it *has* to break, and let the parent ask for earlier breaks only if this does not reconcile well with other conditions, for example when reconciling breaks in the cells of a table row or for list items. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Hi Keiron, Keiron Liddle wrote: > > The line height calculation and alignment is only very basic at the moment. > The idea is that the LineLM gets certain information to find the offset to > baseline and total line height and when the InlineLM add areas they use this > information to set the position of the inline areas. > > Yes, I noticed that you'd added this as well to the information returned in the BreakPoss. Now that it looks like things are heating up, we probably do need to do some cleanup before we get too much more code written. I agree with Joerg that we could simplify the inheritance now that we are only using the BP stuff. It wouldn't be so much work at this point to fold the BP versions back into the original interface and AbstractLM and to rename LineBP and TextBP. What do you think? The other thing I have been thinking about is how to structure the information we are returning in BreakPoss (besides the actual position part). In fact, it's really the same (more or less) information which we'll end up putting on the final Area we create, since a BreakPoss is really just a potential Area. I was wondering a while back whether we should just encapsulate an Area directly in the BreakPoss and use that to store the size information. On the other hand, some information won't be needed on the final areas (once they are positioned) such as the MinOptMax space around the area, the keep constraints etc, which are only used by the LayoutManagers while decided which BreakPoss to actually use to create the Area. Another general LM issue involves at which level to take into account the stacksize limit. For the inline stuff, I only used it at the LineLM level. I just had the lower level LM return each possible line-end and then let the LineLM decide whether it fit or not. When it got a BreakPoss which was too big, it could then decide to hyphenate, which means going into a kind of mode where it examines less optimal breaks. The equivalent of that logic on the block stacking level could be to have all block-level LM except the FlowLM return fairly large chunks (between block-level FOs for example) and then have the FlowLM ask them to break the block into smaller pieces when it gets a BreakPoss which overflows the current column size. I was originally thinking of having the block-level LM return on every Line, but that makes a lot of work and a lot of object creation, so it would probably be slow. For tables, I'd be tempted to always have the first layout pass return only breaks at row boundaries (or groups of rows linked by spanning cells) and only get into row-breaking logic if a) the row doesn't fit and there is no previous "good" break; b) the row and its cells don't have keep-together=always. Of course, if we get a row or a row group which is already starting a page and still won't fit, we have to break it anyway (or overflow it) in order to avoid the infinite loop problem. As you and Joerg were discussing the other day, exactly how to do the breaking in the row is very complex. If we try to optimize it we will get into some very deep decision trees with breaks in each cell. I tend to think that most tables should be set up to have keep-together=always. (Hint to the users!) On the other hand, there are cases where people are using tables to get some kind of special layout effect (unequal columns for example) and they want the cells to be able to be broken, so we can't get around this in the long run. Regards, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Hi Tony, Thanks for the advice. I have already started to look at the OpenType standard, in particular the parts describing the various baselines. Unfortunately I don't suppose I'll be attending the Unicode conference but perhaps someone here will be and could listen to Steve's talk and could report back to the group. However, it seems clear that FOP will definitely need to enhance the information it is managing about Fonts in order to provide the baseline information needed to implement these aspects of the spec. Regards, Karen Tony Graham wrote: > Karen Lease wrote at 20 Aug 2002 23:07:46 +0200: > > That would be good. I haven't looked at it for a month or so, but I had > > (as usual) some questions about various statements in the XSL-FO spec > > concerning the interpretation of the various properties. Perhaps we > > could go over those issues at some point. > > > Arved Sandstrom wrote: > > > > >>-Original Message- > > >>From: Karen Lease [mailto:[EMAIL PROTECTED]] > > > >>With regard to the line-height calculations, is anybody in the group > > >>interested in getting into the gory details of the baseline stuff for > > >>different scripts? I spent some time poring over the spec and trying to > > >>get a handle on this, but maybe it's too much detail for now. On the > > >>other hand, I'd really like to make sure that this version of FOP > > >>handles that stuff correctly as well as being able to do the various > > >>kinds of line-stacking strategies defined by the XSL-FO spec. > > >> > > > > > > I am definitely interested. I have put some thought into these things > > > already. Granted, when I implement it'll be a different codebase but I am > > > happy to work out the details on this list. > > You may be interested in Steve Zilles's statement in the abstract [1] > for his talk at next month's Unicode Conference where he says: > >The extended CSS/XSL model is based on the Open Type font >model. This model posits a set of alignment baselines for different >scripts, e.g., alphabetic, ideographic and hanging scripts. This >allows characters in a given script, but presented in different >font sizes, to be aligned on the baseline natural to that script. > > I just looked in the XSL Recommendation, and Section 7.8.1 notes: > >XSL uses an abstract model of a font. This model is described in >this section and is based on current font technology as exemplified >by the OpenType specification [OpenType]. > > Maybe you also need to look at the OpenType spec. > > Regards, > > > Tony Graham > > XML Technology Center - Dublinmailto:[EMAIL PROTECTED] > Sun Microsystems Ireland Ltd Phone: +353 1 8199708 > Hamilton House, East Point Business Park, Dublin 3x(70)19708 > > > [1] http://www.unicode.org/iuc/iuc22/a365.html > > - > 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: Tasks - layout
Karen Lease wrote at 20 Aug 2002 23:07:46 +0200: > That would be good. I haven't looked at it for a month or so, but I had > (as usual) some questions about various statements in the XSL-FO spec > concerning the interpretation of the various properties. Perhaps we > could go over those issues at some point. ... > Arved Sandstrom wrote: > > >>-Original Message- > >>From: Karen Lease [mailto:[EMAIL PROTECTED]] ... > >>With regard to the line-height calculations, is anybody in the group > >>interested in getting into the gory details of the baseline stuff for > >>different scripts? I spent some time poring over the spec and trying to > >>get a handle on this, but maybe it's too much detail for now. On the > >>other hand, I'd really like to make sure that this version of FOP > >>handles that stuff correctly as well as being able to do the various > >>kinds of line-stacking strategies defined by the XSL-FO spec. > >> > > > > I am definitely interested. I have put some thought into these things > > already. Granted, when I implement it'll be a different codebase but I am > > happy to work out the details on this list. You may be interested in Steve Zilles's statement in the abstract [1] for his talk at next month's Unicode Conference where he says: The extended CSS/XSL model is based on the Open Type font model. This model posits a set of alignment baselines for different scripts, e.g., alphabetic, ideographic and hanging scripts. This allows characters in a given script, but presented in different font sizes, to be aligned on the baseline natural to that script. I just looked in the XSL Recommendation, and Section 7.8.1 notes: XSL uses an abstract model of a font. This model is described in this section and is based on current font technology as exemplified by the OpenType specification [OpenType]. Maybe you also need to look at the OpenType spec. Regards, Tony Graham XML Technology Center - Dublinmailto:[EMAIL PROTECTED] Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 [1] http://www.unicode.org/iuc/iuc22/a365.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Hi Karen, On Mon, 2002-08-19 at 23:57, Karen Lease wrote: > Hi Keiron etc, > > I'm really happy to see all this movement going on and folks from the > "maintenance" branch getting into the redesign to help you out. I'm > hoping to be able to start contributing again too, perhaps not right > away, but hopefully in September. There may even be some possibility of > getting to work on FOP as part of my "real" work, though it might be > hard to work on the new layout in that context. I'll keep the group posted. Sounds good. > I'll start by looking at the latest and then maybe cogitating on list or > table layout, depending on the timing and what others are interested in > doing. It looks like status.xml is the sign-up sheet for the tasks; is > that right? Yes, the status is keeping track of things. Which reminds me there are some missing entries for Kevin and Rhett and some others who are working on certain areas. > With regard to the line-height calculations, is anybody in the group > interested in getting into the gory details of the baseline stuff for > different scripts? I spent some time poring over the spec and trying to > get a handle on this, but maybe it's too much detail for now. On the > other hand, I'd really like to make sure that this version of FOP > handles that stuff correctly as well as being able to do the various > kinds of line-stacking strategies defined by the XSL-FO spec. Plenty of tricky things in that area. The line height calculation and alignment is only very basic at the moment. The idea is that the LineLM gets certain information to find the offset to baseline and total line height and when the InlineLM add areas they use this information to set the position of the inline areas. > Regards, > Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Arved, That would be good. I haven't looked at it for a month or so, but I had (as usual) some questions about various statements in the XSL-FO spec concerning the interpretation of the various properties. Perhaps we could go over those issues at some point. Karen Arved Sandstrom wrote: >>-Original Message- >>From: Karen Lease [mailto:[EMAIL PROTECTED]] >>Sent: August 19, 2002 6:58 PM >>To: [EMAIL PROTECTED] >>Subject: Re: Tasks - layout >> >> > [ SNIP ] > >>With regard to the line-height calculations, is anybody in the group >>interested in getting into the gory details of the baseline stuff for >>different scripts? I spent some time poring over the spec and trying to >>get a handle on this, but maybe it's too much detail for now. On the >>other hand, I'd really like to make sure that this version of FOP >>handles that stuff correctly as well as being able to do the various >>kinds of line-stacking strategies defined by the XSL-FO spec. >> > > I am definitely interested. I have put some thought into these things > already. Granted, when I implement it'll be a different codebase but I am > happy to work out the details on this list. > > Arved > > > - > 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: Tasks - layout
On Mon, 2002-08-19 at 23:13, J.Pietschmann wrote: > Keiron Liddle wrote: > > - Implement table layout > > The table layout will use the same technique as the block layout. It > > will locate suitable breaks between rows or inside rows until table > > finished or end of bpd reached. > > Actually, what *are* valid breaks within a table apart from breaks > between two rows with no cell spanning both? > > Some interesting situations: > > +-++ > |block|block 1 | > | |block 2 | > +-++ > Break possibility after block 1 if > BPD(block) +-++ > |block|block 1 | > +-++ > --- > +-++ > | |block 2 | > +-++ For this case I would say it is a valid break. Because table row can have keep together which only makes sense if the row can be split when there is no keep. > +-++ > |block block block|block 1 | > |block block block++ > |block block |block 2 | > +-++ > Break possibility after row one, despite that > the cell with block 1 would have to get some > space after the block, i.e. > +-++ > |block block block|block 1 | > |block block block|| > |block block ++ > --- > | ++ > | |block 2 | > +-++ It should be possible to get a break inside a cell but I don't know how the break should be found across the row. What happens if there is a page-break inside a cell. Do other cells go to the end of the page or to their limit? or should the break be at the same position across the row. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
On Mon, 2002-08-19 at 22:58, J.Pietschmann wrote: > Keiron Liddle wrote: > > - Add markers to page when areas added > Is this really a good idea? Markers may be referenced > long after they have been defined, tying them to the > Page object would require keeping the pages in memory > (see 0.20.5cvs: forward page references are *required* > to force keeping pages in memory so that markers can > be retrieved with document scope). I thought the markers only apply to the current page but I haven't really looked into it. If it does apply to pagesequence/document then it should be on the page viewport like the id references, so that the page can be removed leaving relevent information for use later. There may be other places to keep the markers but the area tree might be easier to keep track of. > I thought about adding a running number for the page > sequence and for the page within it's page sequence > as well as the necessary information to make retrieving > markers within a page work properly to the marker itself > and store them in an Array list, with the current page > perhaps storing the array index of the first marker of > this page to speed up some retrieval modes. Page numbers would be good. I think that you only need at most four markers of a particular class per page, so if it is a dictionary type case it doesn't need all the markers in the middle of the page with the same class. > J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tasks - layout
> -Original Message- > From: Karen Lease [mailto:[EMAIL PROTECTED]] > Sent: August 19, 2002 6:58 PM > To: [EMAIL PROTECTED] > Subject: Re: Tasks - layout > [ SNIP ] > With regard to the line-height calculations, is anybody in the group > interested in getting into the gory details of the baseline stuff for > different scripts? I spent some time poring over the spec and trying to > get a handle on this, but maybe it's too much detail for now. On the > other hand, I'd really like to make sure that this version of FOP > handles that stuff correctly as well as being able to do the various > kinds of line-stacking strategies defined by the XSL-FO spec. I am definitely interested. I have put some thought into these things already. Granted, when I implement it'll be a different codebase but I am happy to work out the details on this list. Arved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Hi Keiron etc, I'm really happy to see all this movement going on and folks from the "maintenance" branch getting into the redesign to help you out. I'm hoping to be able to start contributing again too, perhaps not right away, but hopefully in September. There may even be some possibility of getting to work on FOP as part of my "real" work, though it might be hard to work on the new layout in that context. I'll keep the group posted. I'll start by looking at the latest and then maybe cogitating on list or table layout, depending on the timing and what others are interested in doing. It looks like status.xml is the sign-up sheet for the tasks; is that right? With regard to the line-height calculations, is anybody in the group interested in getting into the gory details of the baseline stuff for different scripts? I spent some time poring over the spec and trying to get a handle on this, but maybe it's too much detail for now. On the other hand, I'd really like to make sure that this version of FOP handles that stuff correctly as well as being able to do the various kinds of line-stacking strategies defined by the XSL-FO spec. Regards, Karen Keiron Liddle wrote: > Now that we have some pagination there are lots of areas that people can > work on. > If you want to implement any of these and have any questions then just > ask. > > Once we can get a few of these done then we could do a developers > release. > > > - Add static areas to page > The static areas will need to be handled in a similar way to the flow > except the bpd is unlimited and it will need to reset and repeat for > each page. > > > - Add id areas to page when area added > When the layout managers add an area to the page it can also add the id > information. > > > - Resolve id references on other pages, extensions > When an id is added to a page this will allow id references to be > resolved. > > > - Add markers to page when areas added > When an area is added that is created by an FO that contains markers > then the markers can also be added. There are four types of positions > for markers. > > > - Retrieve markers from page > When doing the static areas the markers wil need to be available for > retrieving. The marker can then be layed out as normal. > > > - calculate line height > The line height needs to be calculated while finding breaks. This needs > to include all the alignment and height details of the inline areas. > > > - Various inline objects > Page number, page number citation etc. need to be implemented. > > > - Implement page caching > If a page need to be stored for the store pages or waiting to resolve > forward references then we need a cache mechanism to save the page > somewhere. > > > - Implement table layout > The table layout will use the same technique as the block layout. It > will locate suitable breaks between rows or inside rows until table > finished or end of bpd reached. > > > - Implement list layout > The list layout like the table layout will be looking for suitable > breaks from the child objects. The it will add the appropriate areas to > the area tree. > > > - Get bookmark extension working > Make sure the extension id references are resolved. Once the data is > fully resolved then implement a way for the pdf renderer to add the > bookmarks. See branch for code how to add bookmarks. > > > These are just some of the things, I will add them to the todo list. > If there is a decent response then there are more that can be added. > > > > > - > 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: Tasks - layout
Keiron Liddle wrote: > - Implement table layout > The table layout will use the same technique as the block layout. It > will locate suitable breaks between rows or inside rows until table > finished or end of bpd reached. Actually, what *are* valid breaks within a table apart from breaks between two rows with no cell spanning both? Some interesting situations: +-++ |block|block 1 | | |block 2 | +-++ Break possibility after block 1 if BPD(block)
Re: Tasks - layout
Keiron Liddle wrote: > - Add markers to page when areas added Is this really a good idea? Markers may be referenced long after they have been defined, tying them to the Page object would require keeping the pages in memory (see 0.20.5cvs: forward page references are *required* to force keeping pages in memory so that markers can be retrieved with document scope). I thought about adding a running number for the page sequence and for the page within it's page sequence as well as the necessary information to make retrieving markers within a page work properly to the marker itself and store them in an Array list, with the current page perhaps storing the array index of the first marker of this page to speed up some retrieval modes. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Keiron Liddle wrote: > Of course, but how can we make it understandable. The problems I had - I was not able to follow the control flow. Too many classes/instances involved in even a few lines of code, too many indirections through custom iterators. I had to insert a few dumpStack(), which I did only once before (in Excalibur of course). - Too many classes in general. - Deep inheritance trees. - Parallel object/inheritance trees. - The state of some important objects is smeared across classes in the inheritance tree as well as auxillary classes. - Inconsistent and in some cases plainly misleading packages. - A few misleading comments. - Distracting style issues. Some hints to possibly improve it: - Will layout managers ever be about something else that break possibilities? If not, discard the BPLayoutManager and the AbstractBPLayoutManager from the hierarchy. (Otherwise, why is LeafNodeLayoutManager not directly derived from AbstractLayoutManager?) - Will positions ever be used to indicate something else that break possiblities? If not, use BreakPoss and LeafBreakPoss and NonLeafBreakPoss instead. This way it should also be possible to get rid of BreakPossPosIterator. - In general, encapsulate iterators otherwise, at least do not use them in method signatures as parameters. - Do something about the responsibilities of StructureHandler, AreaTree and Renderer. - In general, don't be too greedy and derive a class from another to inherit a few short methods. Dont overuse inheritance for code reuse. - Make methods abstract if they are abstract instead of providing an empty implementation (resetPosition() in particular). >>I took a stab at the static content layout and ... ..it does not work, because BlockLayoutManager inherits the no-op implementation of resetPosition() from Abstract...whatever...LayoutManager. Therefore, the block(s) in the static content are never reset, and the content is only printed on the first page :-( This should be easy to fix for you. >>Actually, how is "unlimited" expressed in MinOptMax terms? > I could imagine that it might adjust to the size of the region. So if > larger it uses min value etc. Static content is laid out after the main flow, so the page viewport should already have been adjusted to the real page if necessary. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
On Sun, 2002-08-18 at 02:07, J.Pietschmann wrote: > Keiron Liddle wrote: > > I don't think we should expect or even want people to understand > > everything. > > I think it's preferable that people hacking around in the > code understand *something*. Of course, but how can we make it understandable. > I took a stab at the static content layout and even get Great! > some text but AcrobatReader complains about "Font not > set" if there is static content. Also, the static content > is always rendered into the upper left cornder, regardless > which region it should be in. Meanwhile I'm completely > out of ideas where to look, especially for the font issue. Since each region is in its own graphics state the font needs to be set at a higher state of for the text in each region. The problem was that the last font state was kept from the last region. The regions seem to be put in the right place for me, maybe the viewer got an error so stopped doing things properly. > Actually, how is "unlimited" expressed in MinOptMax terms? > Stuffing in a "large number" doesn't strike me as very clean. > I settled for the page BPD, under the assuption that the > page viewport would not exceed this. I'm not sure. I could imagine that it might adjust to the size of the region. So if larger it uses min value etc. > J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Keiron Liddle wrote: > I don't think we should expect or even want people to understand > everything. I think it's preferable that people hacking around in the code understand *something*. I took a stab at the static content layout and even get some text but AcrobatReader complains about "Font not set" if there is static content. Also, the static content is always rendered into the upper left cornder, regardless which region it should be in. Meanwhile I'm completely out of ideas where to look, especially for the font issue. > No for a static area all areas are placed into the static region. So > that the block progression dimension is unlimited. The clipping and > overflow determine what happens when rendering the things outside the > viewport. Actually, how is "unlimited" expressed in MinOptMax terms? Stuffing in a "large number" doesn't strike me as very clean. I settled for the page BPD, under the assuption that the page viewport would not exceed this. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
On Wed, 2002-08-14 at 22:06, J.Pietschmann wrote: > Keiron Liddle wrote: > > - Add static areas to page > > The static areas will need to be handled in a similar way to the flow > > except the bpd is unlimited and it will need to reset and repeat for > > each page. > > I looked at it. Is static content supposed to be handled > by a FlowLayoutManager too? It seems a bit too specialized > to a fo:flow to me. I would think it would be another class but quite the same. It does the same thing except it doesn't find breaks it just adds all areas. > I think I understand now why the design of HEAD is as > it is now. I still think there are better possibilities, > perhaps deriving classes representing FOs from layout > manager classes, thereby avoiding communication between > the objects representing FOs and the associated layout > managers. I want A solution, the current one is the closest we have right now. > Does anybody dare to apply an OO metric to HEAD? Deeply > nested inheritance trees, lots of communications from > everywhere to everywhere... I'd bet the complexity is > just a notch below "for supergeniuses only", which would > nicely fit the unusual long time it took me to grasp > why *anything* is laid out at all. I haven't noticed lots of communication everywhere to everywhere, most of it is single direction or single purpose. The layout context and break possibility make things a bit confusing. The complexity of the layout means that a lot of this is necessary. I don't think we should expect or even want people to understand everything. In a way understanding the layout *is* understanding the spec except it is done in a particular way. > And: > > except the bpd is unlimited > You mean "limited", do you? No for a static area all areas are placed into the static region. So that the block progression dimension is unlimited. The clipping and overflow determine what happens when rendering the things outside the viewport. > J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Keiron Liddle wrote: > - Add static areas to page > The static areas will need to be handled in a similar way to the flow > except the bpd is unlimited and it will need to reset and repeat for > each page. I looked at it. Is static content supposed to be handled by a FlowLayoutManager too? It seems a bit too specialized to a fo:flow to me. I think I understand now why the design of HEAD is as it is now. I still think there are better possibilities, perhaps deriving classes representing FOs from layout manager classes, thereby avoiding communication between the objects representing FOs and the associated layout managers. Does anybody dare to apply an OO metric to HEAD? Deeply nested inheritance trees, lots of communications from everywhere to everywhere... I'd bet the complexity is just a notch below "for supergeniuses only", which would nicely fit the unusual long time it took me to grasp why *anything* is laid out at all. And: > except the bpd is unlimited You mean "limited", do you? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
On Wed, 2002-08-14 at 08:32, Kevin O'Neill wrote: > > - Reusing pdf objects that links create > > What do you mean ... sorry for being dim. The same as I did for the GState and patterns. If a link is added that has the same action or destination URL as a previous link. Then use the pdf objects with the actions etc. again. So for example if a document has 100 links that point to the same URL then it will only create one URL destination object instead of 100 (or whatever objects it creates I don't have the code in front of me right now). This could be done along the lines of: - create an equals method in the objects that will be reused. - when adding a new link then check if the pdf object already exists and use the old one instead. > > - form XObject > > Already started, I need it for some imposition code I'm working on > (unless someone can think of a better way to do impositioning of pages). Great! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
On Wed, 2002-08-14 at 16:16, Keiron Liddle wrote: > - Encryption and signing Started looking at it (though I'm not using it at the moment and I'm a little driven by the things I need :)). > - Reusing pdf objects that links create What do you mean ... sorry for being dim. > - form XObject Already started, I need it for some imposition code I'm working on (unless someone can think of a better way to do impositioning of pages). > Those are the main ones I can think of. -- If you don't test then your code is only a collection of bugs which apparently behave like a working program. Website: http://radio.weblogs.com/0111457/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
On Mon, 2002-08-12 at 13:44, Kevin O'Neill wrote: > > These are just some of the things, I will add them to the todo list. > > If there is a decent response then there are more that can be added. > > Any PDF tasks? - Encryption and signing - Reusing pdf objects that links create - form XObject Those are the main ones I can think of. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
Kevin O'Neill wrote: > Any PDF tasks? > Encryption related stuff seems to be often asked for. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tasks - layout
> These are just some of the things, I will add them to the todo list. > If there is a decent response then there are more that can be added. Any PDF tasks? -- If you don't test then your code is only a collection of bugs which apparently behave like a working program. Website: http://radio.weblogs.com/0111457/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
