Making a PDF grayscale with ghostscript

A request from a friend made me face the problem of converting a color [[Portable Document Format|PDF]] into a [[grayscale]] one. Searching the web provided some ways of doing so with [[Adobe Acrobat]], via some obscure menu item somewhere.

However, the very same operation could be undertaken with free tools, such as [[ghostscript]]. I found a way to do it in the YANUB blog, and I will copy-paste it here, with a small modification.

Assuming we have a file called color.pdf, and we want to convert it into grayscale.pdf, we could run the following command (all in a single line, and omitting the “\” line continuation marks):

% gs -sOutputFile=grayscale.pdf -sDEVICE=pdfwrite \
-sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray \
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH color.pdf

I prefer the above to YANUB’s version below (in red what he lacks, in blue what I lack), because a shell operation is substituted by some option(s) of the command we are running:

% gs -sOutputFile=grayscale.pdf -sDEVICE=pdfwrite \
-sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray \
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH color.pdf < /dev/null

A sample [[Perl]] script to alleviate the tedious writing above:

#!/usr/bin/perl -w
use strict;
my $infile = $ARGV[0];
my $outfile = $infile;
$outfile =~ s/\.pdf$//;
$outfile = $outfile.”_gray.pdf”;
system “gs -sOutputFile=$outfile -sDEVICE=pdfwrite -sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH $infile”

Assuming we call the Perl script “togray.pl”, and that we have a color file “input.pdf”, we could just issue the command:

% togray.pl input.pdf

and we would get a grayscale version of it, named “input_gray.pdf”.

Comments (27)

Orange contra simyo

Estoy en proceso de selección de una compañía que me dé acceso a internet móvil. Es decir, poder conectarme a internet a través de la red de telefonía móvil, usando para ello una tarjeta SIM como la de los móviles, y un módem habilitado para usarla.

He seguido (de lejos) la evolución de los precios y servicios ofertados por las compañías de telecomunicaciones españolas, y la verdad es que no podían calificarse más que de estafa, o quizá “robo” es una palabra mejor. Sin embargo creo que ahora mismo es el momento en que los precios empiezan a ser competitivos (aunque no los de todas las compañias). Movistar y Vodafone parecen ofrecer basuras de calibre considerable, pero hay dos productos que me han llamado la atención: Internet Everywhere de Orange, y Tu propio internet móvil de simyo.

Ambas compañías ofrecen un servicio similar, que se puede resumir en:

  • Tarifa plana
  • Velocidad 3.6 Mbps hasta 5 GB mensuales
  • Tras consumir 5 GB se puede seguir navegando a 128 kbps sin coste adicional
  • Módem USB Huawei E220, que he leído que está soportado bien por Linux

La diferencia entre ambas es básicamente el precio (siendo simyo bastante más barata). A continuación resumo puntos a favor y en contra para ambas, y animo al amable lector a que me dé su opinión sobre el tema, si a bien tuviera.

Orange

Pros

  • Tiene tiendas físicas donde acudir
  • Regala el módem

Contras

  • El precio es más caro (39 eur/mes + IVA).
  • Exige compromiso de permanencia de 18 meses
  • Siendo una de las tres compañías que forman el oligopolio de las operadoras móviles en España (con Vomistar y Robafone), contratarla supone apuntalar su dominio (y poder para abusar del cliente), y ahogar a la competencia minoritaria

simyo

Pros

  • Mucho más barato: 24.99 eur/mes + IVA).
  • El módem es libre (el de Orange creo que no).
  • Me gusta más su política de funcionamiento, la idea de “no frills”, y lo que conlleva.
  • Aunque respaldada por KPN, simyo es una compañía minoritaria en España. Por ello, contratar sus servicios activa una sana competencia en el mercado.

Contras

  • Sólo puede accederse a la compañía por internet.
  • El módem hay que comprarlo, por 99 eur + IVA.

Todo lo anterior podría resumirse simplistamente en que Orange te regala los 99 euros del módem, mientras que simyo te cobra 14 euros menos al mes. Si esto fuera cierto, en 7 meses uno habría amortizado el módem en simyo (y tengamos en cuenta que Orange pide 18 meses de permanencia, y simyo 0). En los 18 meses de permanencia de Orange uno habrá gastado 18×39 = 702 eur (más IVA), mientras que en simyo habrían sido 99+18×25 = 549 eur (más IVA). Esto supone un ahorro de 150 euros en año y medio.

Comments (2)

LWD – September

Ups! August passed, my holidays finished, second work week… and I haven’t written much lately. I will partially fix that by updating my Linux World Domination project (you can read this May 2008 post for an intro).

As usual D2D means “days to domination” (the expected time for Windows/Linux shares to cross, counting from Feb 3, 2008), and DD2D means difference (increase/decrease) in D2D, with respect to last report. CLP means “current Linux Percent”, as given by last logged data.

Project D2D DD2D CLP Confidence %
Einstein 310.2 +62.3 34.94 43.0
MalariaControl 621.2 -374.9 12.20 35.0
POEM never 9.76
QMC 2873.2 +356.5 7.88 7.2
Rosetta 24647.0 +20189.5 7.80 0.5
SETI 4668.7 +1666.2 7.83 4.3
Spinhenge 12226.0 3.01 0.8

Comments

MacOSX ate my pics

OK, so the 2GB [[Secure Digital card|SD]] card I use in my camera has its problems. Apparently, only 1GB of it are recognized by the OS (Linux) and/or the card readers I own. The problem seems to be common, as you can see by googling about it. More info, from the Wikipedia article for SD cards:

Devices that use SD cards identify the card by requesting a 128-bit identification string from the card. For standard-capacity SD cards, 12 of the bits are used to identify the number of memory clusters (ranging from 1 to 4096) and 3 of the bits are used to identify the number of blocks per cluster (which decode to 4, 8, 16, 32, 64, 128, 256 or 512 blocks per cluster).

In older 1.x implementations the standard capacity block was exactly 512 bytes. This gives 4096 x 512 x 512 = 1 gigabyte of storage memory. A later revision of the 1.x standard allowed a 4-bit field to indicate 1024 or 2048 bytes per block instead, yielding more than 1 gigabyte of memory storage. Devices designed before this change may incorrectly identify such cards. Usually by misidentify a card with lower capacity than is the case by assuming 512 bytes per block rather than 1024 or 2048.

For the new SDHC high capacity card (2.0) implementation, 22 bits of the identification string are used to indicate the memory size in increments of 512 KBytes. Currently 16 of the 22 bits are allowed to be used, giving a maximum size of 32 GB. All SDHC 4-GB and larger cards must be 2.0 implementations. Two bits that were previously reserved and fixed at 0 are now used for identifying the type of card, 0=standard, 1=HC, 2=reserved, 3=reserved. Non-HC devices are not programmed to read this code and therefore cannot correctly read the identification of the card.

All SDHC readers work with standard SD cards.[ref]

Many older devices will not accept the 2 or 4 GB size even though it is in the revised standard. The following statement is from the SD association specification:

