When going from draft to final you jump from editing small documents and image files to building up huge press-ready files. With most text documents this is not a issue but with images then these can quickly leap in size and your old desktop or laptop, which seemed quite fast for regular web based work, becomes unusable.
The hardest page to edit is the cover of a book. If you have commissioned an art work and have got it scanned at a print-shop then you’ll be the proud owner of a huge TIFF or PNG or similar scanned image of 600 or 1200 dpi so say 6000×4000 pixels or bigger. Equally, images from professional cameras will be a minimum of 12 Megapixels (4000×3000 pixels).
The edits you are doing are simple – cropping to get correct aspect ratio, removing rough edges from the scan, aligning the scan, removing artefacts or layering in other images, but operating on such large files then forget trying to do these kind of edits on your old laptop or desktops and forget including these size of files in image frames in Scribus. Unless your laptop is new with at least a dual core and 2 Gigabytes of memory then it will grind to a halt. We’re using GIMP 2.6 so it may be that other programs are more memory efficient and it may be that you think your file is small but memory use also grows with the undo history. If you are trying out ideas then having the ability to undo changes fast allows you to work better. So all programs need to be in real memory, not swapped out to disk.
So you can buy new laptops or upgrade laptop memory for everyone for this one short time they work on this book or you can try something else that is cheaper. This is what we did – we got a new single desktop-scale PC which we put in a good amount of memory and then anyone who wanted to edit large files used remote desktop to get into this new PC.
Nothing fancy: we used a regular desktop style CPU. You could buy an off-the-shelf PC (which would probably run Windows), or even cheaper you could make this yourself from retail parts and run a Linux distribution. Whatever parts you get you need a reasonable amount of memory, reasonable processor speed and lots of disk space.
You don’t need a fancy graphics card as fast graphics cards are only really useful for 3D games – the onboard graphics from the major providers (ATI/Nvidia) on new motherboards are perfectly fine for this kind of “server” use.
How much is a “reasonable” ?. Well this is a desktop class of machine so 4 Gigabytes works out as a reasonably good number to use if you are looking at 1 or two editors. On either Windows 7 or Ubuntu (desktop 10.10) this leaves around 3 Gigabytes for applications if the onboard graphics uses a few hundred megabytes. If you want to go above 4 Gigabytes then you need to either run Windows 64 bit or a GNU/Linux based 64 bit distribution.
What is a reasonable processor ? You will get very good value for money with the retail desktop processors from both Intel and AMD but for the moment the AMD processors offer the best value for money if you want to build your own. As you are intending this to be a multi-user machine then ideally you need a dual core processor. This means an Athlon II 2X or better though if you really want to try for the really low budget then the Sempron 140 processors can be unlocked on a suitable motherboard to give you two cores.
The type of processor and motherboard will drive your memory selection. You’ll find that old memory can usually be much more expensive than new memory for the larger memory sizes. If you are looking at say a 4 Gigabyte memory kit (2x2Gigabytes) then you need to look at DDR3 memory on a matching motherboard.
It wasn’t that long ago I loved to find old machines (“Trashware”) and carefully recover the machines from parts. This meant working with 10-40 gigabyte and similar sized PATA hard drives and PC133 SDRAM on Pentium III and Duron sized machines. This will prove counter-productive for this job in that new parts have many orders of increase in capacity over older equipment so much so that it is much more cost effective to buy new memory or disk drives than to try and work out how to fit a new operating system on a 10 Gigabyte partition. New DDR3 memory is a penny a megabyte for Gigabyte scales and new hard disks are nickels per Gigabyte. Certainly if you find old DVDROM drives (that cannot burn disks) then these are still useful but CDROM/CDRW drives are more or less junk with the use of USB sticks. Old MicroATX cases are still useful if you don’t mind no front-panel audio or USB ports and buying a new power supply unit. Overall playing with trashware is fun but it is not the right equipment for this kind of job – you need new parts not old parts.
For the Operating system then this depends if it is pre-built from a major supplier or if you made this. If it is pre-built then you’ve probably been given Windows 7 of some kind. If you got this made then the best value for money you have is to go with a mainsteam GNU/Linux distribution such as Ubuntu or Fedora. The problem with staying with a retail non-server edition of Windows is that it is not a multi-user operating system in that it won’t allow two simultaneous users to run a desktop from the machine. You have to buy a Windows server edition (which is what the Windows Server 2008 Foundation edition is targeted at – competing with out-of-the-box GNU/Linux for small businesses).
For our server we used the Ubuntu 10.10 desktop 64-bit edition. We downloaded the ISO from the Internet via bittorrent. This is free to do and you are allowed to do this. You can install Ubuntu on as many PCs as you like for free.
To allow multiple Windows desktops to use this server then the easiest way to do this is to install the FreeNX software on the Ubuntu machine and then install the NX Nomachine client on each Windows PC that intends to remotely access the new PC. We’re using NX Client for Windows 3.4.0-10.
Assuming you’ve added accounts onto the new Linux machine then on your Windows PC run the NX Client. The main problems you will have is a clash of the cygwin1.dll. If you have existing Cygwin based applications running then the NX Client may fail with “Cannot initialize the display service.” You may have to use the sysinternals process explorer and search for which application has cygwin1.dll loaded if closing existing Cygwin based applications fails because some (e.g. DeltaCopy rsync.exe) application has Windows explorer.exe loading its copy of the cygwin1.dll. Note that the cygwin1.dll that NX Client loads is located at a path such as C:\Documents and Settings\\.nx\plugin\Windows\bin rather than the installed location.
Remember that Unix is case sensitive so check your logon name is exactly as it is in Unix i.e. lower case usually, if you keep getting Authentication failed messages even though you are confident you are typing in the correct password.
Other than those initial teething problems you will now have a regular Linux desktop. From this you can install new applications, such as GIMP or Scribus-NG and then run them on this new machine.
Sharing data and text files from your Windows PC to the Unix machine is easy via the NX program. Go into the configuration of the NX client and under the Services tab enable the print and file sharing.
Using Grisbi for agreement accounting.
We have an agreement with each joint-venture project signatory and we need to “profit”-share according to the agreement terms e.g. a 70:30, 60:40 or 50:50 split of earnings after cost of production, shipping and other cost of sale expenses. Given this is for a Print-on-demand book with very little stock-in-hand then this Just-In-Time system is accounted for on a cash basis. The signatories may use either cash or accrual basis for their own accounting for what agreement revenues they receive as “profit” – that is independent of this agreement.
To track this for our Doctor Antonio book project we’ve decided to use Grisbi rather than spreadsheets or a more complex double-entry accounting such as GNU Cash or an online ERP system. Grisbi is a simple cross-platform single-entry accounting system that is Open Source. We are running version 0.8.6 built from source. It is file-based, single user (it locks the file) so this allows us to email this as a stand-alone file to the other party to the agreement.
We created 3 different cash accounts for the products, one for each of USD, EUR and GBP currencies that we are working (we do have both incomes (credits) and expenses (debits) in these three so it starts getting complex very fast).
We also created 6 other cash accounts for agreement payouts which we’ll explain later.
We created the “Categories” (what Grisbi calls the Chart of Accounts) according to what the agreement allows (which has no personal or routine office-like expenses).
Invoices or cash payments for items are debits from each product account according to the currency and have the Payee as “cash” or “createspace” or similar common destination.
Royalties or cash receipts are credits to each account according to the currency and have the Payee as “cash” or some specific common source e.g. “Amazon Royalty Payments”.
We do not put any customer data (i.e. personal data) in this file for data protection reasons.
At the end of the month each product cash account balance is split according to the agreement percentages. We track this payout process by doing a “transfer” (in Grisbi) from each of these three product cash accounts to one of the 6 Payment accounts that we have setup i.e. one of each of the three currencies for each of the agreement parties.
The agreement parties can now decide how they want to transfer monies between each party (to help reduce bank or Foreign Exchange charges) e.g. one party may keep the USD in exchange for the other party keeping a matching value in GBP or EUR so that we avoid paying bank charges and money transfer commissions, and each party can either leave the money in that payment account or cash it out.
To cash it out a debit is made against one special payee per currency per signatory which is for each agreement party to logically take the money out of the account in that currency.
Thus an agreement party can elect to only receive USD but hold it in the account until it hits a suitable large value to make it worthwhile based on bank charges, so we shuffle around the payouts as value matched transfers between the payout accounts (e.g. swap their GBP for our USD at a spot rate) and then at a suitable date charge a debit against that payout account to the special agreement payee in effect making money leave this set of accounts and giving it to the agreement party. They then account for this payment as they see fit in their own accounting system as a credit though note that deferring the payment on our agreement accounting system does not alter that once it is in the agreement payment account then the signatory has in effect had constructive receipt of this money from the point of view of their own tax returns for a particular tax year. Grisbi has a good reporting system that will allow a payee annual report to be run between any two dates and so allowing a report to be run for the differing tax and accounting years for the agreement signatories.
Managing trust with this: no accounting system will ever have any meaning if it can’t be trusted. By using Grisbi we can e-mail the Grisbi file to the other party. If either party desires they could compare the invoices for how much product with the sales returns for products to see that credits are being posted correctly. With no personal expenses allowed there is little opportunity for skimming into the agreement profit.
For simplicity sake one party agrees to manage the accounts for the agreement though potentially both parties could do this in isolation using the same input data and then compare the results per month. As the Publisher then Life Sign Press will be doing the accounts as per this documented process.
We have noticed a few minor bugs whilst testing Grisbi so we will be posting these onto the Grisbi bug tracker. The code seems to be mostly C and as we’ve had experience with debugging C for the GNOME Project Planner application it should be reasonably easy to advise the developers of the fixes.