Bug 690932

Summary:	ximage conversion/detection of 16-bit displays is wrong
Product:	MuPDF	Reporter:	Timo Juhani Lindfors <timo.lindfors>
Component:	apps	Assignee:	Tor Andersson <tor.andersson>
Status:	NOTIFIED FIXED
Severity:	normal	CC:	graham.gower, kysucix, mad_soft
Priority:	P4
Version:	unspecified
Hardware:	Other
OS:	Linux
Customer:		Word Size:	---
Attachments:	screenshot. triplane-classic.pdf on 16-bit display with mupdf and xpdf

Description Timo Juhani Lindfors 2009-11-18 16:27:01 UTC

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".

Comment 1 Timo Juhani Lindfors 2009-11-18 16:28:27 UTC

Created attachment 5686 [details]
screenshot. triplane-classic.pdf on 16-bit display with mupdf and xpdf

Comment 2 Timo Juhani Lindfors 2009-11-18 16:32:16 UTC

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.

Comment 3 Tor Andersson 2009-11-19 08:05:45 UTC

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.

Comment 4 Timo Juhani Lindfors 2009-11-19 08:32:21 UTC

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;
        }

Comment 5 Tor Andersson 2010-01-17 06:50:34 UTC

*** Bug 690598 has been marked as a duplicate of this bug. ***

Comment 6 Dmitry Artamonow 2010-06-06 16:28:46 UTC

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.

Comment 7 Tor Andersson 2010-06-16 10:43:16 UTC

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.

Comment 8 Graham Gower 2010-08-20 01:30:10 UTC

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).