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
A variant of "ShowEntire" that does not throw an exception. #861
Comments
Thank you for reaching out 😄 I am not entirely sure of what behavior you want to achieve. Would you please provide some visual examples? |
Examples In all of the examples, the part of the content with the red background color is user-generated. This is the part of the content that we do not want to span multiple pages unless we have no other option. Example 1 The content is short enough to comfortably fit inside the first page.. Example 2 The content is too long to fit inside the first page, but is short enough to fit inside a single page. Using Page 1: Page 2: Example 3 This is where we run into a problem. The content is too long to fit into a single page. Since we're using Instead of this behavior, ideally we'd like to have a method available (i.e. Page 1: Page 2: Obviously I have very little idea about the inner workings of the library, and if what I'm asking for is even feasible. But if it is, it would greatly help us out. Code used to generate the examples
|
My suggestion is to use the |
Well, as I mentioned in the original post, I don't know in advance how large the the header or footer are going to be. For a simplified example of our use case, lets presume the user can modify the following properties: public struct HeaderSettings {
public HeaderType Type { get; set; } // Text or Image
public string Text { get; set; } // Used when header type is "Text".
public float FontSize { get; set; } // Used when header type is "Text".
public byte[] Image { get; set; } // Used when header type is "Image".
} public struct FooterSettings {
public FooterType Type { get; set; } // Text or Image
public string Text { get; set; } // Used when footer type is "Text".
public float FontSize { get; set; } // Used when footer type is "Text".
public byte[] Image { get; set; } // Used when footer type is "Image".
} I have no idea how big the header or footer are going to be. That also means there is no easy way for me to safely use The only way I could think of to safely use |
I wonder... we could create a variant of EnsureSpace that attempts to use all available vertical space as its argument. I already have trouble with naming: ShowEntire, EnsureSpace... and how that third option could be named? |
I think this is something like a feature I would also need for my current project, I need to show a table, and I need the table to be shown in its entirety unless absolutely impossible, I don't know how many rows the table will have, and the rows can have different heights. Using ShowEntire mostly works but can throw stray exceptions once in a while, I think that a 'safe' version of the ShowEntire, something like a TryShowEntire() that would try to fit the content on the current page, if that is not enough, tries to fit it in 1 page, if it still does not fit, it just breaks the content to 2 or more pages. As @MercinaM said I was about to implement this using Dynamic Component, but a more native way to do this would be greatly appreciated. |
Is your feature request related to a problem? Please describe.
I'm trying to render a block of user-generated content. The content is entered by an end-user in a WYSIWYG HTML editor. I have no idea in advance what the content is, and how much space I will need to render it.
The requirement:
The aforementioned block of content should always be rendered in its entirety, unless there is no way to do so (the content cannot fit inside a single page).
The problem:
To my understanding there are currently 2 ways of solving this issue.
The first is using
ShowEntire
, which only works if the content can fit inside a single page. Since the content in this case is user-generated, I as the developer cannot guarantee this. Furthermore, since QuestPDF throws an error if the content does not fit, I cannot use it since it may cause the PDF generation to fail.The second is using
EnsureSpace
. The problem is that it's not just the content that the end-user has control over, but they can also modify the font size and change the content inside the header and footer of the document. Consequently, even though I know the page size (A4) and the margins, I don't know of a consistent way to calculate aminHeight
value that corresponds to the actual available content height of the page. If I set the value too low, then QuestPDF won't add a page break, even if it could fit the entirety of the content on a single page. If I set the value too high, then I run into the same problem as withShowEntire
.Describe the solution you'd like
I would like to have a variant of
ShowEntire
that does not throw an exception if the content cannot fit on a single page, but instead simply behaves as ifShowEntire
hadn't been used.Describe alternatives you've considered
I've tried implementing a solution using a dynamic component, which to my knowledge is the only way of getting actual measurements for both the available page size and the elements I'm rendering on the page. If I could return more than a single page's content from the dynamic component's Compose method, then I would have a (passable) solution - If the content does not fit inside the first page, simply render it on the second (and beyond). But since, once again, the dynamic component throws an exception if I return more than a single page's worth of content, I run into the same problem as with
ShowEntire
.The text was updated successfully, but these errors were encountered: