Created attachment 29170 [details] Input FO, output PDF (for reference), trace, conf In RTF, using fo:table-cell as direct children of fo:table-header (without intervening fo:table-row) causes the FOPException "... RTFHandler: startCell null". In PDF, it works flawlessly (which it should, as far as I understand the FO specs).
I'm running on Windows 7, using FOP 1.1rc1
Created attachment 29509 [details] Patch to fix mismatch between XSL:FO and RTF regarding header table-rows This issue is happening because it is always expecting there to be a TableRow even though Gisbert correctly states that one is not required for XSL:FO. This fix tries to create the missing container element if one cannot be found. This however creates the problem that because no endRow() method is ever fired, the new TableRow will be left hanging by itself which causes table rendering issues. To fix this, each element whether it is a writeable section or not (i.e. headers, footers) are pushed to the stack either as an RtfContainer or as their matching FObj object. When a pop event occurs, a check is made to see that what it thinks is being popped actually matches the top item on the stack. If it doesn't, then it means there is a mismatch and it is likely caused by a new table row. In this event, the item is pushed back onto the stack and a call to the method matching that class is made to close the tag pair before attempting to re-pop the original item. The code allows for further expansion should any other tag mismatches between XSL:FO and RTF be found. I have tested this patch against the original bug FO and it works correctly. There are a couple of things which are not ideal but please feel free to post any comments or suggestions if you have them.
Created attachment 29510 [details] Corrected patch file Sorry, that original patch was related to something else. I have now posted the correct patch file.