Imprimir desde Android

Pues es muy difícil.
Se nota que está pensado para teléfonos: lo único oficial que he encontrado que soporta el sistema operativo es una API miserable para imprimir sólo texto.
Me recuerda los tiempos antiguos del MS-DOS: las aplicaciones gestionan directamente la impresión, normalmente respondiendo a las acciones "share" o "view". Así que, no habiendo API oficial, exigen partir de formatos conocidos: PDF, imágenes, o documentos de MS Office.

En lugar de arreglar la API para poder usar Bluetooth, o los USB, para conectarse directamente con tu impresora, las fuerzas mayores proponen matar moscas a cañonazos: enviar por HTTPS o correo los documentos a Internet y que llegen a la impresora que tienes al lado (Google Print Cloud, HP ePrint).

Hay otras soluciones (de pago):
- PrinterShare Puede usar Wifi o bluetooth si la impresora los soporta. Acepta DOC, DOCX, XLS, XLSX, PPT, PPTX, PDF, TXT. 

Otros enlaces interesantes:
PrintIntent API
CUPS
HPLIP Android PDF Viewer basado en MuPDF library

Velocidad de conversión de vídeo DV a DVD

Una sencilla comparativa de velocidad: partir de un fichero de vídeo DV, convertirlo a DVD PAL, y anotar los fotogramas por segundo que nos reporta ffmpeg.

ffmpeg -threads 2 -i a.dv -target pal-dvd -y a.vob

Para exprimir nuestro procesador al máximo, hay que compilar ffmpeg con las optimizaciones de nuestra arquitectura (usar --cpu= en configure), y hay que ejecutarlo con tantas "threads" como núcleos tengamos.

Tengo bastante variedad de CPUs a mi alcance, e iré completando esta tabla:

Fotogramas por segundo

CPU	GHz	cache K	--cpu=	-threads 1	-threads 2	-threads 3	-threads 4
Pentium-M	1.40	1024	pentium-m	38	-	-	-
Amd Neo K125	1.70	1024	amdfam10	42	42	-	-
Intel D830	3.00	2048	prescott	41	65	-	-
Intel E6400	2.13	2048	core2	85	119	-	-
E2-1800	1.70	1024	amdfam10	100	116	-	-
E2-1800	1.70	1024	amdfam10 64b	109	122	-	-
Intel E5200	2.50	2048	core2	89	129	-	-
Intel E5200	2.50	2048	core2 64b	109	138	-	-
Intel Q8300	2.50	4096	core2	103	133	158	132
Intel Z3775	1.46	2048	core2	110	134	152	159
Intel i7 640LM	2.13	4096	core2	86	118	142	160
Intel i3 3217U	1.80	3072	core2 64b	165	196	222	226
Intel i7 640LM	2.13	4096	corei7	199	245	281	290
Intel i7 640LM	2.13	4096	corei7 64b	216	267	298	310
i5-3450	3.10	6144	corei7	200	275	327	351
i5-3450	3.10	6144	corei7 64b	215	299	364	389
Intel i7 3630QM	2.40	6144	corei7 64b	217	311	394	413
Intel i5 8300H	2.30	8192	corei7 64b	518	883	1118	1098

Sorprenden los resultados de mi humilde Pentium-M. La posible explicación es que está corriendo sobre Ubuntu, y este test debe estar limitado por el ancho de banda del disco (los demás procesadores corren sobre Cygwin).

También es curioso que el Q8300 y el 8300H funcionen mejor con 3 threads que con 4. Posible caso de cache trashing.

Recortar y rellenar con FFMpeg

Vamos a usar los filtros crop y pad.

Para recortar a una imagen 8 píxeles por la izquierda, y 8 por la derecha:

ffmpeg.exe -i input.png -vf 'crop=in_w-16' output.png


Para rellenar con verde (R=69,G=94,B=18) 4 píxeles por la izquierda, y 4 por la derecha, si la imagen tiene 142 de ancho:

ffmpeg -i input.png -vf 'pad=150:0:8:0:699418' output.png

El filtro crop permite referenciar variables que representan el ancho/alto de la imagen. El filtro crop todavía no admite variables.

Crear imágenes monocromas con FFMpeg

Al pensar en FFmpeg como el mejor conversor de multimedia, nos solemos olvidar de que, aparte de vídeo y audio, también maneja imágenes.

En los sistemas Unix tenemos /dev/zero que es una fuente de ceros. Sólo tenemos que darle un tamaño, y una profundidad de bits para tener una imagen de color negro:

# Black image bgra PNG
ffmpeg -vframes 1 -s 64x32 -pix_fmt rgb32 -f rawvideo -i /dev/zero -pix_fmt rgb32 black64x32.png
# Black image rgb PNG
ffmpeg -vframes 1 -s 64x32 -pix_fmt rgb24 -f rawvideo -i /dev/zero -pix_fmt rgb24 black64x32.png

Si queremos otros colores, la cosa se complica: hay que usar filtros (lo cual implica un ffmpeg muy reciente). Los pasos son leer cualquier imagen de partida, superponer el generador de colores, y escalar al tamaño deseado:

# Gray image 50% transparent
ffmpeg -i black64x32.png -vf 'color=gray@.5:64x32:25 [over]; [in][over] overlay [out]' -vf scale=640:200:rgba -pix_fmt rgb32 gray640x200.png
# Gray image
ffmpeg -i black64x32.png -vf 'color=gray:64x32:25 [over]; [in][over] overlay [out]' -vf scale=640:200:rgb24 -pix_fmt rgb24 gray640x200.png

Recordad que, de todos los formatos de píxels que muestra ffmpeg -pix_fmts, sólo rgb32 y yuva420p permiten transparencia.

Compilar frei0r para Windows desde Cygwin

Vamos a compilar "fuera del árbol de código". Así podemos tener un directorio para cada compilación (uno para Cygwin, otro para MinGW32, otro para MinGW64)
mkdir frei0r-mingw32; cd frei0r-mingw32

Queremos compilación cruzada (de Cygwin a MingGW32), así que hay que especificar a CMake el compilador que queremos, dónde están los includes/libs de MinGW32, y dónde queremos instalar los binarios resultantes. El último parámetro es dónde está nuestro código fuente.

Creamos los "makefiles"
CFLAGS=-march=core2 cmake \
-D CMAKE_HOST_SYSTEM_NAME=Unix \
-D CMAKE_SYSTEM_NAME=Windows \
-D CMAKE_C_COMPILER=/usr/bin/i686-w64-mingw32-gcc.exe \
-D CMAKE_CXX_COMPILER=/usr/bin/i686-w64-mingw32-g++.exe \
-D CMAKE_FIND_ROOT_PATH=/usr/i686-w64-mingw32/sys-root/mingw/ \
-D CMAKE_INSTALL_PREFIX=/usr/i686-w64-mingw32/sys-root/mingw/ \
../frei0r-plugins-1.2/

Compilamos
make

Dejamos los módulos mondos y lirondos
/usr/bin/i686-w64-mingw32-strip src/*/*/*.dll

Instalamos
make install

Copiamos el include
cp -p ../frei0r-plugins-1.2/include/frei0r.h /usr/i686-w64-mingw32/sys-root/mingw/include

Comprimir PNG: pngnq y pngcrush

Las fotos se suelen guardar en JPEG porque ocupan menos que en PNG. Pero si queremos transparencia, hay que usar PNG.

Podemos usar un requantizador, pngnq, que pase de ARGB de 32 bits por píxel a un formato de paleta de 256 colores, con 8 bits por píxel.

Y después intentar buscar cuál de los variados algoritmos de zlib compactan mejor el PNG, con pngcrush.

Todo junto queda:
pngnq -n 256 imagen.png && pngcrush -brute imagen-nq8.png imagen_final.png

El soporte para la Intel 855GM va a peor en Ubuntu

Mi portátil empezó su singladura en Ubuntu en 8.04. Todo se instaló sin problemas.
La actualización a 8.10 transcurrió sin novedad. Tras modernizarme a 9.10, la aceleración de vídeo dejó de funcionar.

