I’ve just started using your PDF-generation library and so far I am very pleased with the results. I have a couple of features I would love to see implemented though:
Keep-together: The page-splitting seems to work very well, but sometimes you have elements which you would prefer not to be split. Of course if this element is too large for a page, it should still be split. I would love to be able to have the possibility of using a class to indicate that an element should be entirely moved to the next page instead of splitting, unless it is already at the top of a page.
Scaling: While I don’t agree with your decision to treat px as pt (they are very clearly defined to be respectively 1/96 and 1/72 of an inch), at least your documentation on the issue is great. To get around it, I’ve used css-scaling, which seems to work fine. I do, however, encounter some issues with clipping on absolutely positioned elements, mainly headers/footers, but nothing I havn’t been able to solve. But it would be great if scaling was built into the API, it would solve the px/pt problem completely and might be useful in other scenarios where the rendered size should be different from print-size. Simply including “scale: 0.75” as a draw-dom option and then upscaling page-size and down-scaling all calculated sizes and positions in the output seems like it should be possible.
First page margin: This should be rather simple, but would be very useful I think. Often you don’t want as much info in the header of the first page, as it will include the title and subtitle of the document. If you could specify the margin for the first page separately, you could better handle this.
Headers on split tables: Splitting a table across multiple pages works great, but has one problem: the table header will only be shown on the first page (and presumably the footer will stay on the last page). There are two problems with this: firstly, showing the header on the second page will make the table much more usable for the reader. Secondly, the header often has column width directly applied to it. This width is not copied when split, so the second-page columns will be automatically sized. I realize this might be quite complicated and could probably also raise more problems, like how to indicate to the user that this is a split table, but I imagine many people would find it useful.
Force black/white only: I’ve run into an issue when trying to print a table with every other row highlighted in a slight blue-gray (background #f3f4f8, border #eaebef). This looks great in the browser and in the PDF, but when printed both the stribes and the borders are almost invisible. This is most likely a problem with the printer, but might just as well be a problem in a customers printer. Printing as B/W resolves the issue, so being able to force all colors to be converted would be great. “filter:grayscale(100%)” doesn’t seem to be respected (I suspect because computed styles are not affected by this).
Hopefully some or all of these could be possible to implement at some point. Otherwise, keep up the good work :)
2 Answers, 1 is accepted
Thank you for your feedback. I've discussed each of them with the lead developer of the PDF Export feature and we agree with them in general.
Keep-together, scaling, first page margin all make sense. We'll leave them to our PM for prioritization.
Headers on split tables is a tricky one to implement indeed. We'll try it nonetheless as it seems hugely useful for large tables, such as our own Grid.
Force black/white only is the only one that doesn't make sense right away. Printer settings typically allow you to choose that conversion at print time.
I've updated your Telerik points as a token of gratitude for your involvement.
Regards,
T. Tsonev
Telerik
Rank 1
Sounds great, thank you.
And you're right, on second thought the black/white issue is much easier solved with a bit of CSS if problems arise. It was probably included in the list a bit hastily.