border-before-width length-conditional
Am I right that for a table-cell in collapsing border model the conditional part of a length-conditional (ex. in border-before-width) has no effect (i.e. is ignored)? Thanks, Jeremias Maerki
RE: border-before-width length-conditional
Jeremias Maerki wrote: Am I right that for a table-cell in collapsing border model the conditional part of a length-conditional (ex. in border-before-width) has no effect (i.e. is ignored)? That doesn't sound right. I just did a cursory review of the standard and can't find any support for that. However, the standard has a way of humbling me from time to time, so I may have missed it. Victor Mote
Re: border-before-width length-conditional
Then, I'm wondering how to handle the conditional part (7.7.9) in this case because I don't have a clue and it seems not to go well with the collapsing nature of these borders as well as the rules 1-5 in 6.7.10 for border-collapse=collapse. Also, I don't think the associated edge is (can be) a leading edge in a reference area from this (table-cell, table-row, table-body) formatting object. H. On 21.02.2005 18:11:22 Victor Mote wrote: Jeremias Maerki wrote: Am I right that for a table-cell in collapsing border model the conditional part of a length-conditional (ex. in border-before-width) has no effect (i.e. is ignored)? That doesn't sound right. I just did a cursory review of the standard and can't find any support for that. However, the standard has a way of humbling me from time to time, so I may have missed it. Victor Mote Jeremias Maerki
Re: border-before-width length-conditional
Jeremias Maerki a écrit : Am I right that for a table-cell in collapsing border model the conditional part of a length-conditional (ex. in border-before-width) has no effect (i.e. is ignored)? I would answer no, actually not exactly. If I understand the spec correctly, the conditional part has an effect only if the generated area begins an ancestor reference area. Let's take the example of border-before. If there is a cell before the current cell we don't care about the conditionality: we just have to chose between this border, the border-after of the preceding cell, and the border-after and border-before of the containing table-rows. Now if the table has to be broken at the end of a page and the current cell begins a new page (and no border is specified for the table-row), in this case the conditionality has to be taken in consideration. Because the cell would be a leading edge in the normal-flow-reference-area of the page, as defined at the end of section 4.2.5, Stacking Constraints. Does it answer your question? I may have missed something, I have not carefully studied this aspect of the spec nor the border-collapsing model. Hope this helps, Vincent
Re: border-before-width length-conditional
Ah yes, that makes sense. Thanks a lot Vincent. I didn't think about that. On 21.02.2005 21:54:19 Vincent Hennebert wrote: Jeremias Maerki a écrit : Am I right that for a table-cell in collapsing border model the conditional part of a length-conditional (ex. in border-before-width) has no effect (i.e. is ignored)? I would answer no, actually not exactly. If I understand the spec correctly, the conditional part has an effect only if the generated area begins an ancestor reference area. Let's take the example of border-before. If there is a cell before the current cell we don't care about the conditionality: we just have to chose between this border, the border-after of the preceding cell, and the border-after and border-before of the containing table-rows. Now if the table has to be broken at the end of a page and the current cell begins a new page (and no border is specified for the table-row), in this case the conditionality has to be taken in consideration. Because the cell would be a leading edge in the normal-flow-reference-area of the page, as defined at the end of section 4.2.5, Stacking Constraints. Does it answer your question? I may have missed something, I have not carefully studied this aspect of the spec nor the border-collapsing model. Hope this helps, Vincent Jeremias Maerki
Re: another nose for the grindstone
bonjour fop-devs i would like to work on the awt renderer. Mark (or someone else) , are you working on it? i checked out the code from FOP 0.20.5. is it the latest maintenance version? thanks, renaud On Mon, 17 Jan 2005 10:54:43 +0100, Jeremias Maerki [EMAIL PROTECTED] wrote: Hi Mark We'd love to have you with us. On 17.01.2005 05:18:23 Mark Brucks wrote: I'd like to join the fop development group. I've been an xsl/fop user for the last year or so (generating PDF), but several new projects I'm proposing have a need for a robust and complete awt renderer, and I'd like to devote some time to ensuring this happens. I have a little bit of time in the near term to commit to the project, and I hope much more time starting in the April time frame. I'd like to use the next 2 months to come up to speed, then dive in to serious work when more time is available. The AWT renderer is currently missing in CVS HEAD. It would be great if someone took up that task. To build that renderer you can look at the code from the maintenance branch (or FOP 0.20.5) for reference. Our reference renderer in CVS HEAD is the PDF renderer (like before). Personally, I'd rather call it Java2D renderer, not AWT renderer, because Java2D is essentially the name of the API you code against. AWT is, as the name says, a windowing toolkit, not primarily a graphics API. I need some advice. I've learned enough about xsl and fop to get my job done, but there are lots of holes in my knowledge base. I'd like to spend a little bit of time carefully reading the XSL spec. Should I read the XSL V1.1 working draft (in anticipation of things to come), or should I stick with the V1.0 recommendation (which I assume is what the new version of fop will implement). The recommendation is still the main reference. Glen Mazza already started investigating the 1.1 WD (ex. bookmarks) and it might be helpful sometimes to consult the 1.1 WD because it seems to be somewhat more verbose. It's good to prepare for 1.1 but as long as it's in WD phase the focus should remain on the 1.0 Rec for the time being. Do the development and design documents that are available on-line relate to the root/trunk/redesign version, or do they still describe the maintenance branch? They refer to CVS HEAD. If they are not up-to-date, they should be updated. Is there a development schedule or a prioritized list of features to be implemented? A development schedule is always difficult in an all-volunteer project. I think it's pretty realistic now to target an initial release in late summer 2005. I'm currently working off this list: http://wiki.apache.org/xmlgraphics-fop/FOPWorkEstimates But this list isn't binding. You're free to choose what you like to work on. If you want to build the Java2D renderer, that's great. If you want to help with the layout engine, even better. If you start a task simply notify us what you're working on so we don't have duplicate effort. Is anybody else actively working on the awt rendered for the next release? No, not at the moment. Since this is my first foray into open-source development, any and all advice is welcome. The advice is simple: Choose something to work on, notify this list (if it's something bigger), start hacking and in the end send patches via Bugzilla. Of course, this is a bit simplistic but essentially this is all what you need to know for now. :-) If you have questions simply ask. We're happy to help you getting started. Jeremias Maerki
Re: another nose for the grindstone
Renaud et al I've had less time to devote to it than I thought, but I am working my way carefully through the spec (and trying to keep up with the posts to fop-dev). The bottom line is that I'm not actively working on the code yet - I hope to be by April. So, if you've got time now, you should pick what you want to work on, and I'll fill in where needed. Mark Brucks Renaud Richardet wrote: bonjour fop-devs i would like to work on the awt renderer. Mark (or someone else) , are you working on it? i checked out the code from FOP 0.20.5. is it the latest maintenance version? thanks, renaud On Mon, 17 Jan 2005 10:54:43 +0100, Jeremias Maerki [EMAIL PROTECTED] wrote: Hi Mark We'd love to have you with us. On 17.01.2005 05:18:23 Mark Brucks wrote: I'd like to join the fop development group. I've been an xsl/fop user for the last year or so (generating PDF), but several new projects I'm proposing have a need for a robust and complete awt renderer, and I'd like to devote some time to ensuring this happens. I have a little bit of time in the near term to commit to the project, and I hope much more time starting in the April time frame. I'd like to use the next 2 months to come up to speed, then dive in to serious work when more time is available. The AWT renderer is currently missing in CVS HEAD. It would be great if someone took up that task. To build that renderer you can look at the code from the maintenance branch (or FOP 0.20.5) for reference. Our reference renderer in CVS HEAD is the PDF renderer (like before). Personally, I'd rather call it Java2D renderer, not AWT renderer, because Java2D is essentially the name of the API you code against. AWT is, as the name says, a windowing toolkit, not primarily a graphics API. I need some advice. I've learned enough about xsl and fop to get my job done, but there are lots of holes in my knowledge base. I'd like to spend a little bit of time carefully reading the XSL spec. Should I read the XSL V1.1 working draft (in anticipation of things to come), or should I stick with the V1.0 recommendation (which I assume is what the new version of fop will implement). The recommendation is still the main reference. Glen Mazza already started investigating the 1.1 WD (ex. bookmarks) and it might be helpful sometimes to consult the 1.1 WD because it seems to be somewhat more verbose. It's good to prepare for 1.1 but as long as it's in WD phase the focus should remain on the 1.0 Rec for the time being. Do the development and design documents that are available on-line relate to the root/trunk/redesign version, or do they still describe the maintenance branch? They refer to CVS HEAD. If they are not up-to-date, they should be updated. Is there a development schedule or a prioritized list of features to be implemented? A development schedule is always difficult in an all-volunteer project. I think it's pretty realistic now to target an initial release in late summer 2005. I'm currently working off this list: http://wiki.apache.org/xmlgraphics-fop/FOPWorkEstimates But this list isn't binding. You're free to choose what you like to work on. If you want to build the Java2D renderer, that's great. If you want to help with the layout engine, even better. If you start a task simply notify us what you're working on so we don't have duplicate effort. Is anybody else actively working on the awt rendered for the next release? No, not at the moment. Since this is my first foray into open-source development, any and all advice is welcome. The advice is simple: Choose something to work on, notify this list (if it's something bigger), start hacking and in the end send patches via Bugzilla. Of course, this is a bit simplistic but essentially this is all what you need to know for now. :-) If you have questions simply ask. We're happy to help you getting started. Jeremias Maerki
Re: another nose for the grindstone
On Feb 21, 2005, at 4:55 PM, Renaud Richardet wrote: bonjour fop-devs Salut! Bienvenue! i would like to work on the awt renderer. Mark (or someone else) , are you working on it? i checked out the code from FOP 0.20.5. is it the latest maintenance version? thanks, renaud Actually, the fop-0.20.5 code is merely for reference. All FOP development has moved away from the fop-0.20-5 branch (fop-0_20-maintain OR 'maintenance' branch) in favor of the re-design branch (HEAD). This was done because the 'maintenance' branch had significant problems that were not easily resolvable. The re-design branch occurred because of problems in implementing the XSL0FO 1.0 spec--specifically with the 'keeps' I believe. In any case, if you wish to contribute to FOP development, please check out the HEAD branch. You may look to fop-0.20.5 for reference, but any work you do on that branch will probably not be integrated into FOP 1.0. Cheers! Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
Re: another nose for the grindstone
Clay, he knows that. I told him to use the maintenance branch code as a reference for bringing back the AWT Renderer in CVS HEAD. Renaud and I met last Friday at lots.ch. So, Renaud, please use the code found under the fop-0_20_2-maintain branch for reference. And happy hacking! On 22.02.2005 05:38:58 The Web Maestro wrote: On Feb 21, 2005, at 4:55 PM, Renaud Richardet wrote: bonjour fop-devs Salut! Bienvenue! i would like to work on the awt renderer. Mark (or someone else) , are you working on it? i checked out the code from FOP 0.20.5. is it the latest maintenance version? thanks, renaud Actually, the fop-0.20.5 code is merely for reference. All FOP development has moved away from the fop-0.20-5 branch (fop-0_20-maintain OR 'maintenance' branch) in favor of the re-design branch (HEAD). This was done because the 'maintenance' branch had significant problems that were not easily resolvable. The re-design branch occurred because of problems in implementing the XSL0FO 1.0 spec--specifically with the 'keeps' I believe. In any case, if you wish to contribute to FOP development, please check out the HEAD branch. You may look to fop-0.20.5 for reference, but any work you do on that branch will probably not be integrated into FOP 1.0. Jeremias Maerki
Renaming the AWT Renderer to Java2D Renderer
Now that we've got someone who will work on the AWT Renderer I'd like to know if someone is against renaming the AWT Renderer to Java2D Renderer. The API in use is actually the Java2D API [1], although most of the classes had their origin within AWT (and are still in there). AWT is actually the windowing toolkit which is something that's not used inside the renderer. Only when the Java2D renderer is embedded inside a GUI application AWT (or rather Swing or SWT) are coming into use. And the preview window actually uses Swing, not AWT. So here are the proposed changes: - Package org.apache.fop.render.awt becomes org.apache.fop.render.java2d - AWTRenderer.java becomes Java2DRenderer.java (AWT*.java - Java2D*.java) I think the viewer subpackage can stay as is under the renamed package. Any objections? [1] http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec.html Jeremias Maerki
