We\u2019ve already looked at ways to generate document samples using Adobe Acrobat Services. But how can we do even better?<\/h2>\n\n\n\n\n\n<\/p>\n\n\n\n![\"Raymond](\"https:\/\/miro.medium.com\/v2\/resize:fill:88:88\/1*ldF-FsLonNyTUOmQ7cIV_g.jpeg\")
<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/a><\/p>\n\n\n\n\n![\"Adobe](\"https:\/\/miro.medium.com\/v2\/resize:fill:48:48\/1*riyFijvwTfGcWNf1guRNtg.png\")
<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/a><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n![\"\"]()
<\/picture><\/div>\n<\/div>\n<\/figure>\nIn our previous post<\/a>, we discussed how to use Adobe Acrobat Services<\/a> to generate PDF \u201csamples\u201d of documents.<\/p>\nSo for example, an online bookseller could use our APIs to automate the process of creating a 5-page preview of the book with content prepended in front describing how the file was a sample only.<\/p>\n
While that process worked well (and be sure to read that post<\/a>!), we can take it a step further and create even better samples. How?<\/p>\nIn our previous example, we used a static PDF with generic text to \u2018prepend\u2019 our samples. While it was kept simple for the demo and could have been embellished, the sample didn\u2019t actually reflect the content of the same in any particular way.<\/p>\n
We can greatly enhance our workflow by using dynamic<\/em> content for our prepended document instead. This will be done using the Document Generation API<\/a>.<\/p>\nThe Document Generation API lets you use Microsoft Word to create a \u201ctemplate\u201d.<\/p>\n
The template is just a regular Word document with tokens intermixed with the regular content. The Document Generation API then lets you pass that Word doc to our service, along with your custom data, and together the content is merged and a new PDF is created. (You can also create a new Word document as well.)<\/p>\n
If you haven\u2019t had a chance yet to play with this API, check out our excellent quick stats<\/a> for an introduction.<\/p>\nFor now though just know we are going to use Word to create a template for our sample creation process. Let\u2019s take a look at that document now.<\/p>\n\n\n![\"Screenshot]()
<\/picture><\/div>\n<\/div>\n<\/figure>\nIn the screenshot above, you can see a mix of \u201cregular\u201d Word text along with some words surrounded by curly braces ({{ }}) in the text.<\/p>\n
In the first paragraph, the words title<\/code>, author<\/code>, and pageCount<\/code> are all surrounded by curly braces and represent tokens.<\/p>\nWith the Document Generation API, we can send this Word document along with data for those values, and get a PDF generated with ‘real’ values replacing the tokens.<\/p>\n
Now our sample will actually address the content it’s sampling, giving details about the document’s title, author, and number of pages.<\/p>\n
As an aside, this is one of the simplest<\/em> things you can do with the Document Generation API. Along with simple token replacements, you can have dynamic lists, tables, conditional content, and even dynamic images.<\/p>\nNone of that is required for this particular demo, but keep in mind we\u2019re barely scratching the surface here.<\/p>\n
Your next question may be \u2014 how do we get<\/em> the title, author, and number of pages of a PDF? We can make use of the PDF Properties<\/a> API which, as you can probably guess, will return the properties of a PDF document.<\/p>\nHere\u2019s an example of the output returned from a PDF:<\/p>\n
Note that there is an optional argument, pageLevel<\/code>, that returns even more information about page content. Another thing to note is that the SDKs return properties in a slightly different format. It’s the same data, just with different labels essentially.<\/p>\nLooking at the sample above, we can see our three values (Author, Title, page_count) are there, so let\u2019s look at how we can bring this all together.<\/p>\n
Let\u2019s now turn to the updated workflow that will process our PDFs. If you read the previous post<\/a> (and I highly encourage you to do so), you\u2019ll remember there were two scripts.<\/p>\nThe first one simply figured out what PDFs needed to be processed. It did this by looking at an input directory and seeing which files did not<\/em> exist in a corresponding output folder.<\/p>\nIn this version, the code in this file has changed in one small way. Instead of specifying a file for the PDF to prepend to our samples, we instead point to the Word doc:<\/p>\n
As that\u2019s the only real change, so let\u2019s get right into the new PDF processing script. We\u2019ll focus on the changes from the previous version.<\/p>\n
First, let\u2019s look at the main entry point, makeSample<\/code>, which is called by the previous script:<\/p>\nFrom the top, we begin by getting our access token. We use the credentials generated by Adobe\u2019s developer console and exchange them for the token.<\/p>\n
Next, we upload the PDF that we\u2019ll be creating a sample from and store it in the asset<\/code> variable.<\/p>\nNow we need to generate our dynamic PDF that will be prepended. First, the Word doc is uploaded and the result is stored as prependAsset<\/code>.<\/p>\nWe need our data for the token. To accomplish that, we use a new function, makePropertiesJob<\/code>, which wraps a REST API call to the PDF Properties endpoint.<\/p>\nHere’s that call:<\/p>\n
When this job is done, we then need to copy out the value we care about: author, title, and page count.<\/p>\n
Note that in our testing, author and title weren\u2019t always available, hence the use of the Elvis operator to handle those cases. The end result is a new, simpler object named documentInfo<\/code>, that contains the information we want to use in our generated PDF.<\/p>\nYou can see this passed to our next new function, makeDocumentGenerationJob<\/code>. Not surprisingly, this looks very similar to the last function, just with slightly different attributes and a new endpoint:<\/p>\nAnd that\u2019s it! The rest of the main function simply uses the Combine PDF<\/a> functionality that we used in the last post.<\/p>\nRemember, this API not only lets you combine multiple PDFs but also lets you specify a range of pages to combine. We use this to combine our \u2018prepend\u2019 PDF and a slice of the main PDF.<\/p>\n
Here\u2019s an example of what that first page would look like:<\/p>\n\n\n![\"PDF]()
<\/picture><\/div>\n<\/div>\n<\/figure>\nAs an aside, in our use of Document Generation, all of the data came from the result of the PDF Properties API.<\/p>\n
In case it wasn\u2019t obvious, we can use any<\/em> data. So for example, I could have included a token for the URL showing where someone might purchase the full book.<\/p>\nWe would do that by adding the token to the Word document, and in our code, adding another key and value to the data passed to the Document Generation API.<\/p>\n
If you want the complete source of this version, check out the repo at https:\/\/github.com\/cfjedimaster\/document-services-demos\/tree\/main\/article_support\/book_demo<\/a>. This version uses makeSamplesv2.js<\/code> and pdfProcessorv2.js<\/code>. Be sure to sign up for your own credentials<\/a> and let us know what you think!<\/p>\n<\/div>\n
<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/a><\/p>\n <\/a><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n In our previous post<\/a>, we discussed how to use Adobe Acrobat Services<\/a> to generate PDF \u201csamples\u201d of documents.<\/p>\n So for example, an online bookseller could use our APIs to automate the process of creating a 5-page preview of the book with content prepended in front describing how the file was a sample only.<\/p>\n While that process worked well (and be sure to read that post<\/a>!), we can take it a step further and create even better samples. How?<\/p>\n In our previous example, we used a static PDF with generic text to \u2018prepend\u2019 our samples. While it was kept simple for the demo and could have been embellished, the sample didn\u2019t actually reflect the content of the same in any particular way.<\/p>\n We can greatly enhance our workflow by using dynamic<\/em> content for our prepended document instead. This will be done using the Document Generation API<\/a>.<\/p>\n The Document Generation API lets you use Microsoft Word to create a \u201ctemplate\u201d.<\/p>\n The template is just a regular Word document with tokens intermixed with the regular content. The Document Generation API then lets you pass that Word doc to our service, along with your custom data, and together the content is merged and a new PDF is created. (You can also create a new Word document as well.)<\/p>\n If you haven\u2019t had a chance yet to play with this API, check out our excellent quick stats<\/a> for an introduction.<\/p>\n For now though just know we are going to use Word to create a template for our sample creation process. Let\u2019s take a look at that document now.<\/p>\n In the screenshot above, you can see a mix of \u201cregular\u201d Word text along with some words surrounded by curly braces ({{ }}) in the text.<\/p>\n In the first paragraph, the words With the Document Generation API, we can send this Word document along with data for those values, and get a PDF generated with ‘real’ values replacing the tokens.<\/p>\n Now our sample will actually address the content it’s sampling, giving details about the document’s title, author, and number of pages.<\/p>\n As an aside, this is one of the simplest<\/em> things you can do with the Document Generation API. Along with simple token replacements, you can have dynamic lists, tables, conditional content, and even dynamic images.<\/p>\n None of that is required for this particular demo, but keep in mind we\u2019re barely scratching the surface here.<\/p>\n Your next question may be \u2014 how do we get<\/em> the title, author, and number of pages of a PDF? We can make use of the PDF Properties<\/a> API which, as you can probably guess, will return the properties of a PDF document.<\/p>\n Here\u2019s an example of the output returned from a PDF:<\/p>\n Note that there is an optional argument, Looking at the sample above, we can see our three values (Author, Title, page_count) are there, so let\u2019s look at how we can bring this all together.<\/p>\n Let\u2019s now turn to the updated workflow that will process our PDFs. If you read the previous post<\/a> (and I highly encourage you to do so), you\u2019ll remember there were two scripts.<\/p>\n The first one simply figured out what PDFs needed to be processed. It did this by looking at an input directory and seeing which files did not<\/em> exist in a corresponding output folder.<\/p>\n In this version, the code in this file has changed in one small way. Instead of specifying a file for the PDF to prepend to our samples, we instead point to the Word doc:<\/p>\n As that\u2019s the only real change, so let\u2019s get right into the new PDF processing script. We\u2019ll focus on the changes from the previous version.<\/p>\n First, let\u2019s look at the main entry point, From the top, we begin by getting our access token. We use the credentials generated by Adobe\u2019s developer console and exchange them for the token.<\/p>\n Next, we upload the PDF that we\u2019ll be creating a sample from and store it in the Now we need to generate our dynamic PDF that will be prepended. First, the Word doc is uploaded and the result is stored as We need our data for the token. To accomplish that, we use a new function, Here’s that call:<\/p>\n When this job is done, we then need to copy out the value we care about: author, title, and page count.<\/p>\n Note that in our testing, author and title weren\u2019t always available, hence the use of the Elvis operator to handle those cases. The end result is a new, simpler object named You can see this passed to our next new function, And that\u2019s it! The rest of the main function simply uses the Combine PDF<\/a> functionality that we used in the last post.<\/p>\n Remember, this API not only lets you combine multiple PDFs but also lets you specify a range of pages to combine. We use this to combine our \u2018prepend\u2019 PDF and a slice of the main PDF.<\/p>\n Here\u2019s an example of what that first page would look like:<\/p>\n As an aside, in our use of Document Generation, all of the data came from the result of the PDF Properties API.<\/p>\n In case it wasn\u2019t obvious, we can use any<\/em> data. So for example, I could have included a token for the URL showing where someone might purchase the full book.<\/p>\n We would do that by adding the token to the Word document, and in our code, adding another key and value to the data passed to the Document Generation API.<\/p>\n If you want the complete source of this version, check out the repo at https:\/\/github.com\/cfjedimaster\/document-services-demos\/tree\/main\/article_support\/book_demo<\/a>. This version uses <\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n![\"\"](\"https:\/\/miro.medium.com\/v2\/resize:fit:640\/format:webp\/1*SK6vD9KbTo8IhAIEBpfM6w.png)
![\"Screenshot](\"https:\/\/miro.medium.com\/v2\/resize:fit:640\/format:webp\/1*J9tCzohX2P1kFeZaHXw8Sg.png)
title<\/code>, author<\/code>, and pageCount<\/code> are all surrounded by curly braces and represent tokens.<\/p>\npageLevel<\/code>, that returns even more information about page content. Another thing to note is that the SDKs return properties in a slightly different format. It’s the same data, just with different labels essentially.<\/p>\nmakeSample<\/code>, which is called by the previous script:<\/p>\nasset<\/code> variable.<\/p>\nprependAsset<\/code>.<\/p>\nmakePropertiesJob<\/code>, which wraps a REST API call to the PDF Properties endpoint.<\/p>\ndocumentInfo<\/code>, that contains the information we want to use in our generated PDF.<\/p>\nmakeDocumentGenerationJob<\/code>. Not surprisingly, this looks very similar to the last function, just with slightly different attributes and a new endpoint:<\/p>\n![\"PDF](\"https:\/\/miro.medium.com\/v2\/resize:fit:640\/format:webp\/1*RB8z26rsQ4bFtB9v4OkUpw.png)
makeSamplesv2.js<\/code> and pdfProcessorv2.js<\/code>. Be sure to sign up for your own credentials<\/a> and let us know what you think!<\/p>\n<\/div>\n