| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This fixes 2258_-_invalid_transparency_group_colorspace.pdf
|
|
Required for 1879_-_Indexed_colors_wrongly_converted.pdf
Also, removing broken code in the same place (where mat->v[] is
overwritten right after being set in the L*a*b* case).
|
|
This progresses among others Bug689803.pdf and
Alternate_colorspace_for_ICCBased_not_supported.pdf
|
|
This is required e.g. for 2314 - jpeg tables in tiff.xps.
This folds fz_open_resized_dct back into fz_open_dct instead of adding
further variations for calls with and without the jpegtables argument.
|
|
If opening a filter in pdf_open_crypt throws, the stream is closed in
the used fz_open_* method and thus mustn't be closed again.
|
|
|
|
Strip stupid project build settings.
Add proper "make generate" target that uses the 'macosx' sdkroot.
Rewrite cross compile build script to be more future proof.
|
|
|
|
There is the possibility of marking an object dirty via one indirection
and testing it via another. This patch ensures that is handled
correctly. The scenario occurred within calc.pdf and stopped the update
of the display field.
|
|
|
|
A user (sebblonline) reports a problem when rendering the 300Meg
document downloadable from:
http://www.mitsubishicarbide.com/EU/de/product/epaper/index.html
(7th icon on the bottom). Memento builds report that softmask objects
are leaked.
Tracing these it appears that the handling of softmasks in
pdf_run_xobject is not quite nested right. Fixing this reveals another
problem with clipping paths being doubly removed. Adding a gsave/grestore
pair solves this and leaves us with a well behaved program.
|
|
|
|
|
|
|
|
In particular, cope with the cases where xstep/ystep are not the same
as the tile width/heights.
|
|
Pull subpixel glyph adjustment calculations into fz_subpixel_adjust.
This reduces the repetition of code, and will be helpful for the
OpenGL device.
|
|
These do no caching, and are intended to be useful for the opengl device.
|
|
For large glyphs, sub pixel positioning is supremely unimportant.
Even for smaller glyphs, we don't need 5*5 possible sub pixel
positions. Base the degree of sub pixel quantisation on the size
of the glyphs.
This should result in better cache use.
We push all the glyph sub positioning logic into fz_render_glyph
(and fz_render_stroked_glyph). This simplifies the calling code.
We also tweak fz_render_glyph so that it updates the transform it
is called with to reflect the sub pixel positioning. This solves
various problems: Firstly, we can round positions both up and down
to achieve a smaller net displacement (e.g. (0.99, 0.99) can go
to (1,1) rather than (0.75, 0.75) if we have a subpixel position
resolution of 1/4 pixels).
Secondly, glyphs that are drawn from outlines will have exactly the
same subpixel changes applied. This is unlikely to be noticable, but
it does mean that baselines should avoid having any shifts in them.
Finally, it enables us to avoid lots of unnecessary copying of
matrices, hopefully reducing overhead.
|
|
Rather than generating fz_pixmaps for glyphs, we generate fz_glyphs.
fz_glyphs can either contain a pixmap, or an RLEd representation
(if it's a mask, and it's smaller).
Should take less memory in the cache, and should be faster to plot.
|
|
The most complex part here is to ensure that we can output various
bitmaps in bands.
|
|
fz_putc; this fills a hole in our fz_output functions.
fz_new_output_to_filename: This saves people having to create
a FILE * just to pass to fz_new_output_with_file and then having
to remember to close the FILE *.
|
|
|
|
|
|
|
|
This fixes among others 693274 - cmyk jpeg image.xps from bug 693274.
|
|
This fixes at least 2347 - old-style tiff jpeg compression.xps.
|
|
XPS extracts the resolution of a JPEG image from the image data. The
current code however only reads the density values provided by JFIF
metadata, while the XPS specification also allows for resolution to be
in either EXIF metadata or Photoshop's APP13 chunk. This patch adds
code for reading both kinds of metadata in order to get more consistent
behavior with Microsoft's XPS Viewer. Documents for reproducing this issue:
2093*.xps, 2249*.xps, 2252*.xps, 2268*.xps and "jpeg exif resolution.xps".
Another detail: The default resolution for JPEG images in XPS documents
is 96 DPI and not 72 DPI.
|
|
Gradients in XPS code are ordered by offset. If however two offsets are
equal, the order of the colors depends on the sort algorithm instead of
the original order in the document. This is shown e.g. in 2245*.xps:
<GradientStop Offset="0" Color="#ff00ff00" />
<GradientStop Offset="0.5" Color="#ff0000ff" />
<GradientStop Offset="0.5" Color="#ff00ff00" />
<GradientStop Offset="1" Color="#ff00ffff" />
Tracking the original order of gradient stops and always sorting earlier
stops first makes gradient ordering consistent.
|
|
If MuPDF is used in a project using Subversion or another VCS adding
hidden subfolders to each folder, cmapdump breaks when trying to
load the subfolder as cmap file. This fix is required starting with
643370f04348569b5e5e577660031d638537671c
|
|
|
|
By default an OCG is supposed to be visible (for a testcase, see
2011 - ocg without ocgs invisible.pdf). Also, the default visibility
value can be overwritten in both ways, so that pdf_is_hidden_ocg
must check the state both for being "OFF" and "ON" (testcase was
2066 - ocg not printed.pdf rendered with event="Print").
|
|
* If fz_alpha_from_gray throws in fz_render_t3_glyph, then glyph is leaked.
* If fz_new_image throws in pdf_load_image_imp, then colorspace and mask
are leaked.
* pdf_copy_pattern_gstate overwrites font and softmask without dropping
them first.
|
|
Content streams may contain multiple inline images compressed as LZW
data. The LZW filter used for such inline images might in some cases
be closed in a state where less than 8 bits remain unread. The parent
stream remembers that number (in stream->avail) and uses it again
when reading the next inline image instead of resetting the remaining
bit count when reading the next entire byte after the first inline image
(or resetting it when closing the LZW stream as this patch does).
|
|
If /EndOfLine is set for a CCITTFaxDecode stream, the image must start
with an EOL per the spec. Other readers seem to ignore all data up to
the first EOL in that case - instead of rejecting such images as broken.
Required for e.g. "1848 - 1d faxd doesn't start with EOL.pdf".
|
|
|
|
|
|
Broken in recent optimisations.
|
|
The symptoms were that, created annoations were in some cases not saved.
Some updated objects withing the document were not being moved into the
incremental-save xref section. That in turn was due to nodes within the
hierarchy of those objects not having their parent_num field set. The
objects falling foul of this problem were those held in object streams.
When any one object from a stream is cached, the whole stream is read and
all other objects from that stream are also cached, but only the initial
one has its parent_num set. This patch ensures that all objects from a
stream are accounted for. In fact, for the initially-requested object, we
now set parent_num twice, but that is harmless and the code to avoid doing
so wouls be an unnecessary complication.
|
|
|
|
|
|
|
|
|
|
|
|
This is the single largest hotspot in J11_acrobat.pdf on the pi,
by a massive margin.
J12_acrobat.pdf hits fz_paint_affine_g2rgb too.
|
|
If we want the alternative versions we can pull them out of git
later.
|
|
The 2 biggest hotspots in benchmarking on the Raspberry pi at
1200dpi.
|
|
Forgot to drop the font.
|
|
Previously there was a bug when parsing GoToR link annotations that had
a named destination. mupdf incorrectly attempted to resolve the
destination in the current document. Now the destination name is
present in the link objects returned to the application so it can
resolve any names for GoToR links in the remote document instead.
|