“To make 2 GByte card, the Maximum Block Length (READ_BL_LEN=WRITE_BL_LEN) shall be set to 1024 bytes. However, the Block Length, set by CMD16, shall be up to 512 bytes to keep consistency with 512 bytes Maximum Block Length cards (Less than and equal 2 Gbyte cards[ref].”

I have had problems in the past with this issue, and could only retrieve the photos exceeding the “first GB” of the card with a tedious operation: copy some photos from the card to the internal memory of the camera (28MB), remove the card from camera, connect camera to computer, download the photos in the internal memory (and empty it), unplug and repeat. 1GB/28MB = boring as hell.

However yesterday I realized that I had a shinny MacBook with its MacOSX intact. I read somewhere that Windows would sometimes read 2GB cards that Linux couldn’t, by the simple method of happily ignoring the f*cked up file system in them. Maybe MacOSX could, too.

Well, it turns out it couldn’t. When I attached the card in the card reader (I didn’t try with the camera directly), MacOSX found the device and mounted it, giving me a nice icon in the Mac version of “My PC”. However, the directory the icon led to was empty. I thought “Tough luck, Mac reads nothing in the card”, unmounted it and unplug it. Then I placed it in the camera again, turned it on and… there was no photo in the darned thing! MacOSX had erased them!

There is still the (likely) possibility that I made some deep mistake, but the explanation for now seems that MacOSX ate my pics. Sad.

Comments (1)

LaTeX input in Inkscape 0.46

I use [[Inkscape]] to do many of the drawings for my articles and talks, and have come across an irritating problem: I could not include [[LaTeX]] formulas on it. I have googled a bit about it, and the first match already led me to a bug report, where a comment by Kees Cook gives a fix that I quote below:

% cd /usr/share/inkscape/extensions
% curl -s 'http://launchpadlibrarian.net/12978623/eqtexsvg.py.patch' | sudo patch -p0

The bug affects (and the patch fixes) Inkscape 0.46 on [[Ubuntu]] Hardy Heron and [[Debian]] Lenny (that I know of).

Comments (2)

LWD – July

After another boring month, I have little to write about, besides my LWD project data update. You can read this May 2008 post for an intro.

As usual D2D means “days to domination” (the expected time for Windows/Linux shares to cross, counting from Feb 3, 2008), and DD2D means difference (increase/decrease) in D2D, with respect to last report (around a month ago).

Project D2D DD2D Confidence %
Einstein 247.9 +62.8 30.4
MalariaControl 996.1 +166.2 15.7
POEM 478.5 8.6
QMC 2516.7 +555.0 5.9
Rosetta 4457.5 +3155.8 1.8
SETI 3002.5 -1194.0 4.9
Spinhenge never

Except for SETI@home, all the D2Ds have gone up, showing that maybe the predictions so far were too optimistic. On the bright side (for [[FLOSS]]), SETI is, by far, the project with most users, so its results are the most reliable.

Recall that confidence percents are below 10%, except in two cases, which means logged data extent is small, compared to prediction time. This periodic report, thus, will get more and more accurate as months pass by.

Comments

Making iSight camera work in Ubuntu

As I said in a previous post, I bought a [[MacBook]], and I am making all bits work correctly. Out-of-the-box support from Ubuntu (the only GNU/Linux I tried on the MacBook so far) is excellent, but some things (camera, WiFi…) need proprietary drivers, so some more tweaks are needed.

I have followed the instructions in the Ubuntu community site, as with the procedures detailed in the previous post.

Basically, it all boils down to:

Fetch the Apple drivers for the camera

As root (if, unlike me, you like sudo, then run the following as user, but prepended with sudo), mount the Mac OSX partition (you didn’t delete it, right?) and copy the relevant file somewhere else (the cp command should be all in one line):

# cd
# mkdir /mnt/macosx
# mount /dev/sda2 /mnt/macosx
# cp /mnt/macosx/System/Library/Extensions/
     IOUSBFamily.kext/Contents/PlugIns/AppleUSBVideoSupport.kext/
     Contents/MacOS/AppleUSBVideoSupport .
# umount /mnt/macosx

You might have noticed that the Mac OSX partition is not sda1, but sda2. Don’t ask me. It turns out like this after following my own installation instructions. Apple must have decided to install the OS in the second partition for some reason.

Install the required packages

We need a package called isight-firmware-tools. Unfortunately it is not present in the Hardy repos at the moment (it was in the Gutsy ones, I think). You can add a Launchpad repo, editing /etc/apt/sources.list to add:

deb http://ppa.launchpad.net/mactel-support/ubuntu hardy main
deb-src http://ppa.launchpad.net/mactel-support/ubuntu hardy main

Then, as root:

# aptitude update
# aptitude install isight-firmware-tools

You will be prompted for a path to the driver you copied before. You can press Enter without paying much attention, then execute (assuming you copied the driver to your root home):

# cd
# ift-extract -a ./AppleUSBVideoSupport

To activate the driver, restart [[HAL (software)|HAL]]:

# /etc/init.d/hal restart

Test it with [[Ekiga]]

As explained in the Ubuntu community site, you can run Ekiga as user (after installing the ekiga package). Choose V4L2 as video plugin, and Built-in iSight should appear among the Input device list. If it does, the process worked.

Comments (22)

LWD update

This is a (in principle, monthly) update to my “Linux World Domination” project. You can read the intro in this May 2008 post.

The data presented is different from the one in the aforementioned post:

  • Mac is dropped from it
  • Predictor@home is also dropped
  • Two projects have been added: POEM and Spinhenge
  • D2D means “days to domination”. The expected time for Windows/Linux shares to cross, counting from Feb 3, 2008.
  • DD2D means difference (increase/decrease) in D2D, with respect to last report (a month ago)
Project D2D DD2D Confidence %
Einstein 185.1 21.8
MalariaControl 829.9 -1.1 15.5
POEM never
QMC 1961.7 +122.7 6.1
Rosetta 1301.7 3.8
SETI 4196.5 -370.5 2.9
Spinhenge

Except for QMC@home, all the projects have reduced the D2D. Rosetta and Einstein were expected to never lead to LWD, and now they are.

See you next month!

Comments

Linux e-mail clients rant

I am really disappointed at the [[e-mail client|MUA]] offer I am finding for by Debian box. I have tried [[KMail]], [[Mozilla Thunderbird|Thunderbird]], [[Evolution (software)|Evolution]] and [[Claws Mail]], and all of them fail at some point. All four errors are different, and all of them almost total showstoppers.

Note: I access my e-mail through Gmail [[IMAP]]. I don’t really care if these MUAs are good at [[POP3]] or whatever. I want good IMAP.

KMail 1.9.9

The [[GUI]] is nice, has all features I want, everything OK… It’s just that browsing the remote folders is hopelessly slow. I can brush my teeth in the time it takes to delete a message, and I don’t want to go into what I can do in the time it takes to move a message from one folder to another one.

Apparently this could be fixed in KMail2, which will come with KDE4. The problem is that I want it fixed now.

Thunderbird 2.0.0.14

This one is also very good in general. Actually, its problem is not due to itself. Its probably due to some bad interaction with [[X.org]] or something: everything works fine, but starting up and subsequent rendering/deleting of the window itself is really slow. If I minimize and maximize it back, it takes ages to reappear. I have this problem with TB and Firefox (actually Icedove and Iceweasel in Debian), and with no other program.

Evolution 2.22

Again, almost everything is fine. Almost. The single problem is that if the “To” and/or “From” fields in the message list contain non-ASCII characters, they appear garbled. Nowhere else does this happen. Even other fields, such as “Subject” can contain accents or ñ with no problem, as can the text body.

This would be a cosmetic issue I could live with, but there are two problems I can not tolerate: I do not want these errors to appear in the messages I send when replying to garbled messages, and more importantly, I have sometimes had recipient lists containing non-ASCII characters mangled. I don’t want to click “Reply all” and end up sending the message to only 3 of the 10 recipients.

This problem will supposedly be fixed in version 2.23.

Claws-mail 3.4.0

Again and again, almost everthing is right. Now messages can contain non-ASCII chars anywhere, browsing folders is fast, manipulating/drawing/erasing the program window is fast… BUT, replying to a message, regardless of the settings one chooses, does not include the original message quoted. This seems a minor error. It isn’t.

The thing that bugs me most is that I can not understand how these problems happen with [[free software]] packages. If you take KMail, Evolution and Claws, each one has a single error that the other two have already fixed… Couldn’t they just copy each other? That is precisely the whole point of free software.

Couldn’t KMail browse/scan/manipulate the IMAP folders with the efficient method Evolution and/or Claws use?

Couldn’t Evolution display the message fields with the error-free method KMail and Claws use?

Couldn’t Claws quote the original message as anyone else in the Universe does?

If only the three errors where not spread among the three MUAs, there would be one that I could use!

Comments (14)

How much left for GNU/Linux World domination?

Remember Project BHS? It is an effort I am making to log the evolution of Windows/Linux/Mac/Other market share, via the respective contributions to [[BOINC]] projects.

I have taken a further (and very crude) step towards the estimation of when will the Beast from Redmond fall, by extrapolating the “Number of hosts vs. time” curves to the points of crossing. For that I have fitted the data so far to (very crude, I know) second order polynomials (with [[Xmgrace]]), and calculated the crossing points (with [[GNU Octave]]).

The results can be:

  1. Windows seems to go upwards and Linux/Mac downwards (will never cross)
  2. The crossing point is above 100% or below 0% market share: the extrapolation is unfit (will never cross)
  3. There is a crossing point and lies within 0-100% market share: that’s the World Domintion date!!

I will be posting data for different projects, along with a “confidence” percent. This value corresponds to the fraction of the total time required for Linux/Mac to overcome Windows (according to the present tendency) that is represented in the collected data. If 10-day data suggests that Linux will overcome Windows in 1000 days, then the result is not really very trustable. OTOH, 999-day data suggesting the same is compelling.

An important notice: expected times are not measured from “now”, but from the moment I started collecting data, on Feb 3, 2008 (3 months ago).

The following table illustrates the aforementioned data for some selected projects, with time in days and confidence percent in parenthesis.

Project Linux (%) Mac (%)
Rosetta never never
MalariaControl 831 (11.4) 1142 (8.3)
SETI 4579 (1.9) 3094 (2.8)
Einstein never never
QMC 1839 (4.64)
Predictor 1095 (1.03) never

As an example, the curve fits and corresponding crossing points are given in the following figure, for the case of SETI@Home. You can infer the limited trustability of the predictions from the tiny time extent of the data points used to extrapolate the curves. As time goes by, curves will be more and more trustable, so expect updates to this “project”.

seti_small

SETI@Home data (click to enlarge)

The software used to process the data is BHS, and can be found at my home page.

Comments (2)

« Previous Page« Previous entries « Previous Page · Next Page » Next entries »Next Page »