Working with agencies, I have found they tend to deliver assets in all kinds of different ways. Some prefer Photoshop or Illustrator (or, to my horror, Indesign). Others buck the tranditional and go for Figma or Sketch. At the end of the day, sometimes I just need a clean view of what I’m working on regardless of the tools.
One long term build involved a completely static app, which meant a static background with all elements contained in a single JPG background image, with invisible “hot spot” links on top where applicable. For this particular type of work, I found the agency delivered the work with each page of the static app as a self-contained PDF. The original view and each modal view (along with any other UI changes based on user interaction) were contained to pages within the PDF.
Building this type of application manually would have been impossible, especially when the assets are not final and the agency will re-submit new artwork. I decided to automate the process.
Breaking PDFs into directories
Each PDF had it’s own unique name, which I could use for the directory name of each page of the app.
$ ls -a
app_page_001.pdf
app_page_002.pdf
app_page_003.pdf
...
So I decided that each PDF would be contained inside their own directories. Then, I could export out each page of the PDF to a JPG that could be applied to the background of the HTML file.
for f in ./*.pdf
do
# set just the basename as filename, no ./path
filename=$(basename -- "$f");
# strip file extension so we just have the name
file=${filename%.*};
#msg to bash
echo "working on $file";
#make a directory using the file var
mkdir $file;
#convert the PDF called $file into JPGs and put them into the $file/ dir
convert -monitor -density 150 -colorspace RGB -quality 75
-alpha remove
-verbose
-scene 1
-set filename:original %t ./${file}.pdf "${file}/%[filename:original]_%03d.jpg"
done
We loop through each file in the directory via for f in ./*pdf. Then, we get the filename of the PDF and store it inside $filename. Iterating on that, we remove the file extension and store it inside $file.
I then want to store each set of JPG images in their own directory, so I use mkdir $file; to make a directory with the filename in question.
Finally, I use the swiss army knife that is Imagemagick to convert each page of the current PDF and save them as JPGs to the newly created directory, adding an appended set of numbers counting iterating.
This leaves me with each PDF directory containing the following files.
$ cd app_page_001;
$ ls -a;
app_page_001_0000.jpg
app_page_001_0001.jpg
app_page_001_0002.jpg
app_page_001_0003.jpg
app_page_001_0004.jpg
...
In this case, I built a custom Gulp-powered static site generator, so I move all of the PDF directories into a /bg-import/ and run an import script. Because of the nature of this type of build, I know that certain PDF pages correspond with certain user actions (e.g, trigger a modal, open a menu). Therefore I mapped my bg-import script to detect certain filename endings, 0004 for example, and rename them to ‘app_page_001_menu_modal.jpg’. My CSS then picks this up and the menu can appear.
Why implement this?
Because of the unique nature of this build, and the long and iterative process the agency goes through to build and rebuild the art assets and PDf’s, the idea of replacing backgrounds, menus and other images by hand does not make sense. Having a build system that I can easily and quickly run on a new set of assets ensures quick and consistent turn around when new assets are delivered. Plus, I don’t have to do it by hand.
