| Age | Commit message (Collapse) | Author |
|---|
|
Fix bug 692282.
|
|
Fix bug 692325.
|
|
In an effort to solve bug 692377, examine what ghostscript does,
and move mupdf into line with it.
Firstly, it seems that rather than collecting a pure 'shape' plane
ghostscript keeps a 'shape-with-alpha' plane. Only a tiny change is
required to move mupdf to the do the same thing, so done here.
Secondly, it seems that ghostscript 'uncomposites' the result of
non-isolated groups, before applying the blend mode. It's not clear
to me that this is entirely correct; this 'uncomposite' operation
assumes that all compositing has been done internally with the
'normal' blend mode. Nonetheless, I do the same here, and it seems
to work.
This 'uncomposite' operation may yet turn out to be a source of bugs
if I have muddled the use of premultiplied and non-premultiplied
components, but it seems to work on the testfiles I have.
|
|
Comment #3 on bug 692377 notes that the "Hivemind" pdf (from bug
692203) has regressed; this is due to the new shape code not
working quite right with mask groups. Fixed here.
It also showed up a bug in the shape code with filled paths at non
full alpha. Also fixed.
In tracking this down, I've extended the DUMP_GROUP_BLENDS debugging
code to give more readable output. Also committed here.
This still leaves a regression in l16.pdf which the bug was originally
reopened about, but that's a much more minor one.
|
|
All glyphs in type3 colored fonts were drawn mirrored in y due to
an incorrectly setup transformation matrix.
The bug was reported by Zeniko, with a helpful example file that showed
the problem.
Until then I'd been working using only fts_23_2303.pdf as an example,
which uses geometric shapes, so isn't obvious that it's wrong. Also
my copy of acrobat fails to render them.
|
|
When playing back from a list, previously flags would just be 0 or
non-zero. This makes no real difference, but looks odd when traced.
|
|
Some code that I find useful for debugging the group blending code.
|
|
unsigned char * is not the same as char *.
|
|
To solve bug 691629 we need to ensure that the scaling weights for
every pixel in a gridfitted image sum to 256. I had attempted to
do that by enabling the 'WRAP' code, but this has the effect of
adding too much bias to the outlying source pixels, resulting in
thickened serifs etc.
A better fix is to extend the code that is already present to check
the weights for validity. If an image pixel is completely covered,
then force the weights to 256 by adjusting the largest weight.
This still skews the output slightly but it's a much less visible
result.
|
|
A combination of constant alpha and non-zero blending modes resulted
in incorrect rendering.
Various fixes seem to have made it work:
* Allow for non-full alpha when blending non-isolated groups back.
* Clamp blended pixels to allow for overflow.
* Allow for alpha in the shape blending.
|
|
When we calculate weights for scaling, 'wrap' weight calculations
slightly to avoid getting antialiased edge pixels in grid fitted
images.
Seems to solve bug 691629 as much as it's possible to.
|
|
Detect the d0 or d1 operators by writing a bit to the new device
flags word. This can then be checked by the Type3 code to create
the appropriate backing pixmap.
In order to know what the appropriate backing pixmap is, we pass
an additional colorspace into the glyph rendering code.
|
|
Not quite sure how this one slipped through - must add encrypted documents
to the mupdf test suite.
|
|
The problem is due to abutting images showing gaps between them.
These gaps are due to a combination of rounding errors, and anti-aliasing
effects on the edge of images.
The solution is to selectively 'grid fit' images.
If an image is part of a type 3 font, we do NOT want to grid fit it, as
this is where the sub pixel positioning makes a huge difference.
If an image is displayed with alpha, then we don't want to grid fit it
(as grid fitting will tend to make the edges of images overlap by 1
pixel, and will hence produce nasty effects).
Otherwise, we will grid fit; Grid fit in this sense is where we expand
an image to completely fill the pixel grid that it touches (i.e. the
extents for the image are expanded to pixel boundaries; no half full
pixels are left around the edges).
The only real change of note here is in how we detect that we are in a
type 3 charproc; we add a new draw device creation function that we call
in the type3 charproc case that sets a flag that the drawing functions
can check.
|
|
While in a knockout group, we create a new group around every single
object drawn. These groups are either isolated or non-isolated as
required (but non-isolated ones seed their background from two
backgrounds up the stack, not one).
|
|
Firstly, this takes on some of Zenikos patch to correct the clip
stack handling that was broken by the fix to bug 692287 (in commit
2c3bbbf). This bug should now be solved.
We add a new 'shape' field to the draw device structure (and clip
stack). When we are inside non-isolated groups, this is set to be
a pixmap where we accumulate the 'shape' of the objects drawn.
When we come to blend back, if we are blending a non-isolated group
back, we have to use a different blending function that takes account
of the shape.
Various internal groups (the page group, and groups used to force
blending) are set to be isolated to avoid carrying shape planes
around when this is not required.
All our rendering code now has to know how to maintain the shape
plane as well as doing the basic rendering.
|
|
First, we add clipping rects to clipping functions. Various functions
(the ones that handle clipping) are now additionally passed a rectangle
that represents an additional bound for this clip in device space
(i.e. it has already been mapped through the current ctm).
Next, when constructing the displaylist, keep track of the bounding box
for the contents of each clip.
While writing the list, on every node we add, we add the bbox for that
node to the enclosing clips content bbox (if there is an enclosing clip).
When we pop a clip, write back to the corresponding push to update
the bbox.
This means if we get large clip regions, with only small areas used within
them, we will only do the slow blending for those small areas.
Finally, we fix a calculation in fz_bound_path which was incorrectly
accounting for mitrelimits. This was showing up in testing on page 630
of the PDF reference v1.7.
|
|
In the existing mupdf clip path code, it would be possible for us to
render incorrectly; consider the following fragment of a content
stream:
0 0 100 100 re
W
50 50 100 100 re
f
That should set the clip path to the (0, 0) -> (100, 100) rectangle,
and then attempt to fill both the (0,0) -> (100,100) rectangle and the
(50,50) -> (150,150) rectangle, resulting in just the (0,0) -> (100,100)
rectangle being filled.
In the existing mupdf code, it would actually fill both rectangles as
the path after the W operation (the addition of the second rectangle)
would also affect the stored clip path.
We solve this by doing the clip operation on the W operator, rather than
deferred to when the path is actually disposed of.
|
|
The calculation of the translation due to the mediabox/cropbox was
wrong on android, causing nothing to be rendered.
|
|
If the app was hidden, and then restarted, it would leak lots of
memory due to onCreate not only being called on create. To fix
this, we armour the app a bit aginst such problems, including
adding code to destroy the core when the app really is destroyed.
|
|
In particular say where to get thirdparty and how to generate generated.
Also note that ndk-build should be run in android, NOT in andoid/jni.
|
|
Acrobat (and gs, see bug 690478) will open a file without a CF dictionary
by assuming that the encryption type is RC4. Mirror this in mupdf.
|
|
pdf/data_encodings.h and pdf/data_glyphlist.h were added without adding them
to the solution.
|
|
Bring the MuPDF android build up to date with the latest source changes.
Many thanks to Dominic Battre for his helpful report in bug 692222.
|
|
|
|
Bug 692245 gives a file that produces a runtime assert in mupdf due to an
extremely large ctm offset (unrepresentable in a float). We fix our code
here so that such floats are always read as 1.0.
In this particular case, the exact value read doesn't seem to matter. We
match acrobat. We pick 1.0 rather than 0.0 as this is less likely to
provoke division by 0 errors later on.
|
|
Added BEYOND_TRESHHOLD for pdfapp and code which flips to next/previous
page if one pans beyond the page end plus that threshhold.
|
|
Thanks to Zeniko for finding/reporting/patching the problem.
Due to a pointer miscalculation we were overwriting memory. Simple fix.
|
|
Some particularly broken generators forget to terminate the
comment with a newline. Skip the comment character so we'll
get some garbage tokens that we can ignore, rather than
consuming the innocent objects that follow on the same line
as the %.
|
|
|
|
|
|
|
|
Add libs (to allow for building of libraries without apps, such
as will be required for the WebOS bindings).
Add 2 webos OS setups to the Makerules file to match the 2 default
webos configurations used in the PDK.
|
|
|
|
|
|
Simple tweak to aid cross compiling.
|
|
Add 2 new makefile options to Mupdf. If CROSSCOMPILE is defined, then we
avoid performing tasks during the build that require a binary to be built
and then executed as part of the build. Currently this is just the cmap
and font dumping steps.
If NOX11 is defined, then we avoid building the X11 app.
Finally, in Makerules, we have a new section to show how to encapsulate
the changes for a given cross compile target. If OS is defined to be
"beagle-cross" then we build using given compilers/options.
|
|
FT_LOAD_TARGET_LIGHT implies the autohinter, which causes spectacular
failures on DynaLab fonts. The stripped down freetype we compile with
using the "thirdparty" package does not have the autohinter, which is
how this bug slipped through the regression testing.
|
|
|
|
|
|
|
|
These are the original Type1 fonts, without modifications.
They have been converted to CFF format, with preserved hints,
by FontForge.
|
|
|
|
|
|
The file in question is missing newlines, causing the first two
objects to be hidden because we treat the %PDF-1.3 version marker
as a comment.
|
|
|
|
|
|
|
|
This bug fix shaves another 650K off the compiled in cmaps!
Also fix the detection for when the cmap table is full, and ignore
surrogate pair mappings (since we can't do anything useful with
them at the moment).
|
|
|
