The bug tracking for MuPDF has been moved to http://bugs.ghostscript.com/buglist.cgi?product=MuPDF.
This page lists bugs I know about in mupdf mainstream sources.
Compared to Adobe Reader, most of the text is missing (might be windows-specifi thing), colors aren't always right. Didn't investigate.
The document uses Separation colors, which are always rendered as grayscale.
Updating the colorspace rendering code to use the alternate tint transform should
make this PDF look more correct. On the TODO list. -Tor
Displays incorrect chinese characters (when compared to Reader).
In bad-chinese-00.pdf: uses SimSun font and correctly picks Window's SimSun font. The font has encoding gbk-euc-h. For whatever reason either the cid in ftrender is not right, or Window's SimSun is messed up (but I would thing Reader uses the same font so it shouldn't be).
Fixed. CJK fonts loaded from a system file were not flagged as substitute fonts, causing them to get encoding errors. -Tor
Compared to Reader: the black circle is gray (semi-transparent?). This might be releated to blending. Also, the green text "501st Legion..." has drop-shadow in Reader.
Another page that renders differently from Reader that seems to be related to 4.
Complex form is not rendered at all. Instead, the document says "To view the full contents of this document...blah,blah, use Reader"
The content stream consists of the text "To view the full contents..." MuPDF does not
support interactive forms, so I suggest closing this as WONTFIX or implementing support
for interactive forms (ugh). -Tor
Reader renders a different color for non-white-and-black parts (blue in Reader, more greenish in mupdf).
Few problems compared to Reader:
- a white line in the middle, not present in Reader
- different colors (Reader colors seem more saturated and no white on the right (looks like a different kind of radient)
- lower part of the image in Reader is not semi-transparent
Reader masks some text with bullets, as if they were passwords (even though it's selectable text and can be copy&pasted from Reader). mupdf just displays it.
Also, a different font is picked up for the upper text (substituting EurostileExtended, I imagine, which Reader maps to Adobe Sans MM)
Text positioning messed up (due to weird embedded fonts?)
Reader needed to download 10MB japanese font file, even though this document doesn't seem to have japanese characters. Maybe it was for the cmap. Fonts used: MS-PGothic, mapped to MSPGothic and MSPGothic with 90msp-RKSJ-H cmap, also mapped to MSPGothic.
Wontfix. The file actually uses Japanese fonts and encodings, even though the text is in latin characters. -Tor
Vector graphics are not rendered (http://code.google.com/p/sumatrapdf/issues/detail?id=216)
Looks like an inverted clip path. I'll need to investigate this more closely.
Adobe shows a bunch of red rectangles. mupdf shows a bunch of colorful triangles. Probably to do with handling of shade type 4.
The shading code is full of problems; this is one of them. The red rectangles are rendered
as a shading function using 32 bits per component, but the code incorrectly assumes that
it's always using 24 bits per component. The shading code needs a big revamp.
On the TODO list. -Tor
Barcode is not being rendered (http://code.google.com/p/sumatrapdf/issues/detail?id=302)
From http://code.google.com/p/sumatrapdf/issues/detail?id=297
Problems: very slow, spending most of the time re-allocating memory in growshademesh(). Also, seems to be using too much memory:
c:\kjk\src\sumatrapdf>obj-rel\pdftool.exe draw -m c:\kjk\downloads\ExampleWithLotsOfShading.pdf
draw c:\kjk\downloads\ExampleWithLotsOfShading.pdf page 1 warning: cannot realloc 11341824 bytes
warning: cannot realloc 11309056 bytes
warning: cannot realloc 2625536 bytes
warning: cannot realloc 1314816 bytes
Partial fix for slowness: increase grow factor from 1024 to e.g. 8*1024 in triangulatepatch() as in http://github.com/kjk/mupdf/commit/ed5bb92cb294eb159ba4f701b077b0713092a302
This PDF has two inline jpeg (jfif) images and they're rejected by libjpeg. Either they're corrupted or we're not passing the right data to libjpeg. Adobe Reader handles them. Also, maybe not being able to load inline image shouldn't be fatal - there's more content on this page that could be rendered even if images cannot be loaded.
2 black rectangles, Reader shows green and red rectangles with gray border.
Reader substitutes non-embedded font KochAntiqua with Adobe Serif MM. Also white stripes across in yellow background while it's solid yellow in Reader.
Page extracted from http://code.google.com/p/sumatrapdf/issues/detail?id=322
Nothing shows up, Reader shows text. Is it caused by fonts with custom encoding?
Reader shows orange circle. We show more reddish circle with some some line artifacts. A simplified test case for http://code.google.com/p/sumatrapdf/issues/detail?id=327
From http://code.google.com/p/sumatrapdf/issues/detail?id=336
Pattern not rendered correctly.
This is a circle that should exactly fill the page but it only does that at zoom of 800%. When rendered at 100%, right and bottom parts are slightly cut off. The amount being cut off gets smaller when we increase zoom.
Crash due to stack overflow in cleanmask(), at least in debug build on Windows with genereous 1MB stack.
Got broken by this change: http://ccxvii.net/darcsweb.cgi?r=fitz;a=commitdiff;h=20080824223202-86a4e-c1a252485fdf51e35d1d7cbbbdd45ff5e6925962.gz
Rendering fails. Weirdly, doesn't go through fz_throwimp, so don't know why.
Jpeg on page 49 cannot be processed. However, when I extract just the page 49 using pdftool, it can be rendered so maybe there's a problem positioning the stream. Also, Reader renders it just fine.
We render more than Reader (two rectangles).
32. http://kjkpub.s3.amazonaws.com/mupdf/bug354.pdf
See http://code.google.com/p/sumatrapdf/issues/detail?id=354 for more information.
Comments (0)
You don't have permission to comment on this page.