Acabo de actualizar a 10.04, y el soporte para mi tarjeta gráfica ha ido todavía, a peor: ni siquiera arranca.

Sí, hay ñapas para sobrevivir a ambos fallos, pero la gente instala Ubuntu por su facilidad de uso, es muy  raro que se lean las "Release Notes" (yo, desde luego, las leo sólo cuando todo falla).

Está claro que la prioridad de los programadores de Intel es sabotear tarjetas antiguas.

Compilar frei0r

 frei0r es un conjunto de filtros de vídeo. Efectos visuales y tal.

Para compilarlo en Cygwin, necesitaremos los paquetes gcc4-core, gcc4-g++, cmake.

Nos bajamos el código fuente, y lo desempaquetamos:
wget http://www.piksel.no/frei0r/frei0r-plugins-1.2.tar.gz
tar xvf frei0r-plugins-1.2.tar.gz

Se puede construir usando GNU autotools ( ./configure && make ) or CMake ( cmake . && make ).

Usamos CMake. El primer problema es que la versión del paquete cmake de Cygwin es 2.6, así que cambio la primera línea de CMakeLists.txt a esto:
cmake_minimum_required (VERSION 2.6)

Construímos los "makefiles":
CFLAGS=-march=core2 cmake .

Y a compilar. Como tengo un Core2, pues lo aprovechamos:
make -j 2

Para instalarlo:
make install

Y, como se han olvidado, también:
cp -p include/frei0r.h /usr/local/include/

Desde el 24-sep-2010, (SVN r25165), ffmpeg permite usar filtros de frei0r

Para construir ffmpeg con soporte para frei0r:
./configure --enable-frei0r

Antes de usar los filtros, conviene avisar dónde están:
FREI0R_PATH=/usr/local/lib/frei0r-1

Ejemplo de uso de un filtro:
./ffmpeg -i in.avi -vf "frei0r=water.dll:3.0:y:y:y:y:y:y" -y out.avi

Compilar para Windows desde Cygwin (IV)

Ya están disponibles en Cygwin los paquetes para compilación cruzada preparados por el projecto MinGW-w64, que generan código para Windows de 32 y de 64 bits.

Si queremos compilar ffmpeg para Windows de 32 bits, nos bajamos los paquetes:
mingw64-i686-binutils, mingw64-i686-gcc-core, mingw64-i686-headers, mingw64-i686-pthreads, mingw64-i686-runtime

La invocación de configure queda así:
./configure --enable-memalign-hack --arch=x86 --target-os=mingw32 --enable-cross-compile --cross-prefix=i686-w64-mingw32- --disable-shared --enable-static --disable-dxva2


Si queremos compilar ffmpeg para Windows de 64 bits, nos bajamos los paquetes:
mingw64-x86_64-binutils, mingw64-x86_64-gcc-core, mingw64-x86_64-headers, mingw64-x86_64-pthreads, mingw64-x86_64-runtime

La invocación de configure es ahora:
./configure --arch=x86_64 --target-os=mingw32 --enable-cross-compile --cross-prefix=x86_64-w64-mingw32- --disable-shared --enable-static --disable-dxva2

Lo de --disable-dxva2 es porque no uso la aceleración DXVA2 al decodificar h264.
DXVA 2.0 necesita Vista como mínimo (-D_WIN32_WINNT=0x0600), y activar las macros para que C maneje los objetos que normalmente se acceden desde C++ (-DCOBJMACROS), así que, si la queréis, usad --extra-cflags='-DCOBJMACROS -D_WIN32_WINNT=0x0600'.

Ojo con el punto y la coma

Los anglosajones usan el punto para separar decimales. Los españoles usamos la coma.
De vez en cuando, hay algún programa (suelen ser los que importan datos en CSV) que pide ir al Panel de Control y cambiar el separador de decimales de coma a punto.

Ojo, porque este acto, en apariencia inocente, confunde de mala manera a algunos programas escritos chapuceramente. Por ejemplo, al Administrador de Tareas de Vista:

A la izquierda el separador de decimales es coma, y a la derecha es punto

