In my previous post, I estimated the main part of the process of preparing stuff artwork for the Corby Tribe remasters (reassembling the coloured art, DTP and web preparation) at 45 minutes per original. This is down from an hour per original two weeks ago, but it is still very long for what is very simple DTP and image processing work. What's making it take so long?
The earlier time per update of one hour was partly due to the problems I had using Scribus as described in a previous post: the built-in text editing functionality in Scribus caused me to spend a lot of time entering quote marks and apostrophes, which the software would then destroy in a wide range of interesting ways. I have since worked around this by editing the text in OpenOffice.org and importing the OpenOffice files into Scribus using the Acquire Text feature. This works a lot better, though there is one further complication: while Scribus, by default, prompts the user to ask whether the text formatting from the imported file should be used, unchecking the relevant boxes in the prompt makes no difference and the formatting from the file is used. This leads to the absurd situation that most of the DTP leg work for text formatting is done in OpenOffice, and the only thing that the DTP software adds is the ability to put the text in a box and separate it into two columns. If I had known, I'd just have done all the work in OpenOffice from the start.
In any case, this workaround works well enough and getting the text processed and adding the curly quotes I want now takes up very little time*) The other source of long production times is simple waste, especially to rework. The rework rate on this weekend's batch was about 150%, meaning that every file had to be redone at least once after I thought it was done with it. Some had to be redone three times. The cause of this rework is that I am very very bad at keeping track of the wide range of source items that go into the updates: numbered line art files in one folder, numbered color files in another, numbered text files in a third, resulting in numbered dtp files in a fourth, which all carry a differentnumber in their internal text (the update number relative to the very first ROCR comic whereas the files are numbered from the start of the storyline. It's easy even for a person with a mind for numbers to lose track; since I have a terrible mind for numbers, I end up with a high enough error rate to result in having to fix every file after DTP is technically complete.
So far, I have worked by saving each DTP file after completion and then Saving As with a new number and then importing the appropriate image master file and text file. This may seem like an easy and convenient way to work, and it does have the advantage that it is pretty much impossible to skip a number. But if I lose concentration just for a moment (make that when I lose concentration), I risk keeping the old image file or replacing the image file twice so it's a number ahead, or adding the wrong in-text update number. So it is probably worth the extra time to go back to the template for each update so that I start each new file with a clean slate. I have already decided to stop doing these large batches for a while because getting as far ahead as I want that way has turned out to be undoable, but when I do go back to the process, that's what I'll do.
In my day job, I've been translating some learning materials about Lean Manufacturing. In this approach, rework is one of the Seven Wastes to be avoided, and keeping track of the extra time and frustration involved has been instructive as to just how wasteful it can be. It strikes me that both the decision to spend time learning a DTP program when it would be easier just to use the page layout features in my word processor also fits into one category of waste (overprocessing - using a sledgehammer to put in a nail) as does the use of a visible number inside the update in imitation of the way Marten Toonder's old newspaper comics were added (also overprocessing, but by a more generalised definition of adding a feature that the readers aren't interested in. On the other hand, as a young reader I always loved gimmicks like that, so maybe).
*) Note: For years, I avoided curly quotes despite the fact that not using them is considered a serious sin in desktop publishing. I was doing work for display on the web and for a long time, display of curly quotes on web sites was unreliable because of character set issues. However, that seems to be mostly remedied now and as more blogging software provides for curly quotes, it was time to switch.
Confusingly, in my day job in localisation, I am instructed to make minimal use of any kind of quote marks, and only to use straight quotes in those situations where I do use quotes.