Generate PDF from already-formatted Glide page

I have a long page (~30+ pages if printed) that I have formatted using the Glide interface that I’d like to make a printable PDF. Due to how Glide works, it gets stuck in the frame and won’t display in full on its own. It is pretty complicated, with filters on rich text components to pull out specific data and display it just right on the page.

I know there are some options to export the data to external templates or even embed a template in a Table cell/column, but this would be a very big/ugly piece of code and I’m not sure how to properly format and filter everything.

Is there any workaround or solution in place?

So you generated HTML & CSS, not a PDF, and now you want to convert it to a PDF?

I think this could be a good use case for Glide x DocsAutomator.

I have a page in my Glide app that is made up of multiple rich text boxes, some nested inside of custom collections to filter out specific information, and presented in a particular way with HTML markup. I want to be able to print this out as a long document to a PDF.

1 Like

I have looked at DocsAutomator a little and it might be the closest solution I can use. But here’s a question: I have a table that has, say, 10 columns and 100 rows. I want to have the template show data from a specific set of columns, maybe the ones that are labeled “Friday” only, and have them in a particular order, say “organized by start time.” Would I be able to do that?

Yes.
Use a Query column to target just the rows you want (by applying one or more filters), and order them as you wish. Then use that to feed the integration.

2 Likes

Also beware you have to set up the variable in advance for DocsAutomator, and enable Markdown formatting for your case. If you’re using HTML, find a way to convert it to Markdown (and accept that not everything will be converted), before feeding it to DocsAutomator.

1 Like

Instead of doing:

data > html > markdown > DocsAutomator

I think I’d do something like:

data > html > layout editor
data > DocsAutomator

Two separate column groups in the data editor if need be. Something like that.

@ThinhDinh

1 Like

That would also work, but it depends a bit on how complex the HTML is. On your point, I would make sure that the HTML doesn’t involve anything Markdown can not replicate, else it’s not “what you see is what you get” from the app to the PDF.

I understood that was your approach with data > html > markdown > DocsAutomator. That would be ideal. My approach is more “what you get is more or less what you see, and that’ll be good enough because it’s easier to set up”.

The HTML stuff I have is relatively minimal. Most of it could easily work in markdown, but there are a couple align-left/align-right bits and a big section that displays the data as a series of 2x2 tables (I need a format of “Time / Place” on the left and “Title / Description” on the right for an itinerary).

This was more a comment for @MJolley , I would be surprise that when I generate a PDF from something I see on the screen, the resulting file doesn’t match.

If there’s something that’s not able to be replicated in Markdown, if your structure allows it, break different parts into different variables, and hardcode the non-replicable designs in the template doc. I think that’s about the only way this can work.

1 Like