O igual es que así los programas consumen mil veces menos memoria ...

Mostrar entradas recientes

Encontré un JavaScript que muestra las entradas más recientes de una categoría:


<script type="text/javascript">
function recentpostslist(json) {
 document.write('<ul>');
 for (var i = 0; i < json.feed.entry.length; i++)
 {
    for (var j = 0; j < json.feed.entry[i].link.length; j++) {
      if (json.feed.entry[i].link[j].rel == 'alternate') {
        break;
      }
    }
var entryUrl = "'" + json.feed.entry[i].link[j].href + "'";//bs
var entryTitle = json.feed.entry[i].title.$t;
var item = "<li>" + "<a href="+ entryUrl + '" target="_blank">' + entryTitle + "</a> </li>";
 document.write(item);
 }
 document.write('</ul>');
 }
</script>
<script src="http://lineadecomandos.blogspot.com/feeds/posts/summary/-/awk?max-results=999&amp;alt=json-in-script&amp;callback=recentpostslist">
</script>


Este código se puede usar dentro de una entrada (decid al editor que muestre HTML literalmente). Por ejemplo, aquí listo mis entradas sobre awk:




También se puede poner en un gadget HTML/Javascript.

Google admite comandos

Google ha tenido a bien crear googleCL, un script en Phyton para acceder a la funcionalidad de Blogger, Picassa, Calendar, Docs, Youtube.

Lo he probado desde mi Ubuntu 9.10, creando la primera línea de esta entrada:
google blogger post --tags "GoogleCL, Phyton" --title "Google admite comandos" "Google ha tenido a bien crear un script en Phyton para acceder a la funcionalidad de Blogger, Picassa, Calendar, Docs, Youtube."

Tras pulsar enter, te pregunta el nombre de tu cuenta en Google, y te devuelve un URL para que lo valides desde tu navegador.

Cygwin es lento (I)

Pero mucho, mucho.

Lo más lento es ejecutar los configure, que en Unix tardan segundos y en Cygwin minutos.
La razón es la lentísima creación de processos (spawing) en Cygwin.

Por ejemplo, el configure de FFmpeg.

Primero creamos un entorno óptimo, eliminando los directorios innecesarios de PATH:
export TMPDIR=/tmp
export TEMP=/tmp
export TMP=/tmp
export PATH=/usr/local/bin:/usr/bin:/bin

Esta es mi invocación habitual de configure:
time ksh ./configure --disable-shared --enable-static --enable-gpl --enable-avfilter --enable-avfilter-lavf --enable-pthreads --enable-avisynth --enable-bzlib --enable-libmp3lame --enable-libx264 --cc=gcc443 --cpu=core2 --enable-zlib --extra-cflags=-DX_DISPLAY_MISSING

real 2m24.004s
user 0m15.938s
sys 0m41.157s


La cuenta no sale: 2m24s -15s -42s = 86 segundos sin currar.

Primer intento de mejorarlo: evitar las reubicaciones de las DLLs.
Para ello, invocamos la línea de comandos de Windows (cmd.exe), vamos al directorio de los binarios de Cygwin, invocamos dash, y lanzamos rebaseall:
cd c:\cygwin\bin
dash
./rebaseall

Volvemos a invocar el configure de FFmpeg y nos da:

real 2m20.758s
user 0m15.713s
sys 0m42.660s

Bueno, hemos ganado 4 segundos.

Mi tele lee multimedia (II)

Para las pruebas, necesito material HD, por ejemplo Big Buck Bunny

Nos lo traemos:
wget http://mirror.bigbuckbunny.de/peach/bigbuckbunny_movies/big_buck_bunny_1080p_h264.mov bbb.mov

FFmpeg nos dice:

ffmpeg -i bbb.mov

Atentos a que partimos de sonido envolvente: los 6 canales de audio.

Convertiremos un trocito, por ejemplo 3 segundos, que a 24 cuadros por segundo, son 72 cuadros.

Empezamos a probar conversiones.

