Is anyone interested in chipping in and sponsoring some work for bug fixes and enhancements for the CFDOCUMENT / PDF support, aka extension?
Lots of people are frustrated with various issues with the current implementation.
If any users/companies in the Lucee community who need this fixed could help sponsor some work on the PDF extension it would happen a lot faster.
I’d be happy to sponsor some additional development in this area. Do you have a specific scope of works in mind?
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
here’s a list of pdf tagged items (not all cfdocument /pdf related items are labelled correctly and I don’t have enough rights in jira)
https://luceeserver.atlassian.net/issues/?jql=labels%20%3D%20"pdf"
@Zackster if you can point out a list of PDF tickets with incorrect tagging, I can try and fix them.
there are a few false positives but this works.
having two pdf engines also makes working out which engine a bug applies to a bit confusing
https://luceeserver.atlassian.net/issues/?jql=text%20~%20"pdf%20OR%20cfdocument"
@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:
Incompatibility LDEV-1198
Bug LDEV-1153
Enhancement LDEV-1374
Task LDEV-610
Task LDEV-2034
Incompatibility LDEV-641
Incompatibility LDEV-2404
Bug LDEV-701
Bug LDEV-852
Bug LDEV-1846
Bug LDEV-759
Bug LDEV-699
Bug LDEV-1476
Bug LDEV-1300
Bug LDEV-2157
Bug LDEV-1219
Bug LDEV-1235
Bug LDEV-499
Bug LDEV-690
Bug LDEV-1038
Bug LDEV-1113
Bug LDEV-679
Bug LDEV-1534
Bug LDEV-948
Bug LDEV-681
Bug LDEV-1562
Enhancement LDEV-94
Bug LDEV-985
Bug LDEV-986
Bug LDEV-1500
Bug LDEV-92
Bug LDEV-93
Bug LDEV-2348
Bug LDEV-1716
Bug LDEV-1273
Incompatibility LDEV-1941
Bug LDEV-1943
Incompatibility LDEV-1825
Bug LDEV-1385
Bug LDEV-2256
Bug LDEV-2255
Bug LDEV-1004
Enhancement LDEV-1698
Bug LDEV-827
Bug LDEV-2047
Bug LDEV-1519
Bug LDEV-1356
Task LDEV-1470
Enhancement LDEV-419
Bug LDEV-2405
Enhancement LDEV-1847
Bug LDEV-232
Bug LDEV-2409
Bug LDEV-1546
Bug LDEV-1849
Bug LDEV-1850
Bug LDEV-967
Bug LDEV-2326
Bug LDEV-989
This should be a better list. All open tickets labeled PDF. There are 30, most of which are in the backlog.
Non-functional watermarks are especially annoying:
LDEV-1519 cfpdf addwatermark error
LDEV-2256 CFPDF Add watermark problem in openJDK8
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
It seems that for some tickets like this one, the work was done a full year ago and submitted as a pull request, that rotted on the vine with no love.
https://luceeserver.atlassian.net/browse/LDEV-1941
Very sad to think I could be using that feature right now if the pull had simply been merged in a timely manner.
Ummm, that’s only a test case 
@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:
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…
ahhhh, oops, ok
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