Welcome Guest Search | Active Topics | Sign In | Register

EO.Pdf incorrectly applying ConvertHtml on orientation change post 21.2.70 Options
Posted: Thursday, January 6, 2022 11:43:32 AM
Rank: Member
Groups: Member

Joined: 3/18/2014
Posts: 13
EO.Pdf version 21.2.99 seems to have introduced a bug (also broken in 21.3.18) in ConvertHtml when being used with PDFs with orientation changes, this works fine on 21.2.70 and earlier.

We use EO to apply a "stamp" to each page of a PDF. Most of the time these are simple documents with just portrait orientation pages. However, sometimes they are a mix of portrait and landscape. When using ConvertHtml to apply a stamp to these documents the stamp appears on every page in the first section of orientation, but only on the first page of each subsequent section of orientation.

It's easiest to see in the PDFs, but essentially... Say you have a 30 page document, pages 1-10 are portrait, pages 11-20 landscape, and 21-30 portrait. If we stamp this PDF with 21.2.70 or earlier all 30 pages get their stamp, as expected. But starting in 21.2.99 pages 1-10 are stamped, but only page 11 (not 12-20) and only page 21 (not 22-30) are stamped. ConvertHtml seems to be only applying the html to the "first" page after an orientation change.

Repro code emailed to support, with PDF output in debug directory. You can see the "stamp" (Hello in lower right) on every page of PDF in 21.2.70 and earlier, but in 21.2.99 and later only the first page after each orientation change. Just change the project to use different versions and you can repro the problem.
Posted: Monday, January 10, 2022 9:19:02 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 23,159

We have sent you a new build that should resolve the issue for you. Please check your email for the download location and let us know how it goes.

Posted: Monday, January 10, 2022 10:13:36 AM
Rank: Member
Groups: Member

Joined: 3/18/2014
Posts: 13
You guys are awesome as usual, I can confirm that build fixes the issue in my repo document, and more importantly, fixes it w/the original document that exposed the issue. Yay EO!

I assume that fix will make its way into the nuGet builds when you move over to 64-bit in the next release? We back-leveled our current build and that's fine for now. If this fix will be in the normal releases shortly (and hopefully nuGet will be 64-bit then) we'll just wait for the formal release to use in production.


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.