Learn how to convert Google Slides into high-resolution PNG images using Google Apps Script. Choose between the Google Slides API and the Google Drive API based on your requirements.
Here’s a useful snippet from Amit Agarwal exploring two methods exploring how to convert Google Slides to PNG images with Google Apps Script. The first approach uses the Google Slides API to get the thumbnail images of the slides, fetch the blob of the image, and then upload it to Google Drive. However, this method has limitations including predefined fixed widths and requires two URL fetches.
The second approach uses the Google Drive API, which offers advantages like generating images with the same resolution as the original slide and requiring a single URL fetch. For both code snippets follow the source link.
Project IDX allows you to use all your favourite IDE extensions and themes, but also offers AI assistance through tools like Gemini Code Assist. It also has one-click integration to many Google products such as Firebase Hosting or deploying your app to Cloud Run. A really handy feature of IDX is the ability to share a workspace with a colleague so you can collaborate and develop together in real time! …
This guide will demonstrate how to develop your Apps script code from within Project IDX, and we will even touch on how to enable Google’s AI Code Assistant to get extra help when writing your App scripts.
The current Apps Script integrated development environment (IDE) has several limitations that can hinder collaboration and productivity. One significant limitation is the lack of real-time collaboration. Multiple users cannot simultaneously edit the same script, making it challenging for teams to work together on projects. This can lead to version control issues and conflicts, especially when multiple developers are making changes concurrently.
Project IDX is an experimental cloud-based IDE developed by Google. IDX is designed to make it easier to create, edit and deploy applications eliminating the tasks of configuring development environments for yourself and your team. For Google Workspace developers already doing local code development using VS Code the interface will be familiar as IDX is also built on Code OSS.
As well as being cloud-based IDX has some useful features built-in including GitHub import, extension and a Gemini code assistant. In addition to real-time collaboration (still highly experimental), IDX features a Gemini-powered code assistant with both a suggestion tool and a sidebar chat agent for code where you can discuss your code and get additional help.
This guide by Josh McMurdo demonstrates how you can set up IDX to develop Google Apps Script projects, including the installation of the clasp command line tool to push/pull code to Apps Script projects. As IDX is able to import existing GitHub repositories if you’ve not done local Apps Script development before I recommend Amit Agarwal’s Google Apps Script Starter kit, which can be cloned in IDX from https://github.com/labnol/apps-script-starter.
Once cloned IDX will automatically run the npm install to add all the dependencies. To switch to your own GitHub repository, create a new repo then in the terminal run the following command replacing YOUR_ACCOUNT and YOUR_REPO:
One other note on Josh’s post you don’t need the Add Gemini API step. IDX comes with Gemini code assist enabled, the Add Gemini API step is only required if you want to use Gemini in your Apps Script solution.
A reminder that Google states “Project IDX is in beta. Project IDX is likely to change and is not subject to any service level agreement (SLA) or deprecation policy. The implementation is subject to change without notice and in future releases. Use caution before proceeding to use IDX in a production environment.” IDX also can’t run Apps Script code so you’ll need to use clasp to push back into your Apps Script project and debug there.
Gassypedia is a bigquery datatset and Google Looker report for analyzing on the Google Apps Script developer ecosystem on Github
The Apps Script developer ecosystem is an exciting and growing space. Bruce McPherson recently published a blog post that analyzes trends in this ecosystem using publicly available GitHub data which has been added to a BigQuery dataset.
Key findings of the post include that the number of Apps Script repositories and developers on GitHub is on the rise. There is a wide variety of Apps Script projects, including add-ons, web apps, and LookerStudio connectors. The report highlights popular OAuth scopes, advanced services, and libraries utilised by developers. It also offers insights into the geographical distribution of developers and the prevalence of tools like clasp.
Bruce acknowledges that the data is limited to public GitHub repositories, which may not be fully representative of the entire Apps Script ecosystem, but it’s nevertheless a great jumping off point if you are interested in exploring Apps Script solutions. You can access the full report via the source link.
Great news for fans of both Google Docs and Markdown! Google Docs recently acquired the ability to export documents directly into the markdown format.
This functionality extends beyond the user interface, with early indications suggesting the Google Drive API might also be capable of converting between Google Docs and Markdown. I confirmed that this could also be achieved by Drive API. This opens exciting possibilities for automated workflows.
Google recently announced in July 2024 that import and export Markdown in Google Docs. This is a user facing features, which Google announced includes the ability to:
Convert Markdown to Docs content on paste
Copy Docs content as Markdown
Export a Doc as Markdown (from File > Download)
Import Markdown as a Doc (from File > Open or “Open with Google Docs” from Drive)
Kanshi Tanaike hasn’t wasted any time in unpicking Markdown conversion capabilities using the Google Drive API. This functionality enables automated workflows for converting between Google Docs and Markdown. There are various scenarios where this can be useful, in particular, given GenAI solutions like the Gemini API often generate markdown there are opportunities to automatically convert these to Google Docs.
As part of the source post there are sample scripts: one for converting Google Docs to Markdown and another for converting Markdown to Google Docs.
For the Markdown to Google Docs it is assumed that there is already a Markdown file in Google Drive. If you have a Markdown text as a string, for example from a Gemini API response, then you can create a formatted Google Doc using the following snippet designed to be used with v3 of the Google Drive Advanced Service:
function sample3() {
// note string is tab sensitive (tabs are converted to code blocks on certain Workspace accounts)
const sampleText = `sample text 1
| a1 | b1 | c1 |
| :---- | :---- | :---- |
| a2 | b2 | c2 |
sample text 2
* sample option1
* sample option2
* sample option3
sample text 3`;
const blob = Utilities.newBlob(sampleText, 'text/markdown');
const fileMetadata = {
name: `Sample MD Conversion`,
mimeType: MimeType.GOOGLE_DOCS,
};
Drive.Files.create(fileMetadata, blob, { supportsAllDrives: true });
}
A Google Cloud run hosted puppeteer with a graphQL interface … In this article I’ll show you how to use this (I’ve called it gql-puppet ) with Apps Script
One of Apps Scripts superpowers is the ability to make HTTP requests to external services. These can be requests to other product APIs, or as in the following example, your own services. In this post from Bruce Mcpherson you can learn how you can use Google Apps Script to interact with a service he has created on Cloud Run which has a deployment of the headless browser, Puppeteer.
To interact with Puppeteer, Bruce has added GraphQL as an application interface. GraphQL is a query language that allows developers to request specific data from an API, making it more efficient and flexible than REST, which often requires multiple requests to retrieve the same data.
As Puppeteer is just a browser there are lots of things you can do like take a screenshot, print a PDF or get the page content. With GraphQL there is an interface layer to do this as well as returning specific data from a webpage.
The article has various code examples for different use cases, such as taking screenshots, extracting table data, and creating PDFs from web pages using Google Apps Script and saving the data in Google Drive. Bruce is providing access to his combined Puppeteer/Cloud Run/GraphQL solution, gql-puppet but you can also find out how you can deploy it as your own service.
This post describes a Google Apps Script function to create a dummy folder structure in Google Drive, including nested folders and files (Documents, Sheets, Slides). It highlights some useful features beginners might find useful such as recursion, randomness, and the use of Google Apps Script services for Drive interactions. The post additionally discusses specific challenges encountered, like using Drive.Files.create for file creation and ensuring compatibility with Shared Drives.
Working with Google Workspace Enterprise customers we recommend using a DEV/Test Google Workspace domain. If you purchase your Workspace licences through a Google Partner you should be able to get a free test domain, which admins can use to test features like Data Loss Prevention, Context Aware-Access without fear of breaking things for your live domain.
Unfortunately there are no convenient settings or data duplication so configuring your test environment can be a challenge. To help create some dummy data with a little help from Gemini I was able to create the following createDummyFoldersWithNesting() function:
To use the script
Copy into the Apps Script Editor
Enable the Google Drive Advanced Service
Configure the settings inside the function for the root folder and the number of files/folders to generate
Gemini suggested I highlighted the following key points:
Recursion: The createNestedFolders function calls itself to create folders within folders.
Randomness: The script randomly determines the number of folders and files to create, and the types of files.
Google Apps Script Services: It uses DriveApp and Drive.Files to interact with Google Drive.
File Metadata: When creating files, it uses the mimeType property to specify the Google Apps Script file type.
Whilst Gemini wrote a lot of the code for me (with a little guidance), there were a couple of gotchas I’ll highlight.
Drive.Files.create instead of DriveApp.createFile(name, content, mimeType) – the current documentation would suggest that you can use the .createFile() method and include a MimeType like GOOGLE_SHEETS, but as explained in this Stackoverflow post Google have said “After extensive consideration, we have determined that DriveApp.createFile() should not be used to create MimeType.GOOGLE_* files.”
I could have asked Gemini to rewrite this to use DocumentApp, SpreadsheetApp or SlidesApp .create() methods e.g. SpreadsheetApp.create() but then I would have to move into a folder, use extra scopes, which all felt a bit messy so instead opted for Drive.Files.create.
Drive.Files.create supporting Shared Drives without a blob – when using Advanced Services there is a bit of cross referencing required between the auto-complete in the script editor and the associated API documentation. For my script I wanted to support creating files in Shared Drive. To do this requires adding the supportsAllDrivesas optionalArgs in the Drive.Files.create(resource, mediaData, optionalArgs) method. As I only wanted blank Docs, Sheets and Slides I was scratching my head as to what to include for the mediaData blob. Fortunately this issue was discussed in the Google Apps Script Community – Google Group and it was clear I could use null or undefined.
An illustration which includes the Google Drive logo. The illustration includes a filing cabinet overflowing with files
This report provides a Google Apps Script to retrieve all files, including those within subfolders, for a designated folder. It addresses the challenges of retrieving files within deeply nested folder structures and obtaining complete file paths.
We’ve shared a couple of approaches to Google Drive reporting using Apps Script in Pulse, this latest comes from Kanshi Tanaike. There are actually two approaches covered in the post one using DriveApp and the other using the Drive API.
Hopefully, the related posts list on Pulse will highlight some of the alternative approaches you can use. I’m slightly obsessed with the .getFileNameWithPath() methods. This isn’t something that is provided in the Google Drive File resource data so it has to be constructed using only the file and parent information so it is interesting to see how this has been approached.
If you are looking at these code examples and struggling to understand them, Gemini (including implementations on gemini.google.com or aistudio.google.com), is a great way to copy the code (even the entire blog post) and start asking questions.
Surely, you have also experienced having a presentation in which you needed to replace old content with new. Replacing text is very simple because you just need to use the Replace function, and you can either do it in the Google Slides user interface.
The problem arises when you need to replace one image with another, for example, if your corporate logo is updated to a new graphic design or if one of your favorite cloud services updates its icons (Gmail, blink blink ;-) It’s still somewhat bearable with one presentation, but what do you do when, like me, you have thousands of Google Slides files on your Google Drive?
This post explores a clever application of the Gemini API’s multimodal capabilities, created by Ivan Kutil. His code utilizes GenAI to automatically detect outdated logos within your Google Slides presentations. The original blog post (March 2024) used the Gemini Pro Vision API. As a sign of how rapidly this area evolves, Google now recommends switching to Gemini 1.5 Flash or Gemini 1.5 Pro.
Switching to the newer APIs is very straightforward as all you need to do is search the source code for models/gemini-pro-vision and replace with models/gemini-1.5-flash or models/gemini-1.5-pro.
For Apps Script projects I lean towards Gemini 1.5 Flash as it is designed for speed. I’m also always looking to opportunities to test the GeminiApp library for Apps Script and very quickly I was able to fork Ivan’s code and use Gemini 1.5 Flash using a service account.
While GeminiApp requires some initial setup, it offers significant advantages:
Easy Model Testing: Experiment with various models quickly.
Built-in Features: Includes functionalities like exponential backoff.
The Google Developer Program gives developers access to a range of new tools and benefits, to allow them to discover and explore all the Google sponsored communities we already offer.
Google recently announced an expansion of the Google Developers Program:
“The program will give developers access to a range of new tools and benefits such as technical assistance from Gemini and allow them to discover and explore all the Google sponsored communities we already offer. Joining is free and open to any developer worldwide.”
One of the headline benefits is when you also join the Google Cloud Innovators program through your Developer Profile, you will get free credits for the Google Cloud Skills Boost learning platform. Your credits will automatically replenish every month, so if you run out you just need to wait a little to continue your learning.
A note for Google Workspace account holders is you may find that your Workspace Admin has disabled the ‘Developer Profile’ service for your domain. If so a friendly email to your support desk might be required, however, given you can collect badges for your Developer Profile you may prefer to create an account with a personal consumer Gmail account.
In 2022, we made it easy to seamlessly access popular Education Technology tools directly in Google Classroom. We partnered with 20+ EdTech companies, including Kahoot!, Pear Deck, IXL, ReadWorks, and Nearpod, to build Google Classroom add-ons. These new integrations let educators and students easily find, use, and grade great content in their favorite EdTech tools without having to navigate to external websites and apps.
Today, we’re excited to make Classroom add-ons generally available to all developers.
Given the number of Apps Script users in EDU today’s announcement the Google Classroom add-ons now generally available for anyone to publish is probably welcome news. Whilst Google Classroom add-ons have been around for a couple of years they have historically only been created by a select few of Google partners.
Before jumping in something key to keep in mind is that while Apps Script offers a low-entry approach for most Workspace add-ons, Classroom add-ons require more technical expertise. They involve building a web application and integrating it with Classroom’s functionalities using the Google Workspace Marketplace SDK. Proficiency in web development languages like Python, Java, or Node.js is recommended and Google have published some example implementations for Python, Java and Node.js.
Whilst there are differences there are overlaps. For example like Workspace and Editor Add-ons you will need to create a Google Cloud project to publish to the Google Workspace Marketplace. As part of this you’ll have to also provide key information such as terms and conditions as well as going through the OAuth verification process.
The Google Developer documentation and other resources are linked from the source announcement.
