DO NOT REPLY [Bug 41860] New: - FOP crash on fixed-layout table with increasing number of cells/row
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=41860. 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=41860 Summary: FOP crash on fixed-layout table with increasing number of cells/row Product: Fop Version: 1.0dev Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Rendering a table with fixed layout where the first row has two cells and the second has more than two cells crashes FOP Example FO document to show the bug: ?xml version=1.0? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=page fo:region-body region-name=body/ /fo:simple-page-master fo:page-sequence-master master-name=contents fo:repeatable-page-master-reference master-reference=page/ /fo:page-sequence-master /fo:layout-master-set fo:page-sequence master-reference=contents fo:flow flow-name=body fo:block fo:table table-layout=fixed width=100% fo:table-body fo:table-row fo:table-cell fo:blockx/fo:block /fo:table-cell fo:table-cell fo:blockx/fo:block /fo:table-cell /fo:table-row fo:table-row fo:table-cell fo:block /fo:block /fo:table-cell fo:table-cell fo:blockA/fo:block /fo:table-cell fo:table-cell fo:blockB/fo:block /fo:table-cell fo:table-cell fo:blockC/fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:block /fo:flow /fo:page-sequence /fo:root -- 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 41860] - FOP crash on fixed-layout table with increasing number of cells/row
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=41860. 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=41860 --- Additional Comments From [EMAIL PROTECTED] 2007-03-16 06:23 --- Created an attachment (id=19721) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19721action=view) Backtrace of fop crash Produced with FOP-SVN at revision 518965. -- 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 41860] - FOP crash on fixed-layout table with increasing number of cells/row
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=41860. 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=41860 --- Additional Comments From [EMAIL PROTECTED] 2007-03-16 09:11 --- This should indeed be handled better, but your FO is actually very dubious... In fixed-layout, the number of columns and their respective widths are ultimately determined based on the cells in the first row. There is no obligation for an implementation of XSL-FO to even process the offending cells in the next rows... Going to leave the bug open, but just wanted to let you know this. -- 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 41831] - [PATCH] Refactored configuration, font detection and caching, url resolution
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=41831. 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=41831 --- Additional Comments From [EMAIL PROTECTED] 2007-03-16 13:57 --- Something else just occurred to me (In reply to comment #7) ... only, I can't find a TTF file on my system for which I get no complaints (about ascender/descender conflicts, or absent unicode cmaps) Must be something Mac-related (? or did you test on that platform yet?) I would very much like to know what the results are on an Intel Mac. I'm still on the PowerPC. As I was browsing through the font handling code, there's a lot of byte-reading and bit-shifting done... Well, maybe if I find the time, I'll study the TTF-spec, step through the code and have a look at how the bytes are interpreted over here... -- 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.
AddAreas in RowPainter
Hi, There are things unclear to me in the addAreasAndFlushRow method of the RowPainter class. I hope someone can shed some light: - why is a Map used to store y-offsets of rows? That seems to indicate that rows are not added in a sequential order, or that there could be hole between them, which sounds unlikely to me. - there is one condition that I don't understand on l.204: in case the primary grid unit at the given column isn't null, then the corresponding areas are added only if: - forcedFlush == true, or - the end of the cell is reached on the current row AND (the current grid unit is null or is the last in the row-spanning direction). What's the purpose of that second member of the and? - also, inside the if branch, in case the primary grid unit was null, then the primary grid units from the current grid unit (i.e., on the current row) is retrieved if: - it does not correspond to an empty cell; - the cell doesn't span in the column direction - it is the last grid unit Why such conditions, and can the primary grid unit still be null after that (as implied by the if l.223)? There seems to be some careful selection of the cells to be painted, which is still a bit cryptic to me... Thanks, Vincent
