Answers.Body: <p>It seems the later version of dompdf is less forgiving of minor lapses in HTML syntax. In the template there were a few instances of the absolute position information specified as <em>4.1 cm</em> or <em>25 px</em> instead of <em>4.1cm</em> or <em>25px</em>. The extra spaces obviously did not cause problems in the earlier version of dompdf but now causes dompdf apparently to ignore the position parameters. So my problem was caused by about 5 spaces in the wrong places and once removed the templates functioned as expected.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-09-14T08:14:35.140Z
Answers.LastActivityDate: 2023-09-14T08:14:35.140Z
Answers.UserDisplayName: de Oldphart
Body: <p>In our Drupal 7 CiviCRM system I created HTML templates to produce PDFs that precisely positioned text on an A4 sheet (such as a tear-off return coupon and mailing address for a window envelope). This worked fine for years. Then we upgraded to Drupal 9 and dompdf 2.0.3. When I tried it with the new system there was no formatting and it appeared to simply dump the raw text into a PDF. The templates haven't changed. I expected I might have to re-locate an image used as a letterhead, but not the mess that came out.</p>
  <p>Any clues, please?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-09-13T15:15:28.227Z
Comments.Text: Have you tried using `wkhtmltopdf`?
Comments.UserDisplayName: Coleman
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-09-13T16:21:22.747Z
Comments.Text: No, not yet. Just trying to go with what our hosting company has set up for us, and trying to find out what changed between versions.
Comments.UserDisplayName: de Oldphart
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-09-13T18:48:17.223Z
Comments.Text: Did you also upgrade civi? What versions? One thought is that newer civi is more picky about bad smarty in the template. e.g. do you have `<style>` tags without `{literal}` tags around it? Is CIVICRM_MAIL_SMARTY on or off in civicrm.settings.php? Also if you turned off `DOMPDF Enable Remote Images` at Administer - system settings - misc then images might not work.
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-09-13T19:28:43.823Z
Comments.Text: Thanks. Our current Civi stands at 5.58.1 and was generally reasonably up-to-date under D7, so we are probably caught up regarding Civi's Smarty pickiness. Smarty tokens are on. We use them routinely in our email membership renewals system with no issues. I created the templates in the Civi template editor which seems to have its own mind about how to write HTML and that doesn't always align with current standards. Bottom line, however, is that the templates did work with a reasonably current Civi installation but stopped when dompdf was updated.
Comments.UserDisplayName: de Oldphart
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-09-13T19:54:08.187Z
Comments.Text: Hmm dompdf was updated to 2.x in 5.51 and 2.0.3 in 5.58. It was security/image related so maybe some url in your template is getting blocked in dompdf? The smarty pickiness isn't until after 5.58. Maybe also check the drupal side doesn't have its own conflicting copy of dompdf?
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-09-13T20:53:38.247Z
Comments.Text: Demerit: Your suggestion that Civi may be more picky about smarties in the template got me wondering of Civi or more likely dompdf has become more picky about the html code in general. I ran the template source through the W3C Markup Validation service and it flagged up errors on lines that had 10 px or 4.1 cm instead of 10px and 4.1cm.  I fixed all those and suddenly my template is looking correct. I'll to a bit more testing in the morning and, I hope, post an answer to my question. Thanks for getting me thinking in the right direction.
Comments.UserDisplayName: de Oldphart
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2023-09-13T21:34:58.830Z
Comments.Text: Cool. You should post that as an answer below, and you're allowed to mark your own answers as answered.
Comments.UserDisplayName: Demerit
Tags: <pdf><printmerge><dompdf>
Title: HTML templates not working after upgrade from Drupal 7 with dompdf 1.2.1 to D9 with dompdf 2.0.3
ThreadText: # HTML templates not working after upgrade from Drupal 7 with dompdf 1.2.1 to D9 with dompdf 2.0.3
  
  (Asked by: username_0 on 2023-09-13)
  
  In our Drupal 7 CiviCRM system I created HTML templates to produce PDFs that precisely positioned text on an A4 sheet (such as a tear-off return coupon and mailing address for a window envelope). This worked fine for years. Then we upgraded to Drupal 9 and dompdf 2.0.3. When I tried it with the new system there was no formatting and it appeared to simply dump the raw text into a PDF. The templates haven't changed. I expected I might have to re-locate an image used as a letterhead, but not the mess that came out.
  
  Any clues, please?
  
  **Tags:** pdf, printmerge, dompdf
  
  > **Comments:**
  > **username_1**: Have you tried using `wkhtmltopdf`?  
  > **username_0**: No, not yet. Just trying to go with what our hosting company has set up for us, and trying to find out what changed between versions.  
  > **username_2**: Did you also upgrade civi? What versions? One thought is that newer civi is more picky about bad smarty in the template. e.g. do you have `<style>` tags without `{literal}` tags around it? Is CIVICRM_MAIL_SMARTY on or off in civicrm.settings.php? Also if you turned off `DOMPDF Enable Remote Images` at Administer - system settings - misc then images might not work.  
  > **username_0**: Thanks. Our current Civi stands at 5.58.1 and was generally reasonably up-to-date under D7, so we are probably caught up regarding Civi's Smarty pickiness. Smarty tokens are on. We use them routinely in our email membership renewals system with no issues. I created the templates in the Civi template editor which seems to have its own mind about how to write HTML and that doesn't always align with current standards. Bottom line, however, is that the templates did work with a reasonably current Civi installation but stopped when dompdf was updated.  
  > **username_2**: Hmm dompdf was updated to 2.x in 5.51 and 2.0.3 in 5.58. It was security/image related so maybe some url in your template is getting blocked in dompdf? The smarty pickiness isn't until after 5.58. Maybe also check the drupal side doesn't have its own conflicting copy of dompdf?  
  > **username_0**: username_2: Your suggestion that Civi may be more picky about smarties in the template got me wondering of Civi or more likely dompdf has become more picky about the html code in general. I ran the template source through the W3C Markup Validation service and it flagged up errors on lines that had 10 px or 4.1 cm instead of 10px and 4.1cm.  I fixed all those and suddenly my template is looking correct. I'll to a bit more testing in the morning and, I hope, post an answer to my question. Thanks for getting me thinking in the right direction.  
  > **username_2**: Cool. You should post that as an answer below, and you're allowed to mark your own answers as answered.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2023-09-14. Score: 1 | Accepted answer
  
  It seems the later version of dompdf is less forgiving of minor lapses in HTML syntax. In the template there were a few instances of the absolute position information specified as *4.1 cm* or *25 px* instead of *4.1cm* or *25px*. The extra spaces obviously did not cause problems in the earlier version of dompdf but now causes dompdf apparently to ignore the position parameters. So my problem was caused by about 5 spaces in the wrong places and once removed the templates functioned as expected.
  
  
  ---
  
  