PDFsharp & MigraDoc Foundation

I am currently using MigraDoc to take a bunch of data and turn it into a pdf document. The document uses a letter size page with a header and a footer. I am adding tables to a Section object and then adding rows to the tables.

The end users of this document are very particular and have all sorts of requirements on how the data should be presented. Text wrapping in a row cell is a must so row height is not a constant.

The biggest hurdle I have to overcome is knowing when a particular table runs over to another page. To my knowledge, the only way I can know if the row I added to a table causes another page to be added to the document is by rendering the document and getting a page count. I have a very large amount of data to put on this document so rendering it after adding each row is a very time consuming process. Is there a better, or more efficient, way for me to keep track of my vertical location on a page so I can know whether adding a row, or not, will cause another page to be added to a document?

Thanks in advance!

Darren

MigraDoc adds page breaks automatically and repeats the table header automatically.
When used as intended, you do not have to track the current position on the page.

What are your special requirements?

You can create one table, render it once to a dummy document. Then you know the height of each row and create the final document with tables that always fit a single page.
But I don't understand yet why this is necessary.

_________________
Best regards
Thomas
(Freelance Software Developer with several years of MigraDoc/PDFsharp experience)

The data I have is grouped in tables. So let's say that I create a table and start putting rows on it for the data of Group #1. I finish with that group and render the document. I see that I'm still on page one so I create another table and start adding rows for the data of Group #2. I finish with that group, render the document, and still see I'm on page one. However, when I do the same thing for Group #3, I am now on page two. The powers that be don't want a group to be split between two pages so I have to remove the table from the section, add a page break, and then add a clone of the offending table back to the section so that it starts on its own page.

I can handle the above example easily enough, but it requires a lot of rendering. One issue that I have come up against with this example is when the offending table itself is too large to fit on one page. Then I have to figure out how many rows of that table I can add before another page needs to be added. Then I have to remove the table, add only the rows that will fit, add another page with a page break, add a new table, and finally put clones of the last rows in that table.

All this requires a ton of rendering to figure out when another page is needed and what object, exactly is causing that page count to increase. Now I will admit that I am not a MigraDoc expert, by any stretch of the imagination, so I may be overlooking something very simple. That's why I started this thread in the first place, to learn.

Thanks,

Darren

Maybe you can convince the powers to make a little compromise.

When you set KeepWith for the first data row of each table to e.g. 5, then you will always have at least 6 data rows of a table on the first page.
Find a number of rows that will surely fit on one page. This will automatically avoid tables starting with very few rows at the bottom of a page and continuing on the next page. This will save the time and code for extra rendering and for keeping track of it.
From time to time you will have tables that break across pages even though they will fit a single page. No big deal IMHO, but might take some discussions with management.

Maybe you can make that number dynamic, not fixed, by scanning the contents of each row to estimate how many rows will surely fit.

_________________
Best regards
Thomas
(Freelance Software Developer with several years of MigraDoc/PDFsharp experience)

For an approach without compromise:
- Create a document with all tables, force a page break before each table
- Let MigraDoc prepare the document. Now you can access the RenderInfo for all elements.
- Now create the final document and set KeepWith based on the results from the RenderInfo. Small tables will be kept on a single page, for larger tables the maximum possible rows will be kept on the first page.

Advantage: no compromise.
Disadvantage: Document must be prepared twice, consuming a few extra milliseconds.

_________________
Best regards
Thomas
(Freelance Software Developer with several years of MigraDoc/PDFsharp experience)