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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide