Build error (BoxLayout): Table header too large

This forum is for all Flare issues related to PDF, eBook, Microsoft Word, Adobe FrameMaker, XPS, and XHTML book targets.
Post Reply
ruthhoward
Sr. Propeller Head
Posts: 121
Joined: Tue Jul 24, 2012 12:38 am

Build error (BoxLayout): Table header too large

Post by ruthhoward »

Hi folks

We have an issue that's repeating in the same Flare project for different PDF targets following the departure of a colleague (and with her the knowledge of what to do about it).

Code: Select all

ID 10009 Table header is too large to fit on page 12. Content may overflow. Subsystem = BoxLayout.
The first time we encountered it there was a table on the reported page and it was very wide. After a lot of messing with the table content (eventually allowing individual cells to break across pages), we managed to get rid of the error. We tried using custom target error settings but when we switched from the default, a bunch of "off by default" errors got turned on and since we found a fix at the same moment, we stopped pursuing that option.

On the surface, it appears that the reported page is the automatically-inserted blank page after the TOC and before the content starts. We insert this in many places without error and it is completely empty apart from a watermark in the page layout saying "blank page". If I go to the footer page number reported in the error, there is a table but it's not very wide and doesn't look like it has any issues. The error in the build logs in the Flare UI are, however, misleading. If I dig into the raw build log file, that says that it's page 12 of the chapter currently being processed. This allows me to find the problematic table - it's the same one as before but other content got written in the PDF that inserted a few lines before it and altered where page breaks fell.

So, first some advice: if you see error 10009, open the logs as a text file so you can correctly identify the topic causing the error (the page number reported has nothing to do with the pages in the final PDF output).

Secondly, any advice on controlling table pagebreaks to prevent this sort of thing? We don't want to allow auto-pagebreaks, in general pagebreaks inside rows are undesirable but Flare just isn't coping with this particular table. We have a row that has one line of text on one page (and that's the entire content of the page), 22 sub-rows and a multi-column row on a second page. I've set

Code: Select all

page-break-inside: auto;
on the cell, the row, the parent row span and nothing is resolving the error.

Thanks!
Ruth
doloremipsum
Sr. Propeller Head
Posts: 290
Joined: Mon Aug 26, 2019 2:11 pm

Re: Build error (BoxLayout): Table header too large

Post by doloremipsum »

I haven't encountered this particular error before, but from the description, it sounds a little like there's a big table header which cannot fit on the page. Do you have multiple rows within the <thead> element, by any chance? The thead element is meant to repeat on every page that the table flows to, so if it's too large I would imagine that Flare would attempt to fit it in, give up, then try again on the next page. Move any rows which aren't actually part of the header into the <tbody> element.

If that's not the case, I'd recommend (temporarily) removing all of the attempts to control the page break flow and seeing if that fixes the problem. Then you can add them back in one by one and see which style change causes the table to stop working.
in hoc foro dolorem ipsum amamus, consectimur, adipisci volumus.
ruthhoward
Sr. Propeller Head
Posts: 121
Joined: Tue Jul 24, 2012 12:38 am

Re: Build error (BoxLayout): Table header too large

Post by ruthhoward »

Thanks for the reply doloremipmsum. The thead doesn't have multiple rows but there are several columns in all, with some cells spanning multiple rows and other spanning multiple columns.
I think you suggest a good strategy, but this table covers 12 pages altogether so I fear it would take a very long time to try that. I've discussed with the owner of the doc and she had much higher priorities so while the build is no longer throwing an error (because it's being explicitly ignored) she's happy to leave it as it is. Really, the table is not a very good bit of information design and the same thing could be communicated in a much better, clearer and more accessible way. But sadly we don't have time for reworking it either.
Post Reply