a) Calidad HD.
Los codecs H.264 / AAC encajan con lo que la tele puede leer. El contenedor .mov es un dialecto de .mp4, así que basta con cambiar la extensión de fichero.

Si queremos coger un trocito:
ffmpeg -ss 13 -vframes 72 -i bbb.mov -vcodec copy -acodec copy bbb_9300.mp4

La tele muestra bbb_9300.mp4 correctamente.

Si los codecs no hubieran coincidido:
ffmpeg -ss 13 -vframes 72 -i bbb.mov -vcodec libx264 -fpre normal -crf 22 -acodec libfaac -ab 192k bbb_9300.mp4

b) Calidad DVD.
La tele es 16:9, y Big Buck Bunny también, así que mejor usar "-aspect 16:9". Dotaremos de 8000kb/s al vídeo (los DVDs comerciales suelen quedarse en 6000kb/s).

Preparamos las tres variantes de audio.

b1) MPEG layer 2 (sólo estéreo)
ffmpeg -ss 13 -vframes 72 -i bbb.mov -target pal-dvd -aspect 16:9 -b 8000k -ac 2 -acodec mp2 bbb_8000_mp2.vob

b2) LPCM, forzando audio estéreo.
ffmpeg -ss 13 -vframes 72 -i bbb.mov -target pal-dvd -aspect 16:9 -b 8000k -ac 2 -acodec pcm_s16be bbb_8000_lpcm.vob

b3) AC3, preservando los 6 canales.
ffmpeg -ss 13 -vframes 72 -i bbb.mov -target pal-dvd -aspect 16:9 -b 8000k -acodec pcm_s16be bbb_8000_lpcm.vob

La tele los muestra correctamente.

c) Calidad AVI.
Mi tele no necesita la marca "-vtag DX50" que algunos reproductores requieren en Windows.

Preparamos las tres variantes de audio.

c1) MPEG layer 2 (sólo estéreo)
ffmpeg -ss 13 -vframes 72 -i bbb.mov -vcodec mpeg4 -s 720x576 -aspect 16:9 -b 8000k -ac 2 -acodec mp2 -ab 192k bbb_8000_mp2.avi

c2) MPEG layer 3 (sólo estéreo)
ffmpeg -ss 13 -vframes 72 -i bbb.mov -vcodec mpeg4 -s 720x576 -aspect 16:9 -b 8000k -ac 2 -acodec libmp3lame -ab 128k bbb_8000_mp3.avi

c3) AC3, preservando los 6 canales.
ffmpeg -ss 13 -vframes 72 -i bbb.mov -vcodec mpeg4 -s 720x576 -aspect 16:9 -b 8000k -acodec ac3 -ab 384k bbb_8000_ac3.avi

La tele los muestra correctamente.


Conclusión:
La tele da bastante de sí: muy pocos reproductores de salón soportan 8000kb/s en MPEG4. Y menos aún, H.264/AAC.


Líneas de investigación:
El fichero de partida tiene 23.97 fps (FILM). Hay que ver si la tele soporta 29.97fps (NTSC) y 25fps (PAL).
Lo más probable es que sí, pero he notado que el movimiento con 23.97fps es a saltitos, no es suave.

Hay que probar con distintos tamaños. En AVI he visto que 720x432, 704x298, 640x272, 720x400, 640x480 van bien.

Hay que probar si traga tal cual el .mp4 de YouTube HD (1280x720, 640×360).

El fabricante dice que la tele lee particiones FAT16, FAT32 y NTFS. Leer NTFS es inusual, así que hay que refrendrarlo con una pruebecilla.

Mi tele lee multimedia

Como indica su fabricante, mi tele lee estos formatos:

Extensión	Vídeo	Tamaño	Kilobits/s	Audio
.avi	MPEG-4 SP MPEG-4 ASP	352×288 720×576	384 8000	MPEG layer 2/3 AC3
.mpg .mpeg .vob	MPEG-1 MPEG-2	352×288 720×576	1500 9800	MPEG layer 2 LPCM AC3
.mp4	H.264, L2-CIF H.264, L4-HD	352×288 1920×1080	2000 20000	AAC-LC AAC-LC

