Evince update attempt

[tjzeeman]

Looking for a decent comics reader (cbz/cbr), as well as one capable of reading tex or postscript, I wanted to update the evince application as provided elsewhere on this forum.

Based on the build instructions there I started out to try to build the latest release possible without having to update system libraries and also without the need to use any hacks in the build system.

After a lot of trial and error I have at least managed to get something to compile and run on the simulator. Unfortunately, no document opens due to an error saying the required backend component cannot be found.

I've tried to solve this last issue, but I'm a bit at a loss right now as to what is causing this. Is there anyone around here who could help me with this?

Here's what I managed to get going so far:

The required sources are:

• evince 2.24
• djvulibre 3.5.22
• gnome-doc-utils 0.18.0
• gnome-icon-theme 2.22.0
• icon-naming-util 0.8.90
• libglade 2.6.4
• shared-mime-info 0.70
• jpegsrc v7

I'm using the vmware image as posted elsewhere in this forum. I did update the SDK to include a newer version of the SDK and had to install a few more things to get the build process completed:

• intltool
• libjpeg62-dev

Build djvulibre:

• autoreconf
• ./configure --prefix=/media/mmcblk0p1/Programs_evince --host=arm-poky-linux-gnueabi --disable-desktopfiles --disable-djview
• make depend
• make
• make install

Build gnome-doc-utils:

• autoreconf
• ./configure --prefix=/media/mmcblk0p1/Programs/_evince --host=arm-poky-linux-gnueabi --disable-scrollkeeper --disable-nls --disable-dependency-tracker
• make
• make install

Build icon-naming-util (dependency for gnome-icon-theme):

• ./configure --prefix=/media/mmcblk0p1/Programs/_evince --host=arm-poky-linux-gnueabi
• make
• make install

Build gnome-icon-theme:

• autoreconf
• ./configure --prefix=/media/mmcblk0p1/Programs/_evince --host=arm-poky-linux-gnueabi
• make
• make install

Build libglade:

• export LDFLAGS='-L/usr/local/poky/eabi-glibc/arm/arm-poky-linux-gnueabi/usr/lib -L/media/mmcblk0p1/Programs/_evince/lib'
• ./configure --prefix=/media/mmcblk0p1/Programs/_evince --host=arm-poky-linux-gnueabi --disable-gtktest --with-xml-catalog=/media/mmcblk0p1/Programs/_evince/etc/xml/catalog
• make
• make install

Build shared-mime-info

• ./configure --prefix=/media/mmcblk0p1/Programs/_evince --host=arm-poky-linux-gnueabi --disable-update-mimedb
• make
• make install

Build jpegsrc v7:

• ./configure --prefix=/media/mmcblk0p1/Programs/_evince --host=arm-poky-linux-gnueabi
• make
• make install

Build evince:

• export LDFLAGS='-L/usr/local/poky/eabi-glibc/arm/arm-poky-linux-gnueabi/usr/lib -L/media/mmcblk0p1/Programs/_evince/lib'
• export CFLAGS='-I/media/mmcblk0p1/Programs/_evince/include'
• ./configure --prefix=/media/mmcblk0p1/Programs/_evince --host=arm-poky-linux-gnueabi --disable-nautilus --disable-thumbnaler --without-libgnome --without-keyring --disable-dbus --disable-previewer --disable-pdf --disable-ps --disable-tests --disable-scrollkeeper --without-gtk-unix-print --disable-dvi --enable-djvu --enable-t1libs --enable-comics --enable-pixbufs
• make
• make install

I copied the entire /media/mmcblk0p1/Programs/_evince dir to the simulator, ran update-mime /media/mmcblk0p1/Programs/_evince/share/mime through the ssh connection (this has to be done now, instead of at build, because we're crosscompiling; hence the disable-mimeupdate earlier)

I've used the shell script from the published 0.22 package to set some environment variables (and edited it to match my stup), but so far without a positive result

If anyone notices anything in the above instructions going amiss, or if anyone is willing to help me figure out what is still missing from the above, I would be much obliged.

[luite]

Have you tried restarting the X server from the emulator ssh shell ( /etc/init.d/xserver-nodm restart ) ? You'll get more error output. You may also want to try to start evince from this shell.

By the way, what features do you need in a decent cbr/cbz reader? It seems to be a pretty simple file format, so I could probably make a new plugin for UDS in a few days, once I get the issues with the djvu plugin resolved. This will allow you to use exactly the same interface for reading comic files as for PDF files. It will also remember zoom settings and the last page.

[tjzeeman]

I had not tried to restart the x-server yet, but it got me the same result when I tried it just yet.

The console gives me the following error message:

root@qemuarm:/media/mmcblk0p1/Programs/_evince# bin/evince ../2001_compression_overview.djvu

** (evince.bin:2004): WARNING **: /media/mmcblk0p1/Programs/_evince/lib/evince/backends/libdjvudocument.so: undefined symbol: g_set_error_literal

** (evince.bin:2004): WARNING **: Cannot load backend 'djvudocument' since file '/media/mmcblk0p1/Programs/_evince/lib/evince/backends/libdjvudocument.so' cannot be read.

** (evince.bin:2004): WARNING **: /media/mmcblk0p1/Programs/_evince/lib/evince/backends/libdjvudocument.so: undefined symbol: g_set_error_literal

** (evince.bin:2004): WARNING **: Cannot load backend 'djvudocument' since file '/media/mmcblk0p1/Programs/_evince/lib/evince/backends/libdjvudocument.so' cannot be read.

And when I checked, the referenced file is there. Readable and executable for the world:

root@qemuarm:/media/mmcblk0p1/Programs/_evince# ls -l /media/mmcblk0p1/Programs/_evince/lib/evince/backends/libdjvudocument.so
-rwxr-xr-x 1 root root 54716 Aug 19 10:26 /media/mmcblk0p1/Programs/_evince/lib/evince/backends/libdjvudocument.so

My best guess is that I missed something with the environment variables (LD_LIBRARY_PATH or something like that) but after trying the usual suspects without success I'm a bit at a loss which one it could be.
Alternatively, it could be a linker issues, but given that it does know the right path to the requested file and can find several other dependencies, I have some doubts about this being the cause.

I've put a copy of my current attempt up here (WARNING: it's >20MB and doesn't work yet!)


For a comic reader I would like cbz and cbr support for containers, jpeg, png and gif for image format. cb7 and cbt would be nice to haves, as would tiff, svg and bmp.
Remembering the last page read would be nice, but not a deal breaker. Image scaling only if it honours the length/width dimensions (i.e. an 100x100 px image scales to 1000x1000 not 900x1100 or somesuch because the screen isn't a square)

Given that evince provides most of that (and some other interesting formats) I thought I would try to get that ported instead of writing my own app. More so because I haven't touched C in many years and didn't think writing a UDS plugin would be as easy as you make it sound like it is

[luite]

I've put a copy of my current attempt up here (WARNING: it's >20MB and doesn't work yet!)

Unfortunately that page gives me a forbidden error.

For a comic reader I would like cbz and cbr support for containers, jpeg, png and gif for image format. cb7 and cbt would be nice to haves, as would tiff, svg and bmp.
Remembering the last page read would be nice, but not a deal breaker. Image scaling only if it honours the length/width dimensions (i.e. an 100x100 px image scales to 1000x1000 not 900x1100 or somesuch because the screen isn't a square)

Scaling in UDS preserves the aspect ratio of the images (unless the plugin really wants to do things differently, it's the plugin that does the actual scaling), so that shouldn't be a problem. The easiest way to set it up would be that the default setting is to crop the margins off the images (like pdf), the "fill screen" setting would resize the image to fill the screen, and the 100% setting would display the images without scaling. The display is only 4 bit grayscale, so the images may require dithering to look good.

[tjzeeman]

Originally Posted by luite

Unfortunately that page gives me a forbidden error.

Oops. Fixed now.

[Kolenka]

Originally Posted by luite

The display is only 4 bit grayscale, so the images may require dithering to look good.

The only time I've seen undithered images look decent in the iRex was when they were already black and white, or already dithered (like say, someone's scan of a printed comic that was originally printed in B&W).

The good news is that a floyd-steinberg dither is actually rather easy to implement, since the description of the algorithms and sample code is floating around. It will actually be a bit easier to get working on the iRex since one of the bugs I'm facing on the desktop can only be seen on the desktop and not the iRex emulator.