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ā.
Firstly, Iād be only focussing on the new Flying Saucer (FS) engine
As @bdw429s said, getting just the essential basic stuff like page number and document sections working
SVG support via the pluggable ReplacedElementFactory which can be used to add support for missing elements, nice if this was pluggable via cfml [LDEV-419] - Lucee
support for CSS rem units, they are often used in modern CSS frameworks like bootstrap [LDEV-2409] - Lucee
@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