Los tamaños y tasas de bits los he mirado en MPEG-4, y H.264

Me falta hacer una chuleta con las opciones que hay que pasar a FFmpeg para generar estos formatos.

Y probarlos, claro.

RCX

Tras profunda exploración del trastero, he re-encontrado mi Robotics Invention System 1.5.
Dentro de esta caja, está el RCX, que es un "ladrillo" amarillo que aloja un microcontrolador con sensores y salidas.

Fue mi regalo de cumpleaños del 2000 o 2001 y me he llevado la desagradable sorpresa de que Lego quitó todas la referencias de su web oficial allá por 2008.

Así que he tenido que ir escarbando:

http://brickos.sourceforge.net/index.html

http://www.mapageweb.umontreal.ca/cousined/lego/

http://www.crynwr.com/lego-robotics/

El RCX se comunica por infrarrojos, pero se habla con los PC a través de una cajita intermedia unida por el puerto serie. El puerto infrarrojo de muchos portátiles no vale, porque Lego usa un protocolo rarito.

Los que tengan un Palm, sí que pueden comunicarse por infrarrojos con el RCX.

Compilar para Windows desde Ubuntu (II)

En vez de traernos los ejecutables necesarios para la compilación cruzada, podemos traernos los fuentes, y compilarlos.
La ventaja es que podemos tener la última versión, y compilarlos para exactamente la CPU que tengamos (en mi caso, CFLAGS=-march=pentium-m).

Adaptado de la receta de Ramiro.

Nos instalamos algunas dependencias de gcc:
sudo apt-get install flex bison

Algunas dependencias de FFmpeg.
sudo apt-get install texinfo yasm subversion

Y un entorno para poder testear los ejecutables de Windows, sin salir de Linux:
sudo apt-get install wine

Nos preparamos un directorio para bajarnos y compilar el código fuente:
cd "$HOME"
mkdir src
export BASE_PATH="$HOME/src"

Traemos estos ficheros, y los dejamos en el directorio $BASE_PATH:
binutils-2.20.tar.bz2
gcc-core-4.2.4.tar.bz2
mingwrt-3.16-mingw32-dev.tar.gz (from http://sourceforge.net/projects/mingw/files/ under "MinGW Runtime")
w32api-3.13-mingw32-dev.tar.gz (from same site as above under "MinGW API for MS-Windows")
zlib-1.2.3.tar.gz (from http://prdownloads.sourceforge.net/libpng/ )
bzip2-1.0.5.tar.gz (from http://bzip.org/downloads.html )

El compilador cruzado lo instalamos en /usr. Pondrá su cosillas en /usr/bin/i686-mingw32*, sin machacar las del compilador nativo de Ubuntu (que son /usr/bin/i486-linux-gnu*).

Importante:
sudo ln -s /usr/i686-mingw32 /mingw

binutils:
cd "$BASE_PATH"
tar xfvj binutils-2.20.tar.bz2
cd binutils-2.20
mkdir build
cd build
../configure --target=i686-mingw32 --disable-werror --disable-nls --prefix=/usr
make
sudo make install

"runtime" de MinGW:
cd "$BASE_PATH"
sudo tar zxfv mingwrt-3.16-mingw32-dev.tar.gz -C /mingw
sudo tar zxfv w32api-3.13-mingw32-dev.tar.gz -C /mingw

compilador de C:
cd "$BASE_PATH"
tar xfvj gcc-core-4.2.4.tar.bz2
cd gcc-4.2.4
mkdir build
cd build
CFLAGS=-march=pentium-m ../configure --target=i686-mingw32 --disable-nls --prefix=/usr
make
sudo make install

En los entornos GNU, la manera de indicar que queremos usar compilación cruzada, en vez de nativa, es a través de las variables de entorno:
RANLIB=i686-mingw32-ranlib AR=i686-mingw32-ar CC=i686-mingw32-gcc

Compilamos para MinGW algunas bibliotecas de funciones:

zlib:
cd $BASE_PATH
tar zxfv zlib-1.2.3.tar.gz
cd zlib-1.2.3
CFLAGS=-march=pentium-m RANLIB=i686-mingw32-ranlib AR="i686-mingw32-ar rc" CC=i686-mingw32-gcc ./configure --prefix=/mingw
make
sudo make install

bzip2:
cd "$BASE_PATH"
tar zxfv bzip2-1.0.5.tar.gz
cd bzip2-1.0.5
make libbz2.a CFLAGS=-march=pentium-m RANLIB=i686-mingw32-ranlib AR=i686-mingw32-ar CC=i686-mingw32-gcc
sudo cp bzlib.h /mingw/include/
sudo cp libbz2.a /mingw/lib/

Y con esto ya podemos compilar un FFmpeg para MinGW. Aquí la compilación cruzada se indica con --cross-prefix=i686-mingw32- --target-os=mingw32 y la CPU con --arch=pentium-m --cpu=pentium-m:
cd "$BASE_PATH"
mkdir ffmpeg
cd ffmpeg
svn co svn://svn.ffmpeg.org/ffmpeg/trunk svn
mkdir build-win32
cd build-win32
../svn/configure --enable-memalign-hack --cross-prefix=i686-mingw32- --target-os=mingw32 --arch=pentium-m --cpu=pentium-m

Y os preguntaréis, ¿por qué no compilar para MinGW desde MinGW?. Pues porque es más lento. Pero no un poco, sino algo exagerado: diez veces más lento.

Compilar para Windows desde Ubuntu (I)

Tres pasos para crear un entorno en Ubuntu que nos permita compilar para Windows.

Nos traemos el paquete básico para compilar:
sudo apt-get install build-essential

El compilador cruzado, binutils y el "runtime":
sudo apt-get install mingw32 mingw32-binutils mingw32-runtime

Y un entorno para poder testear los ejecutables que compilemos:
sudo apt-get install wine

Podemos intentar compilar FFmpeg:
configure --enable-memalign-hack --cross-prefix=i586-mingw32msvc- --target-os=mingw32 --arch=i686 --cpu=i686

Pero nos da este error:
ERROR: MinGW runtime version must be >= 3.15.

Es que en Ubuntu 9.04 las versiones de los paquetes de compilación cruzada a MinGW son algo antiguas:
dpkg -s mingw32 mingw32-binutils mingw32-runtime |fgrep Version
Version: 4.2.1.dfsg-1ubuntu1
Version: 2.18.50-20080109-1
Version: 3.13-1


FFmpeg tiene la costumbre de exigir la última versión de sus dependencias, con otros programas estos paquetes de Ubuntu nos podrían valer perfectamente.

Cacharricos

En verano, los campos y las bitácoras se agostan. Ya se sabe, las vacaciones es el periodo del año en que conviene no recalentar el cerebro.

Aún así, algo ha caído:

• Mi querido portátil, ha vuelto a la vida tras sustituirle el disco muerto de 40GB por otro de 160GB. El proceso requirió los correspondientos improrerios a la SGAE, al ver que se llevaba un 25% de la factura. En fin, Ramoncín tiene que ir pagando su hipoteca ...
• Me quise comprar un PCecico para el salón. Oferta agotada para cuando me acerqué a la tienda, así que me llevé lo más parecido. No tan mono (es semitorre) pero con 1TB de disco.

Como uno gusta de la diversidad, el portátil tiene su Ubuntu 9.04, y el otro tiene Vista (y un Wubi dentro que tengo que configurar).

Aligerar PDFs

Mensualmente me llega una revista digital en formato PDF.
La mitad de las páginas son anuncios, así que suelo recortarlos con pdftk

Por ejemplo, para dejar sólo las páginas 1, de la 14 a la 24, y de la 26 a la 36:

pdftk MMH20090601.pdf cat 1 14-24 26-36 output MMH20090601-mini.pdf

Con lo cual se queda en la mitad de tamaño:
ls -s1 MMH20090601*
26236 MMH20090601-mini.pdf
48332 MMH20090601.pdf

A los alérgicos a la línea de comando os tranquilizará saber que podéis usar PDFTK Builder