Destinations (was: Re: svn commit: r525078...)
Great addition, I agree, but is it supposed to work? I tried it out and although some new elements are generated in the PDF the destinations don't work. The elements generated also look a little different than in 0.20.5, and I'm not referring to the fact that currently we only reference pages and not coordinates on pages. Jay, is the feature fully implemented or are any things missing? On 03.04.2007 10:41:27 Vincent Hennebert wrote: Hi Jay, First, congratulations for this new feature! This is a great addition to FOP. A few remarks about your commit: - I suggest you to install and setup checkstyle if you haven't done yet; - don't forget to add the ASF headers (checkstyle will notify you about that, BTW) and set the svn:keywords Id and svn:eol-style native on new files. - if your modifications are non-trivial (as is the case here), it's very important to add a note about them in the status.xml file. The content of this file appears on the following web page: http://xmlgraphics.apache.org/fop/changes.html This is a key page for our users to follow FOP's evolutions. If the change is important and deserves to be highlighted in the release notes of the next version (as, again, is the case here), you should add the importance=high attribute to the entry. See for example here: http://xmlgraphics.apache.org/fop/0.93/releaseNotes_0.93.html I've added an entry for named destinations, feel free to improve it if needed (for example, it might be good to explain the net result for users). Thanks, Vincent Author: vhennebert Date: Tue Apr 3 01:14:05 2007 New Revision: 525078 URL: http://svn.apache.org/viewvc?view=revrev=525078 Log: - fix minor checkstyle issues - add missing headers - add an entry in status.xml for the new named destinations feature Jeremias Maerki
DO NOT REPLY [Bug 42043] New: - white-space-collapse=false linefeed-treatment=preserve does not preserve initial spaces.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42043. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42043 Summary: white-space-collapse=false linefeed- treatment=preserve does not preserve initial spaces. Product: Fop Version: all Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Using white-space-collapse=false and linefeed-treatment=preserve for pre-formatted text does not work when spaces are present at the beginning of lines. For example: fo:b w-s-p=f l-t=pHello/fo:b is fine. fo:b w-s-p=f l-t=p Hello/fo:b produces the same as the above. Tested against trunk using awt and pdf. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 42043] - white-space-collapse=false linefeed-treatment=preserve does not preserve initial spaces.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42043. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42043 --- Additional Comments From [EMAIL PROTECTED] 2007-04-04 02:05 --- Created an attachment (id=19911) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19911action=view) FO file demonstrating the problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Clarification for tables: grid units, border-resolution and breaks
Dear XSL Editors, Questions were recently raised on the fop-dev mailing lists about tables, borders and breaks. We finally all came to the same conclusions but I think it might be useful to add some statements to the XSL-FO Recommendation, in order to ease the understanding for newcomers. Grid units and area tree It seems that the notion of grid unit is to be understood in terms of area tree instead of fo tree. This is not obvious in the Recommendation and it might help to explicitely write that. For example, when a table-cell is broken over two pages, does it make one broken grid unit or two separate ones? Thinking in term of FO tree, that would be one; in term of area tree, that would be two. This is important for border resolution, as we can see below. Border-resolution in the collapsing-border model For the (cells of the) first row of a table, border-before on the fo:table and applicable fo:table-column objects play into border resolution. When the table is broken accross several pages, do they also play for the first row of each page? Or only the very first row of the table? We agreed upon yes. This means that if border-conditionality=retain on fo:table, then it will appear on each page (if it wins in the border resolution), which would be the same behavior as in the separate-border model. But if the fo:table-header is not omitted at page breaks, how should border resolution be performed? Technically, the areas generated by the table-cell children of fo:table-header are /replicated/ on each new page, so they would have the is-first trait set to true. So assuming that the conditionality of the fo:table's border-before is discard, should it play or not in the border resolution of table-headers on the second and following pages? Border-resolution and breaks For simplicity let's assume we are inside a single table-body. The question is the same if we are at the boundary between two table-bodies, only the border-after/-before of the table-bodies will also play in the resolution. The border-after of a cell is to be determined from: - the table-cell's border-after; - the containing table-row's border-after; - the following table-row's border-before; - the border-before of the cell below. If a break occurs /within/ a cell, should the following row and cell still play in the border-resolution? We agreed upon not. If a break occurs between two cells: - should a full border appear at the bottom of the page (or column) and a full border at the top of the following page (column)? Or only half a border on each? We agreed upon the former. - like above, should the two cells and table-rows play in the border-resolution of each border? Or only the previous cell and row for the border-after on the first page and the following cell and row for the border-before on the following page? We agreed upon the latter. Those questions are easily answered if we consider that the table is divided into independant grids on each page. Thus there would be a grid line at the top and bottom of each page. Such a scheme would be logical if grid units are entities which belong in the area tree. If on the contrary the table must be thought as a single grid which then is broken down on several pages (more on the FO tree side), then the answers to these questions tend to be different. That's why it may be useful to state that grid units pertain to the area tree, and that border-resolution is performed on them at the area-tree level. Explicit breaks on table-header and -footer I don't think it makes much sense to set the break-before and break-after properties on fo:table-row and children of fo:table-cell which are themselves children of fo:table-header and fo:table-footer elements. It might be helpful to explicitely state that in the descriptions of break-before and break-after. I hope I was myself clear! Thanks, Vincent Hennebert
Re: Clarification for tables: grid units, border-resolution and breaks
I am trying to do the following fo:table-cell border-left-color=green border-left-style=dotted border-top-color=red border-top-style=dotted border-right-color=blue border-right-style=dotted border-bottom-color=yellow border-bottom-style=dotted in fop-0.20.5 , also tried the dashed but it is taking only solid as border of cell not dotted or dashed, How we can make the cell border dashed or dotted, is it a known bug or i am missing some thing ? is there any work around for it? regards Arun - Original Message - From: Vincent Hennebert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: fop-dev@xmlgraphics.apache.org Sent: Wednesday, April 04, 2007 3:20 PM Subject: Clarification for tables: grid units, border-resolution and breaks Dear XSL Editors, Questions were recently raised on the fop-dev mailing lists about tables, borders and breaks. We finally all came to the same conclusions but I think it might be useful to add some statements to the XSL-FO Recommendation, in order to ease the understanding for newcomers. Grid units and area tree It seems that the notion of grid unit is to be understood in terms of area tree instead of fo tree. This is not obvious in the Recommendation and it might help to explicitely write that. For example, when a table-cell is broken over two pages, does it make one broken grid unit or two separate ones? Thinking in term of FO tree, that would be one; in term of area tree, that would be two. This is important for border resolution, as we can see below. Border-resolution in the collapsing-border model For the (cells of the) first row of a table, border-before on the fo:table and applicable fo:table-column objects play into border resolution. When the table is broken accross several pages, do they also play for the first row of each page? Or only the very first row of the table? We agreed upon yes. This means that if border-conditionality=retain on fo:table, then it will appear on each page (if it wins in the border resolution), which would be the same behavior as in the separate-border model. But if the fo:table-header is not omitted at page breaks, how should border resolution be performed? Technically, the areas generated by the table-cell children of fo:table-header are /replicated/ on each new page, so they would have the is-first trait set to true. So assuming that the conditionality of the fo:table's border-before is discard, should it play or not in the border resolution of table-headers on the second and following pages? Border-resolution and breaks For simplicity let's assume we are inside a single table-body. The question is the same if we are at the boundary between two table-bodies, only the border-after/-before of the table-bodies will also play in the resolution. The border-after of a cell is to be determined from: - the table-cell's border-after; - the containing table-row's border-after; - the following table-row's border-before; - the border-before of the cell below. If a break occurs /within/ a cell, should the following row and cell still play in the border-resolution? We agreed upon not. If a break occurs between two cells: - should a full border appear at the bottom of the page (or column) and a full border at the top of the following page (column)? Or only half a border on each? We agreed upon the former. - like above, should the two cells and table-rows play in the border-resolution of each border? Or only the previous cell and row for the border-after on the first page and the following cell and row for the border-before on the following page? We agreed upon the latter. Those questions are easily answered if we consider that the table is divided into independant grids on each page. Thus there would be a grid line at the top and bottom of each page. Such a scheme would be logical if grid units are entities which belong in the area tree. If on the contrary the table must be thought as a single grid which then is broken down on several pages (more on the FO tree side), then the answers to these questions tend to be different. That's why it may be useful to state that grid units pertain to the area tree, and that border-resolution is performed on them at the area-tree level. Explicit breaks on table-header and -footer I don't think it makes much sense to set the break-before and break-after properties on fo:table-row and children of fo:table-cell which are themselves children of fo:table-header and fo:table-footer elements. It might be helpful to explicitely state that in the descriptions of break-before and break-after. I hope I was myself clear! Thanks, Vincent Hennebert
DO NOT REPLY [Bug 41894] - fo:block-container: percentage-lengths + width/height-ipd/bpd
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41894. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41894 --- Additional Comments From [EMAIL PROTECTED] 2007-04-04 02:56 --- I think this is a step in the right direction, but I believe the PercentBase shouldn't be LengthBase.CONTAINING_REFAREA_HEIGHT but LengthBase.CONTAINING_BLOCK_HEIGHT. i-p-d, b-p-d, width and height are all using CONTAINING_BLOCK_WIDTH/HEIGHT as per the spec. top, left etc. are also defined in terms of the containing block, not the nearest ancestor reference area. In your example, that would place all three inner b-cs at the upper edge of the block-container's content area because the block they are enclosed in doesn't have a height in this case. Only if you remove the block between the inner and outer b-c will the vertical positioning work again. It's what I would expect in terms of behaviour. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: startPageSequence() in Renderer interface
Hi Adrian On 02.04.2007 11:05:03 Adrian Cumiskey wrote: I am working on the postscript renderer and have a query about org.apache.fop.render.Renderer#void startPageSequence(LineArea title). Its seems a bit wrong to me that this method is invoked with just the title of the PageSequence being passed to it, surely it would be better to pass the PageSequence itself (which contains the title). I would think that the PageSequence object itself would be much more useful to the renderer. Am I missing something? Is there a good reason which I have missed as to why it is implemented in this way? I think the reason for that is that there are simply no other important things on the PageSequence besides the title. PageSequence.getPageCount () may not be a reliable source of information during rendering as a page-sequence can be started without knowing how many pages there will be in the end. And getPageCount() is really the only thing besides the title on the PageSequence. On 03.04.2007 18:25:15 Adrian Cumiskey wrote: I have had a good look through the code, changed the interface in my sandbox and I can find no reason why org.apache.fop.render.Renderer#void startPageSequence(LineArea title) shouldn't instead be org.apache.fop.render.Renderer#void startPageSequence(org.apache.fop.area.PageSequence pageSeq). Of course this would mean a change in a low level interface but would be a trivial change for all our renderers. our renderers, yes. You also need to consider custom renderer developed outside of FOP. If you implement the other method, you can simply call the old one and you have a compatible change. But see below... The reason why this is important is that the implementing renderer may need to do some initial preparation work before page processing (e.g. in my case the postscript renderer may want to access some extensions that have been defined as children of the simple page master prior to processing the individual pages in its sequence). I don't think I'm missing something here.. I don't understand the motivation here. The simple page master is something that changes from page to page. I'd like to know why you want to access something from a page-master in the context of a page-sequence. If you had an extension element for PostScript as direct child of page-sequence, then I'd understand. Speak now or forever hold your peace :-) This is not very helpful, despite the smiley. Besides, things change. Your post is the best example of that. Well, maybe I'm missing a joke not being native English speaking. Jeremias Maerki
DO NOT REPLY [Bug 42043] - white-space-collapse=false linefeed-treatment=preserve does not preserve initial spaces.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42043. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42043 --- Additional Comments From [EMAIL PROTECTED] 2007-04-04 04:08 --- Created an attachment (id=19913) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19913action=view) Doc update pointing to additional required attribute. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Clarification for tables: grid units, border-resolution and breaks
Arun Kumar wrote: I am trying to do the following By hijacking Vincent's Thread, you have posted your question about FOP to the XSL Editors Please don't hijack threads and be careful who you post to! fo:table-cell border-left-color=green border-left-style=dotted border-top-color=red border-top-style=dotted border-right-color=blue border-right-style=dotted border-bottom-color=yellow border-bottom-style=dotted in fop-0.20.5 , also tried the dashed but it is taking only solid as border of cell not dotted or dashed, FOP 0.20.5 does not implement dashed or dotted borders. How we can make the cell border dashed or dotted, is it a known bug or i am missing some thing ? It is a known limitation of rather ancient FOP version 0.20.5. This has been implemented in later versions of FOP. I recommend that you download the binary distribution of 0.93 and try it for yourself. http://xmlgraphics.apache.org/fop/download.html#binary snip/ Note to other FOP Devs: Isn't it about time we removed the download links to 0.20.5 from the download page? This should help discourage new users of a 5 year old release. Thanks, Chris
DO NOT REPLY [Bug 41995] - [PATCH] Barcode Support for AFP Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41995 --- Additional Comments From [EMAIL PROTECTED] 2007-04-04 06:57 --- Pete, I took a look at your patch. I must say, I'm not happy with the approach you've taken. You've copied many classes from Barcode4J, adjusted some of them and put them in a new package under the FOP source tree. This is a maintenance nightmare and the legal paperwork also needs to be considered. That aside, I'm not comfortable with the bcoca package having a dependency into the classes coming from Barcode4J. From an architecture perspective, it would be much cleaner to simply provide the object model of the BCOCA functionality in the bcoca package and then fill that from the Barcode extension. Like we do it for formats like PDF, PostScript and RTF, I'd prefer to keep that pattern, because that makes it possible to use the AFP code outside the FOP context, too. Until now, that pattern was preserved. The package o.a.fop.render.afp.modca had only dependencies into: - o.a.fop.render.afp.exceptions - o.a.fop.render.afp.fonts - o.a.fop.render.afp.tools - o.a.commons.logging With your patch, o.a.fop.render.afp.bcoca and the forked Barcode4J classes are added. Ideally, the modca package wouldn't even have a dependency into bcoca. Right now, there's a circular dependency in your patch. I have a proposal: Let's reuse (and adapt if necessary) Barcode4J and build a cleaner dependency tree. Let's rid the bcoca package of references to Barcode4J classes and only concentrate on the object model there. In a second step, let's extend the FOP extension in Barcode4J to support native AFP barcodes. It's more or less what I saw as the ideal solution in the first place but since you introduced so many aspects from Barcode4J I think this is the right solution. I can offer you some help with that. I've already locally removed all the forked classes and started to correct the remaining issues. I would be comfortable with just applying the part of the patch with the BCOCA object model after I've done some changes. We can then go from there. Please note that we once talked about bundling Barcode4J with FOP. We could take this as an additional incentive to actually do it. WDYT? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 41995] - [PATCH] Barcode Support for AFP Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41995 --- Additional Comments From [EMAIL PROTECTED] 2007-04-04 07:06 --- BTW, further advantages with my proposal: - Less documentation overhead - Same namespace as Barcode4J already uses (no special handling for AFP) - Optimal rendering (native or Java2D) depending on what's already implemented. Disadvantages: - we cannot just use your patch, more development necessary - we need to make sure that the FOP extension works with 0.93 until the next release of FOP. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 41995] - [PATCH] Barcode Support for AFP Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41995 --- Additional Comments From [EMAIL PROTECTED] 2007-04-04 07:50 --- Jeremias, I should have made it clearer I never really expected the patch to be applied as it stands for the reason that it relies on forked bc4j code. I submitted the patch in the hope that it would prompt this discussion, when writing it I obviously had the issue of calculating the barcode dimensions which is exactly what Barcode4J does very well, so didn't want to re-solve that problem. My intention was not that that FOP would have a seperate set of barcode4j classes as I agree it would be a mainatenance nightmare. This is why I put in the barcode4j a seperate package, so that it could be reviewed as part of the patch and you could decide the best way to achieve this with your Barcode4j hat on. I'd like to see fop include barcode4j, but obviously it also stands on it's own for users who want to generate images. I am more than happy with your proposal and we can take it forward once you've finished the package refactor. However I think some kind of bridging pattern would be required so that the BCOCA attributes (to get the afp barcode type and modifier) can be obtained based on the barcode being rendered. (In reply to comment #4) BTW, further advantages with my proposal: - Less documentation overhead - Same namespace as Barcode4J already uses (no special handling for AFP) - Optimal rendering (native or Java2D) depending on what's already implemented. Disadvantages: - we cannot just use your patch, more development necessary - we need to make sure that the FOP extension works with 0.93 until the next release of FOP. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 41995] - [PATCH] Barcode Support for AFP Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41995 --- Additional Comments From [EMAIL PROTECTED] 2007-04-04 08:13 --- Great! I feared we were too far apart on this, but apparently not. I'll see what I can do today. It looks like AbstractBarcodeBean is tied more deeply into the bcoca package than I first thought. How much time do you have to work on this? I mean, if I can defer some of the work to you, I'd be more than happy. That would allow me to concentrate on other FOP issues. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 41995] - [PATCH] Barcode Support for AFP Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41995. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41995 --- Additional Comments From [EMAIL PROTECTED] 2007-04-04 08:34 --- (In reply to comment #6) I have limited time this week, but could progress further next week. However I'd like to agree an approach, the AbstractBarcodeBean is basically tied deeply as the bcoca model requires access to these attributes. I'd suggest that I make this an interface, and then the barcode4j ext can provide a wrapper that implements that interface if using native support that just delegates to the real bean. Rather than make this interface AFP specific this could go in a barcode package so that any other renderers that are capable of native barcode support could use the same mechanism. This shouldn't take to long to do, WDYT? Great! I feared we were too far apart on this, but apparently not. I'll see what I can do today. It looks like AbstractBarcodeBean is tied more deeply into the bcoca package than I first thought. How much time do you have to work on this? I mean, if I can defer some of the work to you, I'd be more than happy. That would allow me to concentrate on other FOP issues. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Destinations (was: Re: svn commit: r525078...)
Hi all, Great addition, I agree, but is it supposed to work? I tried it out and although some new elements are generated in the PDF the destinations don't work. It's a small error: the PDFDestination class uses the reference to the page object as its goToReference. What it should use is a reference to a /Goto that jumps to the page in question. There's also something wrong with makeLink(Rectangle2D rect, String destination, int linkType, float yoffset) in PDFFactory. The following line is commented out twice: //String file = destination.substring(0, index + 4); Both instances should be uncommented, and in the corresponding calls to getGoToPDFAction (2 lines below), destination must be replaced with file. Otherwise, Jay's destinations (once fixed) will be fine but they won't ever be found by FOP-built external links. The elements generated also look a little different than in 0.20.5, and I'm not referring to the fact that currently we only reference pages and not coordinates on pages. As to that: I will probably submit my basic-links patch tomorrow. It makes links and bookmarks land on the spot. I'll also hook up the named destinations to that mechanism. Kind regards, Paul Vinkenoog
DO NOT REPLY [Bug 42049] New: - RTF tables ignore margin-left of containing block
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42049. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42049 Summary: RTF tables ignore margin-left of containing block Product: Fop Version: all Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: rtf AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] RTF rendering of tables inside a block with a positive margin-left property is exhibiting different behaviour than rendering of AWT/PS/c. In particular, in the RTF render, tables always seem to be left-aligned even if their parent has a positive margin-left. However, the same tables are indented as one would expect in the other render modes. Consider this stylesheet (it will work with any XML file if you run fop -xml any_file -xsl file_provided_below -rtf output_file.rtf ?xml version=1.0 encoding=ISO-8859-1? !-- desc: reproduce problem where RTF table is rendered with incorrect -- !-- margin but PS/AWT versions rendered with correct margin. -- xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:fo=http://www.w3.org/1999/XSL/Format; xsl:template match=/ fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=A4 fo:region-body margin-left=0.26in margin-right=0.25in margin-top=0.17in margin-bottom=0.17in/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=A4 fo:flow flow-name=xsl-region-body fo:block margin-left=0.8in padding-left=0in font- family=arial font-size=8pt !-- a block indented by the margin, correctly. -- fo:block padding-bottom=10ptSome correctly indented text./fo:block !-- a table incorrectly indented. -- fo:table table-layout=fixed padding-bottom=2.7pt fo:table-column column-width=2in/ fo:table-column column-width=2in/ fo:table-body fo:table-row fo:table-cell margin-left=0in fo:blockShould align with/fo:block /fo:table-cell fo:table-cell margin-left=0in fo:blockText above/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:block /fo:flow /fo:page-sequence /fo:root /xsl:template /xsl:stylesheet -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 42049] - RTF tables ignore margin-left of containing block
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42049. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42049 --- Additional Comments From [EMAIL PROTECTED] 2007-04-04 10:52 --- RTF rendering of tables inside a block with a positive margin-left property is exhibiting different behaviour than rendering of AWT/PS/c. In particular, in the RTF render, tables always seem to be left-aligned even if their parent has a positive margin-left. However, the same tables are indented as one would expect in the other render modes. Consider this stylesheet (it will work with any XML file if you run fop -xml any_file -xsl file_provided_below -rtf output_file.rtf ?xml version=1.0 encoding=ISO-8859-1? !-- desc: reproduce problem where RTF table is rendered with incorrect -- !-- margin but PS/AWT versions rendered with correct margin. -- xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:fo=http://www.w3.org/1999/XSL/Format; xsl:template match=/ fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=A4 fo:region-body margin-left=0.26in margin-right=0.25in margin-top=0.17in margin-bottom=0.17in/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=A4 fo:flow flow-name=xsl-region-body fo:block margin-left=0.8in padding-left=0in font- family=arial font-size=8pt !-- a block indented by the margin, correctly. -- fo:block padding-bottom=10ptSome correctly indented text./fo:block !-- a table incorrectly indented. -- fo:table table-layout=fixed padding-bottom=2.7pt fo:table-column column-width=2in/ fo:table-column column-width=2in/ fo:table-body fo:table-row fo:table-cell margin-left=0in fo:blockShould align with/fo:block /fo:table-cell fo:table-cell margin-left=0in fo:blockText above/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:block /fo:flow /fo:page-sequence /fo:root /xsl:template /xsl:stylesheet -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Destinations (was: Re: svn commit: r525078...)
Paul, thanks for the heads up and the explanation. I'm looking forward to your patch. This is going to be a very important feature for all the people doing book-style documents. On 04.04.2007 18:12:53 Paul Vinkenoog wrote: Hi all, Great addition, I agree, but is it supposed to work? I tried it out and although some new elements are generated in the PDF the destinations don't work. It's a small error: the PDFDestination class uses the reference to the page object as its goToReference. What it should use is a reference to a /Goto that jumps to the page in question. There's also something wrong with makeLink(Rectangle2D rect, String destination, int linkType, float yoffset) in PDFFactory. The following line is commented out twice: //String file = destination.substring(0, index + 4); Both instances should be uncommented, and in the corresponding calls to getGoToPDFAction (2 lines below), destination must be replaced with file. Otherwise, Jay's destinations (once fixed) will be fine but they won't ever be found by FOP-built external links. The elements generated also look a little different than in 0.20.5, and I'm not referring to the fact that currently we only reference pages and not coordinates on pages. As to that: I will probably submit my basic-links patch tomorrow. It makes links and bookmarks land on the spot. I'll also hook up the named destinations to that mechanism. Kind regards, Paul Vinkenoog Jeremias Maerki
Border- and padding-conditionality and fences
Dear XSL Editors, I have another question regarding border- and padding-conditionality. Please see the attached fo file, which gives a two-page document: the question is whether the padding-before of the inner block should be discarded or not on the second page. The intuitive answer would be yes (at least I think this is what most users would expect). However, if we strictly follow the rules of the XSL-FO 1.1 Recommendation it seems that the padding should actually be retained. Indeed it would be discarded if the before-edge of the area generated by the inner block were a leading edge in the normal-flow-reference-area (of the second page, let's call it R). This is explained in the last two paragraphs of section 4.3.1, Space-resolution Rules of the XSL-FO 1.1 Recommendation. This edge would be a leading edge if the inner blocks's area would begin the normal-flow-reference-area (section 4.2.5), that is if it had a stacking constraint with R and if none of its ancestor areas had a non-null space-before. However, the retained border on the outer block creates a fence before the area generated by that block; which prevents the inner area from having a stacking constraint with R. Thus the edge is not a leading edge and the padding-before should be retained. What is interesting is that if the outer block had a discarded border-before then the padding would also be discarded, as this time there would be a stacking constraint between the inner area and R. Also, if the outer block were instead a block-container, then the padding would again be discarded, because the reference-area to be considered would be the one generated by the block-container. One developer came up with an interesting interpretation: the rules at the end of section 4.3.1 should be taken only to determine if border and padding create fences preventing stacking constraints to occur (as seems to be implied by the for purposes of the stacking constraint definitions sentence). And that the notion of leading/trailing /area/ should instead be considered to determine if borders and padding should actually be discarded or not. While this interpretation makes sense and would match users' expectations, I'm not sure if it is really intended by the Recommendation. So could you please provide a clarification on this subject? Thanks, Vincent Hennebert ?xml version=1.0 standalone=no? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=page page-height=4cm page-width=15cm margin-top=0cm margin-bottom=0cm margin-left=3cm margin-right=3cm fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=page font-family=serif font-size=14pt fo:flow flow-name=xsl-region-body fo:block orphans=1 widows=1 border-before-width.length=6pt border-before-width.conditionality=retain border-before-style=solid border-before-color=blackSome text. Some text. Some text. Some text. Some text. Some text. fo:block orphans=1 widows=1 border-before-width.length=5pt border-before-width.conditionality=retain border-before-style=solid border-before-color=olive padding-before.length=8pt padding-before.conditionality=discardSome text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. Some text. /fo:block /fo:block /fo:flow /fo:page-sequence /fo:root
Re: Destinations (was: Re: svn commit: r525078...)
Hi all, Great addition, I agree, but is it supposed to work? I tried it out and although some new elements are generated in the PDF the destinations don't work. It's a small error: the PDFDestination class uses the reference to the page object as its goToReference. What it should use is a reference to a /Goto that jumps to the page in question. There's also something wrong with makeLink(Rectangle2D rect, String destination, int linkType, float yoffset) in PDFFactory. The following line is commented out twice: //String file = destination.substring(0, index + 4); Both instances should be uncommented, and in the corresponding calls to getGoToPDFAction (2 lines below), destination must be replaced with file. Otherwise, Jay's destinations (once fixed) will be fine but they won't ever be found by FOP-built external links. The elements generated also look a little different than in 0.20.5, and I'm not referring to the fact that currently we only reference pages and not coordinates on pages. As to that: I will probably submit my basic-links patch tomorrow. It makes links and bookmarks land on the spot. I'll also hook up the named destinations to that mechanism. I think I mistakenly committed an interim step in the project, but I'll have to check. Also, I meant to mention that I only extended fo:block to recognize a destination child object, so destinations only work on blocks (so far). That was a limitation that worked for my client, but I should have mentioned it. Sorry, folks. Jay Bryant Bryant Communication Services
Re: Destinations (was: Re: svn commit: r525078...)
//String file = destination.substring(0, index + 4); I didn't add or comment out those lines, by the way, so I have no idea why those lines might have been commented out. Jay Bryant Bryant Communication Services
Re: Destinations (was: Re: svn commit: r525078...)
Hi jay, //String file = destination.substring(0, index + 4); I didn't add or comment out those lines, by the way, so I have no idea why those lines might have been commented out. I know you didn't, because I'd been staring at them lines long before you committed your destinations code. Sorry, I didn't mean to suggest that this was your fault. Kind regards, Paul Vinkenoog
