HTML to PDF conversion broken

[cas001dk]

So it seems within the last week or so, the HTML to PDF conversion method we use has broken. The page size is completely different and there seems to be several corrupted characters within the generated PDF. 

We use the OneDrive method of converting to get around using Encodian etc. This is sadly the way I have to do it to be within our licensing plan.

Has anyone else had this issue? Potentially found a fix or heard Microsoft mention anything about it?

[AlexEncodian]

@cas001dk 

There have been several posts about this on the forums so it seems to be a wider Microsoft issue. The only thing you can really do is raise a ticket with Microsoft.

[jbman88]

Yep, broke a handful of flows we had running too. Got complaints about awkward formatting and spacing. Stuck waiting on MS.

[cas001dk]

Did you or your team manage to contact Microsoft? If so, I'd love to be kept in the loop. Sadly we have to do sort of a workaround to get in contact here, and I'm still in the process of that. 

[jbman88]

They responded to my ticket saying they are "currently doing some research in regards your case" and asked a bunch of questions that I had already answered in the initial ticket, to further explain why it wasn't us. Flows hadn't been touched in over a year. That was Friday midmorning and we're into Monday so yep, going through the process. I'll certainly circle back when I hear more.

[cas001dk]

Great! Thank you. Not always an easy process but I would definitely prefer a proper answer and solution from Microsoft compared to reworking several flows using this PDF conversion. 

[jbman88]

This is sort of a half-win, as is usually the case.

Here is what Microsoft sent to me for things to check that ultimately led me to the fix:

1. Open the HTML file in a web browser to ensure that the styling is correct.

2. Check if there are any external CSS files linked to the HTML file. Make sure that the paths to these CSS files are correct and accessible.

3. If the styling issue persists, consider using inline CSS styles instead of external CSS files. Inline styles are more likely to be preserved during the conversion process.

4. Ensure that the HTML code is valid and well-formed. Any syntax errors or missing tags can cause issues during conversion.

5. Remember to test the converted PDF file to verify that the styling is preserved as expected.

Long story short, I had to rewrite the inline-styling portion of the code and our handy little PDF's are back to what they looked like prior to this.

Short story long, when I wrote the HTML portion of the flow, I had to do so with the added variable of Power Automate's PDF conversion process. This process made some odd changes to the formatting when it converted the HTML to a PDF, so we had to counter those changes with additional styling to make it look good. I can only speculate here but I think they updated something on their end where it stopped auto-applying some of those (probably well-intentioned) styling/formatting oddities during the HTML - PDF conversion.

To fix our formatting issues, I downloaded one of the flow-generated HTML files that are automatically stored in OneDrive, opened it in the browser, tweaked the code in the inspector, took a look at the print preview until it was closer to the original, applied the same changes to the flow in Power Automate where you generate the HTML, and, lastly, reran the flow. Rinsed and repeated until the PDF's were as close to their prior appearance as I could get. Most styling that needed adjusted were lower values for heights, widths, & margins, along with some adjusted font sizes & the addition of an Arial font family.

We have two flows being utilized that generate PDF's in this fashion and both were fixed by going through this process, so I certainly hope this helps you too!