AppSheet actually uses the Skia/PDF m111 to generate PDF.
Sometimes when they update the PDF generator, our PDF files will be broken: Wrong pagination, wrong text size, … > The output looks bad and unprofessional.
In some cases, AppSheet is able to fix this. In other cases there is no fix. We need to update all our templates
Here is the story of what I was aware (and affected) of:
Feb 2021
Update from Qt 4.8.6 to Qt 4.8.7.
Change in the font size and column width.
No fix from AppSheet. All Templates needed to be updated.
Mar 2021 Update from Qt 4.8.7 to Skia/PDF m88.
Change in the font size and column width.
No fix from AppSheet. All Templates needed to be updated.
Dec 2021 Update from Skia/PDF m95 to Skia/PDF m96.
Change in the row height.
No fix from AppSheet. All Templates needed to be updated by reducing the line spacing.
Dec 2022 Update from Skia/PDF m107 to Skia/PDF m108.
Change in the pagination.
Fix from AppSheet 5 days later.
Mar 2023 Update from Skia/PDF m110 to Skia/PDF m111.
Change in the text alignment in columns
Fix from AppSheet more than 2 weeks later by reverting to the previous version Skia/PDF m110.
July 2023 Update from Skia/PDF m110 to Skia/PDF m114.
Change in the row height.
No fix from AppSheet. All Templates needed to be updated.
The goal is to find a way how we can prevent this in the future. Maybe by an announcement?
@Fabian_Weller you are absolutely correct. Appsheet team needs to do something about this. Template correction everytime is not a feasible solution. I am having numerous templates and editing each everytime is a tedious task. Something should be done in the server side itself when these updates are rolled out. Do you have any idea who is handling this in the Appsheet team.
@Fabian_Weller How did you manage to get these details of Skia/PDF like the latest m111 i am only able to see m98 as the last milestone in Milestone Release Notes in their webpage
I wasn’t able to follow up on this until today - I did some digging, it turns out that we don’t update the Skia library directly. We call a Google-internal service that generates the PDFs using headless chrome, and those folks are updating Chrome as new versions are available and that updates the corresponding Skia library.
That puts this a bit out of our hands, but I’ve asked our team to look into whether we can pin to a particular chrome version, or potentially keep ourselves a version back, so at least there is time to test if the newer Skia introduces issues.
I’ll follow up here as I have additional information.
Thank you very much @zito for your help. Will you be able to fix the issue that came with the Update from Skia/PDF m110 to Skia/PDF m111? Oor will we have to update our templates?
We don’t have any control over what PDF library is being used by the rendering service - we’ll look at whether there’s a way we can request a particular version, but even if that’s possible, it’s not going to be something we can do immediately.
I’m a little surprised just updating the version of skia broke your templates. I looked at the changelog from m110 to m111, and I don’t see anything that obviously looks like it would affect the rendering. I wonder if there might have been a change in the chrome rendering engine, and that is cascading down into the PDF generation?
Obviously, you know your templates better than I do, but from previous experience with PDF generation from other projects, complex CSS tends to be where things break across different PDF libraries. Could you potentially look at streamlining the CSS/HTML to reduce the complexity? That would likely help future-proof the templates.
Apologies, I know this is inconvenient, its just largely out of our hands. There’s another approach to consider as well, which is to use Apps Script to generate a Google Doc, and then use the Drive API to export that as PDF. The advantage there is that the docs formatting consistently renders in PDF, and the engineering team at Google that owns that system takes backwards compatibility very seriously. I realize that’s additional effort in the short-term, but suggesting it as another option.
That’s what I skimmed briefly - it looked mostly like various library fixes, not rendering changes. Not my area of expertise, of course, so I easily could have missed something.
The Appsheet team needs to do something about this. I have four professional apps affected. I’m a user and I pay for it. If they cause any problems, the least I expect is a quick fix.
The suggested ‘fix’ by Zito might be good for hard coders, but I would think for newbies, this arrangement would be out of the question. Isn’t Appsheet wanting to deliver for citizen developers? No-Code??
I would suggest that most companies using Appsheet heavily rely on a decent output for compliance etc and for this core feature to be out of Appsheets hands is quite extraordinary. When this issues first started last year, I had over 200 apps effected. I picked it up on my Friday morning (Sth hemisphere) and it took me 3 to 4 days to get anyone in Appsheet to recognise the issue (unacceptable). Thankfully finally someone had the smarts to role the Appsheet update back, but by that time, I was swamped with VERY sceptical clients on our ability to deliver a decent app product.
Surely common sense and logic must prevail here and Appsheet take better control of this issue rather than poking at suggested fixes. Pagination of documents has always been cumbersome.
I have noticed a couple of pdf’s irregular formatting as of yesterday, and I am hoping and praying that it does not spread throughout my several Appsheet accounts adding to the BOT issues still being experienced around the globe..
It appears like there is becoming a large disconnect between devs / users with valuable feedback and Appsheet management.
Apologies, I was just thinking of potential ways to future-proof the documents. I obviously recognize that is not the most no-code solution, but I also think that asking people to write CSS to generate documents isn’t very “no-code”, so it didn’t seem completely out of line.
That was also a PDF rendering issue? Do you have a case number I can reference?
Maybe this problems are not directly related to Skia and instead is the backend for GDocs/MSWord to HTML/CSS that is messing things up, because I use HTML/CSS directly and haven’t experienced these problems.
@zito Previously I was in talks with @Phil to solve this kind of issues. It seems he is no longer in the team. Could you point us to the new expert on this area? Thanks!
A quick update, we’ve been able to work with the rendering team to identify the change that caused the change in the rendering behavior. As of now, that’s being treated as a bug by that team, and we are going to switch to use previous version of the renderer, which should resolve the issue for now.
From here, we’ll work with the partner team to reproduce the issue and figure out the path forward. If its a bug, it will get fixed, but there is the possibility that the other team will determine that the old behavior was incorrect and that the new behavior is “more accurate” to the specification (just to manage expectations).
For whatever its worth, the issue that you noted in December and this issue are essentially the same issue, and is related to the print engine shifting to the same layout engine that powers chrome web rendering. Once we resolve this issue, I don’t anticipate further rendering changes in the near term.
Thank you for the feedback Zito. I’ve heard crickets from support.
I am concerned regards your statement “…that the new behavior is “more accurate” to the specification (just to manage expectations).”
So you are saying if my approx 200 templates are currently unformatted with the latest fix, that if its determined that the new system is a better and more permanent fix, then I will have to edit all my templates that remain affected by the new fix?
I am happy that Appsheet are taking this issue seriously as it has been occurring since 2021.
Thank you for your findings Zito. Very appreciated.
[quote=“Craig_Clancy1”]
So youare saying if my approx 200 templates are currently unformatted with the latest fix, that if its determined that the new system is a better and more permanent fix, then I will have to edit all my templates that remain affected by the new fix?
[/quote]
Obviously, that is not what we want to have happen, and I have no reason to believe that is what will happen - and we would push very hard on any suggestion that this doesn’t need resolving. I simply don’t want to say confidently “this is 100% going to get fixed” when the fix is outside of my team’s control.
