This article will be a little different from other Colecandoo pieces, and will go behind the scenes on a commissioned project to go through the client’s brief and how that brief was met. This article is presented with the client’s permission, and also at their request to show how this brief was met.
The Backstory
The client was preparing the history of the Cryptopunks story and images as a case-bound book.
A great explainer video about Cryptopunks journey and the “Free to Claim” book can be found here.
The Brief
My involvement with the project was to assemble the catalogue raisonné from a supplied database, linked images and formatted table.
The catalogue raisonné featured:
- 10,000 unique images;
- 10,000 text descriptions; and
- Each description contained a list of color squares used within the images, listed by the amount each color was used (from most to least used);
Each record would be displayed in a table row divided by six columns. Those columns contained:
- The ID number of the image;
- The filename of its graphic;
- Hex codes used within the graphic from most to least used;
- Type (e.g. Alien, Ape, Male, Female, Zombie);
- Attributes (i.e. keywords associated with the image); and
- Its imagehash
Each printed page was to contain 24 works, displayed in a table with two columns, twelve rows and one header row. This would require 417 pages to list the 10,000 works, and was half of the book’s 834 text page total.
Tackling the brief
First question was how to import this data into InDesign. A few ways could be used, namely:
- Data Merge using multiple records;
- Data Merge using into a table using Loic Aigon’s csv2table script;
- Import as XML;
- A catalogue plugin such as Cacidi extreme or Teacup Software’s Datalinker (just to name a few); or
- Import an unformatted version of the Excel file and apply formatting to it.
From the excel file, 4 of the 6 columns were type that required minimal formatting, so I’d opted to import an unformatted version of the Excel file and then apply appropriate formatting to that table. Upon reflection, Data Merge using multiple records would also work well too.
Divide into workable chunks
While it should be possible to create one InDesign file that was 417 pages long and containing 10,000 images, working with such a large file was going to become unwieldy fast, so it was decided to make an INDB book file, with 9 INDD files making up the book file – each INDD file containing 50pp or less.
Best practices are a must
Everything (and I mean everything) in each InDesign file had styles applied, whether it was:
- Table;
- Cell;
- Paragraph;
- Character;
- GREP
- Object
It was also important that styles were not overridden, otherwise inconsistencies would easily occur.
Bring the database to life
The database itself contained all the information needed. The database was split into 8 sets of 1200 records and one set of 400 records.
The client’s frame of the table was kept as a top layer, and the data was literally imported into a new table, populated throughout the document.
By itself, this act would populate AND format two out of the six columns with no further action, namely the ID and the Type. The first column also had a paragraph style property so that it would appear as text variables in the foot of the page – one variable showing the first number on the page, and one variable showing the last number on the page.
Pain point one – inserting line breaks into two of the columns
Within the attribute column, each attribute needed to be on its own line, but within the database the attributes were separated by a comma followed by a space. The attributes column would then be selected and a GREP search/replace would be run to replace commas followed by spaces with line breaks.
The contents of the imagehash column are currently all overset as the string of letters and numbers doesn’t soft-break by itself, so this column is now selected and another GREP search/replace is run to look for collections of 10 characters and insert line breaks between them.
Pain point two – importing the images
While the database contained the image name, that did not mean that it would instantly become a picture in the table cell. Instead, a free script created by Kasyan Servetsky called Place Inline Images and fit was used. This did require adjusting the name in the table cell to ensure that it had @ symbols before and after.
The images would then replace the image names with the images themselves as inline images.
To prevent the image from being cropped by the table frame, the inline images were then released from inline images to floating images in the same position using another indesign javascript.
Pain point three – making the colored squares and showing them in the correct order
The client had requested that instead of showing each hex code as plain text (e.g. #FFFFFF) that they were instead shown as a square that was coloured with their respective hex code.
Unlike the other text portions of this table, the hex codes were flooded into their own threaded textframes that had unusual properties that will be explained later on. Converting the hex codes into colored squares and removing the comma and space separating them required its own custom solution, so a javascript was written solely for this purpose. The script behaves like a find and replace, but with a twist – it will find all selected hex codes but replace them with a square symbol (from the wingdings font) that is colored with the hex code it was swapped out for.
Client had also requested that the hex squares be listed in the order of most used to least used, and that would read from top to bottom and then left to right. The script earlier changed the plain text hex codes into coloured squares, but their order was determined by the database creator who had prepared them reading left to right and then top to bottom.
So I’d mentioned earlier that these text frames had unusual properties – so rather than a script to reorder the colors, the text frames containing the squares were rotated 90 degrees, as well as flipping the frame to be wrong-reading so that the reading order was now as desired.
Pain point four – convert hex colors to CMYK equivalents
This was achieved using a custom javascript that would convert the hex value colors to appropriate CMYK values for print. The script also looked for the specific hex value #000000 and made it 100% Black.
Rinse and repeat
Once the client was satisfied with the results of one chapter, this procedure was repeated eight times to make the remaining chapters.
Once completed, the files were stitched together using an InDesign book file, packaged using the package tool and submitted to the client for use within their project.
Et Voila!
This is certainly a very rewarding project that allowed me to use my very particular set of skills (skills I have acquired over a very long career) and be a part of the book documenting the history of the Cryptopunks.