[zamoragregory]

Summary

mPDF keeps every float it has closed in a document-wide list, and rescans the whole list each time it places a float, so a long layout of floated rows slows down quadratically. PDF for GravityView 2.0.0 stops pruning that list itself on Gravity PDF 6.18+, because it expects 6.18 to bundle the mPDF fork's fix (GravityPDF/mpdf#9). 6.18 bundles upstream mPDF instead, so neither side prunes, and long directory PDFs slow down: 1,000 rows take 7.8 s instead of 1.9 s. 6.18 now bundles mPDF from the fork's new gravitypdf-v6 branch, which is upstream mPDF's development HEAD plus Gravity PDF's fixes:

• Drop float records the layout has already buried (v6) mpdf#819 brings Fatal Error When cURL not installed #9's float pruning: Mpdf::addFloatDiv() drops the float records a new float has buried, and Tag\BlockTag records both of its floats through it.
• Accept an existing cache directory that is_writable() calls read-only (v6) mpdf#820 fixes Cache::createBasePath() rejecting a writable network share that is_writable() calls read-only (Cache rejects a writable directory when is_writable() gives a false negative (network storage) mpdf#708).
• composer.json installs mpdf/mpdf dev-gravitypdf-v6 from the fork, and the lock pins 2a88146a. No other package changes.
• The php-scoper patcher for the Cache.php fix is removed, since mPDF now carries it.
• New tests check the bundled mPDF prunes floats and still lays out the pages the same.

Try it

1. Run composer install, then composer prefix.
2. vendor_prefixed/mpdf/mpdf/src/Mpdf.php now has addFloatDiv(), and vendor_prefixed/mpdf/mpdf/src/Cache.php no longer calls is_writable().
3. With PDF for GravityView 2.0.0, generate the directory PDF of a View with a few hundred entries in the Table layout. It's about as fast as with PDF for GravityView's own pruning on 6.17.2. Before this change it slowed down sharply as the View grew.

Test plan

• yarn test:php -- --filter 'Test_Mpdf|Test_Cache'
• The release zip's vendor_prefixed/mpdf/mpdf/src/Mpdf.php contains addFloatDiv()

More info

• Benchmark (PHP 8.3), with rows of three floated cells streamed into one open container, as PDF for GravityView 2.0.0 writes a directory on 6.18 (its own pruning off):

  Rows	RC1's mPDF	This change	RC1's mPDF with PDF for GravityView's own pruning
  250	0.85 s	0.48 s	0.48 s
  500	2.46 s	0.96 s	0.92 s
  1,000	7.76 s (3,000 float records kept)	1.92 s (3 kept)	1.84 s

  The page counts are the same in every case. The benchmark was taken with the earlier scoper-patch version of this PR, which applied the same code as Drop float records the layout has already buried (v6) mpdf#819.

• gravitypdf-v6 is mpdf/mpdf development at a981bb7b (what RC1 locks) plus $this->data->template_fontdata_location no longer used #819 and Clear mPDF cache when font is deleted #820. mPDF's full suite (1,000 tests) passes on it on PHP 8.5, and the fork's CI (tests, snapshots, static analysis, coding standard) passes on the branch since Run CI on gravitypdf-v6 mpdf#821 turned it on.

• The ServiceFactory patcher stays: it points mPDF at Gravity PDF's own Cache class.

• Tests:

  • test_dropping_buried_floats_leaves_the_pages_unchanged writes 50 rows with and without pruning and compares the page content streams, as mpdf#9's own tests do.
  • test_floats_buried_by_a_new_float_are_dropped fails if the bundled mPDF doesn't prune: 150 float records instead of 3. That catches a later composer update that loses the fork's fix.

• composer install/composer prefix haven't been run locally for the fork switch. This PR's CI builds and tests it.

• On a test site with the earlier build's mPDF, PDF for GravityView 2.0.0's single and directory PDFs for six Views have the same page counts as on RC1. A directory PDF with signed shortcodes still signs all 16 row links.

• This is for 6.18.0 only, with no development PR. development still locks upstream mpdf/mpdf and will move to the fork with 7.0.

• Adds a CHANGELOG line, because it also speeds up any long float layout in a custom template.

🤖 Generated with AI