I’ve got a bit of personal bias to fixing the fact that page numbers are useless when you use document sections. Besides the fact that I could have really used that on a current project, it’s sort of an embarrassing common feature to not have working. It rules out use of bookmarks, custom section headers, and more.
It would be peachy keen if one could use page number variables in expressions like Adobe too, but I’m not sure if Adobe has some magic sauce in their PDF engine to make that possible. My personal use case would be for being able to tell as the PDF rendered what content fell on what actual PDF page after the engine finished dropping in all the page breaks. Then I could retroactively build a table of contents or Appendix out of that data. i.e., “Chapter 4 starts on page 124”.
@Zackster I went through that list and performed a bulk update on the tickets that appeared to be related to PDF and added the PDF label. Many of them were closed already, but data is still data. here’s the list of tickets I updated to have the PDF label:
I notice that several issues relate to changes in the behaviour of the underlying rendering engine. Changes in the underlying rendering engine will inevitably mean folks will need to rewrite their report markup to match the new engine.
We might be able to assist with documenting things that work; for example, how to centre things etc
I’d be happy if we got Flying Saucer implementation working as advertised with the latest version of the new rendering engine, and sidelining all formatting issues that are related to differences in rendering behaviours to a documentation effort.
How do we cleanly identify a rendering behaviour issue vs a bona fide bug?
Can we classify these issues as “WILL NOT FIX” and offer some assistance around documentation?
I think a quite a few of the core issues carried over from the old engine, reading comments in JIRA one of the reasons for the move to Flying Saucer was limitations of the old engine
Perhaps we could create a cfdocument acid test like they did for HTML? that really helped resolve browsers incompatibilities
@Zackster Sorry, there are two pulls on that ticket. For some odd reason, Pothys added this second pull as a developers-only comment so you probably can’t see it. Here’s the pull for the test:
and here’s the pull for the actual functionality:
You can see that second pull actually has new Java code to add the extract text functionality. Of course, it’s conflicted now since it’s been sitting for a year…
It would rather nice to be able to pass in a struct of hosts with cookies to use with CFDOCUMENT so that any authenticated content it loads via http, i.e. protected images could be accessed without workarounds