-
Notifications
You must be signed in to change notification settings - Fork 690
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Table cells that are too tall to fit on one page get truncated; should continue cell contents on next page #147
Comments
This problem also prevents subtables from spanning more than one page. |
A code example of this problem with subtables:
|
Has anyone started to tackle this problem? I'm having the same issue, and need it fixed so I'm willing to take the time to get my hands dirty. Any plan of approach / pointers? |
It's a bit of a complicated problem. Though this seems to be a common request, we still want to support the current case (where cells are constrained to lie on a single page), and we probably want it to still be the default. Splitting cells across pages can be an opt-in feature. The abstract Prawn::Table::Cell API includes the assumption that a cell will be drawn on a single page. Table sets up a bounding box representing the cell's content area and calls I'd start out by defining a method on each subclass of Cell that determines whether it can participate in this new protocol. Image cells wouldn't; text cells would; subtables might (depending on their content). Then, I'd add a method parallel to Then you'll have to modify Prawn::Table#draw to participate in this new protocol, only if a user has requested this option. Some corner cases you'd have to think about:
Good luck if you'd like to tackle this. I'd love to see it in Prawn; I just haven't had the time to work on it yet. Let us know on the mailing list if you try this out and run into issues. Brad |
Any update on this feature? |
No updates yet. I've posted a summary of the issues involved above for anyone who wants to take a crack at starting. |
"Though this seems to be a common request, we still want to support the current case (where cells are constrained to lie on a single page), and we probably want it to still be the default. Splitting cells across pages can be an opt-in feature." I can see how this would be a tricky problem to solve. But I don't understand why truncating the page should be the default. Is there any use case where users would want the data in their PDF truncated? This seems like more of a bug than a feature request. For anyone else with this problem, I think there's an easy workaround: Just split long rows when you generate your input content. |
Hi Brad. Do you think there is any way one could determine before drawing the table how big the bounding box of each cell is? If so, then a good workaround would be to just split rows that are too long before inputting the data into the table call. I've implemented this sort of solution, but since font characters are all different width, and there are linebreaks, etc..., the number of characters is the box is not a good estimate of whether it will overflow. So I end up splitting the rows too early. Thank you for your feedback on this issue. |
@jsarma do you found a workaround yet for calculating height to split cells? i'm going crazy about this :) |
@fluxsaas Unfortunately, I couldn't find any way to use prawn to estimate the height of the cell for splitting. Instead, I did some experimenting. In my particular case, 1700 characters turned out to be a pretty safe place to split. But this assumes line breaks aren't used heavily. If you split after too few chars, you occasionally end up with cases where both cells are on the same page, but are split. This doesn't look very professional, but it's not a disaster. If you split after too many characters, you end up with the overflow bug which is really bad. Below is the code I used to implement this total hack. It was hastily thrown together, so don't expect too much from it. It would probably function a bit better if recognized line breaks and counted them as 50 characters or something. def self.find_prev_space(s, index) #find last space before index and return it
for i in 0..200
return index - i if (s[index-i].chr==' ')
break if (index-i<=0)
end
return index #could not find space, so just break anywhere
end
#if second column has more than max_size characters, split into multiple rows.
#Repeat first column, and add cont... to it
def self.split_big_row(array, max_size)
return [array] if (array[1].size <= max_size)
src = array.dup
dst = []
count = 0
while (src[1].size > max_size)
i = self.find_prev_space(src[1], max_size)
if (count==0)
label = src[0]
else
label = "#{src[0]} (cont...)"
end
dst << [label, src[1][0..i]]
src[1] = src[1][i+1..-1]
count+=1
end
if (count==0)
label = src[0]
else
label = "#{src[0]} (cont...)"
end
dst << [label, src[1]]
return dst
end |
It's possible to get the height of a cell now before rendering a table, but there should be some defined behavior for when a row exceeds the size of the page. Re-opening for further investigation / research, although it will be a very long time before I can look into this problem myself. |
I am closing all issues for Prawn::Table, because it is being extracted into its own gem with its own repository (https://github.com/prawnpdf/prawn-table). As I close tickets, I'm marking them with a "table" tag, so that @hbrandl can easily find them and optionally move them over to the prawn-table issue tracker. Anything that has the table tag can be assumed to have been unresolved at the time I closed it. |
Still getting this error with Rails '4.2.7.1', prawn (1.3.0) and prawn-table (0.2.1). |
any update on this ? |
Successor to this ticket is prawnpdf/prawn-table#41 |
Here's an example showing this issue:
I believe the expected/desired behavior would to have all content displayed, no matter how many page breaks are required to do so.
Also, I don't think we'd want a bottom border on the first page (or a top border on last page), since we want it to be clear that the cell is continued on the next page.
The text was updated successfully, but these errors were encountered: