Making an Illustrated Book
One of the things we plan to do different in the Geek Ranch (see What's New Down Here?) is build a lot of domes instead of conventional buildings. The reasoning behind this is that they are quicker to build, cost less and use mostly local materials and that which is not local (in particular, steel) is used in lower quantities than in conventional construction.
Before you ask, while we will have storage buildings and other parts of the facility build as domes, if you are thinking about a trip to the Geek Ranch for your getaway, yes your casita will also be a dome. It seems like geeks are the least likely to have a problem with something non-conventional.
This area is full of albañils (bricklayers) but I doubt any of them have seen a dome building much less built one. What they know how to do is pour a foundation, stack up bricks with mortar between them, build structural columns with rebar and concrete and throw a cement, fine sand and water mixture on the outside to form a smooth surface.
The specific domes we are looking at are called Ecoshell 1 by Monolithic. They are built by building a foundation, inflating a balloon the shape of the building, putting rebar over the balloon and throwing concrete on it. Thus, while the shape and the balloon part will be new, most of the bricklayer's skills will transfer.
Note that I didn't mention insulation. There isn't any. The Ecoshell 1 is designed for climates where you want protection from the outside (wind and rain, for example) but you don't need a big temperature difference between the environment and you. As I know of zero houses here with heat and close to zero up here in the mountains with air conditioning, there shouldn't be a problem.
The trick is how to explain all this to the bricklayers. Well, Monolithic has published a 33 page book on the process. Most of it is drawings—two per page—with between zero and two sentences of text. Most of the book is applicable to what we want but, it's in English and we need it is Spanish.
Our final version will have mostly new illustrations and Spanish text. But, the starting point is what Monolithic has done. The first step is to scan most of the drawings in the existing book and create a place to add text. While this initially sounded like a job for OpenOffice.org, its default mode of operation is to flow text. While not impossible, it is a bit harder to place two illustrations per page now and then go back later and add some indeterminate amounts of text.
First I got the scanning out of the way using kooka, one of the many programs available for this task. No magic—just a lot of page turning and button pushing.
The next step required a bit of thought. The more complicated solutions include:
- Use Scribus which would allow you to control the layout
- Just create pages in a graphics program such as The GIMP adding the bits of text as needed
The challenges include:
- The graphics vary in size
- I want a footer with the name of the document and page numbers
- While I will be placing the figures, someone else will be writing the Spanish text.
After thinking a bit I decided KWord was the right answer. While KWord creates the same open document format as OpenOffice.org Writer, it is inherently frame oriented. What this means is that to start this document all that is needed it to place the two drawings on each page in their own frames. The frames can be moved and resized as desired. Finally, I turn on footers and set them up to include the document name and page number.
Once I am done with creating the basic book full of illustrations, I can hand the word-less document to Gixia. While she is not a native Linux user, she is a native Spanish speaker. I think she has learned more Linux in the last year than I have Spanish. Wherever text is needed she can add a text frame and enter it. As each illustration and each block of text is in its own frame, they can be moved around as needed to optimize page layout.
Once we are done, we want to produce a PDF. While KWord doesn't directly do this, the CUPS printing system takes care of this for us. By changing the output device from our printer to a file and printing the document, we get the PDF we need.
When this round is finished we will go back and place our new images and adjust the text positions as needed. The images can be created with any of the many drawing programs or can be drawn on paper (remember that method?), and scanned into the document.
There wasn't a lot of Linux magic here but we did manage to solve the problem at hand. Having the choice of OpenOffice.org, Scribus, AbiWord and KWord meant we could choose the best tool for the job rather than having to force the job to fit the only tool we had.
|smbclient Security for Windows Printing and File Transfer||Mar 28, 2017|
|How to Calculate Flash Storage TCO||Mar 27, 2017|
|Non-Linux FOSS: Don't Drink the Apple Kool-Aid; Brew Your Own!||Mar 27, 2017|
|Three EU Industries That Need HPC Now||Mar 25, 2017|
|HOSTING Monitoring Insights||Mar 24, 2017|
|FinTech and SAP HANA||Mar 24, 2017|
- smbclient Security for Windows Printing and File Transfer
- Returning Values from Bash Functions
- How to Calculate Flash Storage TCO
- Non-Linux FOSS: Don't Drink the Apple Kool-Aid; Brew Your Own!
- Two Ways GDPR Will Change Your Data Storage Solution
- Preseeding Full Disk Encryption
- GRUB Boot from ISO
- Chemistry on the Desktop
- Hodge Podge
- HOSTING Monitoring Insights