Fop 0.20.1 reports 'ERROR: The id "b2" already exists in this document' on executing "java org.apache.fop.apps.Fop spanbug.fo spanbug.pdf" with the input file spanbug.fo: ------------------------------------------------------------ <?xml version="1.0" encoding="ISO-8859-1"?> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"> <fo:layout-master-set> <fo:simple-page-master master-name="first"> <fo:region-body column-count="2" column-gap="5mm"/> </fo:simple-page-master> <fo:page-sequence-master master-name="standard"> <fo:repeatable-page-master-reference master-name="first" /> </fo:page-sequence-master> </fo:layout-master-set> <fo:page-sequence master-name="standard"> <fo:flow flow-name="xsl-region-body"> <fo:block id="b1" span="all" text-align="center"> Block 1 </fo:block> <!-- If you add a span="all" here, the error does not occur! --> <fo:block id="b2" text-align="center"> Block 2 </fo:block> <fo:block id="b3" span="all" text-align="center"> Block 3 </fo:block> <fo:block id="b4" text-align="center"> Block 4 </fo:block> </fo:flow> </fo:page-sequence> </fo:root> ------------------------------------------------------------ If the second block has a span="all" attribute like the first and the third, fop proceeds without error and produced the correct output. Since usage of the id-attribute and of alternating spanning / non spanning blocks is quite important for large documents, books, etc., i think this is a serious problem.
I have just run into this bug when there is a span="1". Prior to this week I did not use span in my block tags. Adding them (spans) this week has resulted some docs failing with the id already exists error.
Created attachment 1606 [details] Possible fix, for ids associated with <fo:block>
As far as I have been able to tell, this is due to FOP having to reconsider how it is laying out the elements on the page. It starts filling up one column, then encounters the span="all" block so it has to rebalance what came before. It rolls back the layout, but leaves any id registered so far still registered. The solution is to make sure that ids are unregistered after a rollback. The attached patch fixes the problem when the id that supposedly exists belongs to a <fo:block>. A better solution would fix the problem for all the objects that call IDReferences().createID(). The patch was created against version 0.20.3
Created attachment 8169 [details] Updated patch for FOP 0.20.5
I have attached an updated version of the patch for 0.20.5. Is there a reason this patch hasn’t made it into the main releases? It seems to, at least partly, solve a quite major bug.
*** Bug 23256 has been marked as a duplicate of this bug. ***
Any chance that some kind committer will commit this patch? The patch has been languishing for ALMOST THREE YEARS, which is quite a while in "internet time" :-) I have applied it and it fixed a bug for me too (NB the bug is not dependent on span="all"). But it would be nice not to have to maintain a private build of FOP. I would like to see it fixed in Cocoon, but this will have to wait for an official FOP release.
Fixed since at least version 0.93
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed