Font rendering on 16-bit display looks very ugly. I'll attach a screenshot that shows http://triplane-class.sourceforge.net/triplane-classic.pdf opened in both MuPDF 20090707 and xpdf 3.02-1.4+lenny1. I can reproduce this on both openmoko running Xorg with xserver-xorg-video-fbdev driver and on amd64 running "vnc4server -depth 16".
Created attachment 5686 [details] screenshot. triplane-classic.pdf on 16-bit display with mupdf and xpdf
Forgot to mention: mupdf prints ximage: mode 16/16 0000f800 000007e0 0000001f (11,5,0) lsb <swap> ximage: ARGB8888 to RGB565_BR ximage: XShmPutImage on openmoko.
That looks like an endianness issue to me. I don't know if it is detecting the wrong pixel format or if the conversion function is wrong. Try changing which function is being called at line 234 of apps/unix/ximage.c and see if that helps.
Everything looks ok if I do the following change: --- mupdf-0.01release20090707.orig/apps/unix/ximage.c +++ mupdf-0.01release20090707/apps/unix/ximage.c @@ -232,7 +232,7 @@ } else if (info.bitsperpixel == 16) { if (rm == 0xF800 && gm == 0x07E0 && bm == 0x001F) - info.mode = !byterev ? RGB565 : RGB565_BR; + info.mode = byterev ? RGB565 : RGB565_BR; if (rm == 0x7C00 && gm == 0x03E0 && bm == 0x001F) info.mode = !byterev ? RGB555 : RGB555_BR; }
*** Bug 690598 has been marked as a duplicate of this bug. ***
Hi! I stumbled upon this bug too. It seems to hide in this code snippet in apps/x11_image.c : ------------------------------------------- #if BYTE_ORDER == BIG_ENDIAN byterev = byteorder != MSBFirst; #else byterev = byteorder != LSBFirst; #endif ------------------------------------------- The problem is that both BYTE_ORDER and BIG_ENDIAN are not defined anywhere, so "" == "" and it thinks that host is bigendian, whereas it's not (at least in my case :) I found that adding '#include <X11/Xarch.h>' at the head of apps/x11_image.c fixes problem on my little-endian hosts and pdf colors becomes natural. But it seems that there's also very similar conditional in draw/imageunpack.c : ------------------------------------------- #if BYTE_ORDER == LITTLE_ENDIAN ... #else ... #endif ------------------------------------------- so it probably breaks in similar fashion on big-endian hosts. And fixing it by including X11/Xarch.h would be a bad move, as imageunpack.c has no relation to X11, so probably another solution to all this woes would be to add some preprocessor code computing byte order directly to fitz/mupdf headers.
I believe I have fixed the endianness tests -- but since I don't have a machine capable of reproducing the problem I would appreciate if you could verify that the fix actually works.
I experienced this issue when cross compiling 0.6 for a mipsel target. I can confirm that the bug is not present in the current development tree (tested git fb6ec520ae3400bb7e1bf1857bf04a0316b7302b).