| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Several things irk me about passing values as const pointers:
* They can be NULL, which is not a valid value.
* They require explicit temporary variables for storage.
* They don't compose easily in a legible manner, requiring
weird pointer passing semantics where the variable being assigned
is hidden as an argument in the innermost function call.
* We can't change the value through the pointer, requiring yet more
local variables to hold copies of the input value.
In the device interface where we pass a matrix to a function, we often
find ourselves making a local copy of the matrix so we can concatenate
other transforms to it. This copying is a lot of unnecessary busywork
that I hope to eventually avoid by laying the groundwork with this
commit.
This is a rather large API change, so I apologize for the inconvenience,
but I hope the end result and gain in legibility will be worth the pain.
|
|
|
|
Rather than looking at their individual scale factors, they
were looking at the global one.
|
|
The "blend back" at the end of the inner knockout groups was
attempting to reuse the existing blending code. This was going
wrong for all sorts of reasons (not least the uncomposition
phase) for knockout groups containing alpha, such as found on
page 7 of Altona_Technical_v20_x4.pdf.
Use a dedicated routine. This is much simpler as it doesn't have
to cope with blend modes etc.
|
|
|
|
When pushing a transparency group, MuPDF used to always create a shape
plane if there was one before. Ghostscript works differently, and
only creates a shape plane if we are in a non-isolated group.
This means that when blending an isolated group back to a non
isolated group, GS uses the "source alpha" in place of the "shape
alpha" to modify the non-isolated groups shape plane.
We update MuPDF to do the same here - it requires some new (small)
routines to do this new type of shape update, but means we carry
smaller amounts of data around overall.
Also, for what little remains of my sanities sake, this helps by
making it easier to compare the debug output from the 2 different
renderers.
|
|
|
|
|
|
Introduce an fz_overprint bitmap (currently just a uint32_t,
but it'll grow to be an array of them if FZ_MAX_COLOR is
increased). Pointers to this are passed into all our
painting routines.
NULL means "Do what you've always done before, with no overprint".
non NULL, means that every set bit means "don't ever alter this
component".
We therefore set the overprint bitmap up according to the input
color/colorspace/colorparams before calling each routine.
|
|
(Incorporates fixes from Tor, Michael and Robin).
|
|
We still use the fz_context versions as the default, but these
can be overridden with draw device options.
|
|
|
|
This is intended to be a way to allow us to implement
compiletime/runtime selection of different scan converter
implementations.
|
|
In all cases we reset the gel before populating it, so pull this
out of the draw device into the population routines.
|
|
In all cases, we sort the gel before scan converting it. So
just roll the sort call into the scan convert call.
|
|
Missing qualifier from prototype.
|
|
Again, mainly so profiling works nicely.
|
|
Try and help C avoid pointer aliasing issues. Some of this may not
help at all. None of it should hurt though.
|
|
fz_pixmaps now have an explicit stride value. By default no change
from before, but code all copes with extra gaps at the end of the
line.
The alpha data in fz_pixmaps is no longer compulsory.
mudraw: use rgb not rgba (ppmraw), cmyk not cmyka (pkmraw).
Update halftone code to not expect alpha plane.
Update PNG writing to cope with alpha less input.
Also hide repeated params within the png output context.
ARM code needs updating.
|
|
In general, we should use 'const fz_blah' in device calls whenever
the callee should not alter the fz_blah.
Push this through. This shows up various places where we fz_keep
and fz_drop these const things.
I've updated the fz_keep and fz_drops with appropriate casts
to remove the consts. We may need to do the union dance to avoid
the consts for some compilers, but will only do that if required.
I think this is nicer overall, even allowing for the const<->no const
problems.
|
|
By default in MuPDF, when we render an axis aligned image, we
'gridfit' it. This is a heuristic used to improve the rendering
of tiled images, and avoid the background showing through on the
antialiased edges.
The general algorithm we use is to expand any image outwards so that
it completely covers any pixels that it touches any part of. This is
'safe' in that we never cause any pixels to not be covered that
should otherwise be so, and is important when we have images that are
aligned with (say) line art rectangles.
For gproof files though, this gives nasty results - because we have
multiple images tiled across the page all exactly abutting, in most
cases the edges will not be on exact integer coordinates. This means
we expand both images and 1 (destination) pixel is lost. This severely
hurts the rendering (in particular on text based pages).
We therefore introduce a new type of grid fitting, where we simply
align the edges of images to the closest integer pixel. This is safe
because we know that neighbouring images will be adjusted identically
and edges will stay coincident.
We enable/disable this behaviour through a new device flag, and make
the gproof interpreter set/clear this flag when generating the page -
thus normal rendering is unaffected.
We *could* have just poked the dev->flags fields directly, but that
would require magic in the display list device to check for them
being set/unset and to poke the dev->flags fields on playback, so
instead we introduce a new fz_render_flags function (that calls a
device function) to set/unset flags.
The other attraction of this is that if we ever have devices that
'filter', we can neatly handle passing flag changes on with those.
Currently the display list implementation only copes with set/clear
of the FZ_DEVFLAG_GRIDFIT_AS_TILED option. We only readily have 6
bits available to us, so we'll just extend this as required if we
add new render flags.
|
|
This is not a complete general fix for features dropping out of
rendered line art, but merely a fix for one of the more common
cases.
When rendering rectangles (currently, specifically only those
rectangles that are actually defined as rectangles within the
path structure), if they are axis aligned, then ensure that they
always fill the subpixel line they are on.
|
|
Purge several embedded contexts:
Remove embedded context in fz_output.
Remove embedded context in fz_stream.
Remove embedded context in fz_device.
Remove fz_rebind_stream (since it is no longer necessary).
Remove embedded context in svg_device.
Remove embedded context in XML parser.
Add ctx argument to fz_document functions.
Remove embedded context in fz_document.
Remove embedded context in pdf_document.
Remove embedded context in pdf_obj.
Make fz_page independent of fz_document in the interface.
We shouldn't need to pass the document to all functions handling a page.
If a page is tied to the source document, it's redundant; otherwise it's
just pointless.
Fix reference counting oddity in fz_new_image_from_pixmap.
|
|
Rename fz_close to fz_drop_stream.
Rename fz_close_archive to fz_drop_archive.
Rename fz_close_output to fz_drop_output.
Rename fz_free_* to fz_drop_*.
Rename pdf_free_* to pdf_drop_*.
Rename xps_free_* to xps_drop_*.
|
|
Set the hint in mudraw when AA bits is set to 0.
|
|
The first file of this bug (hang-66.pdf) hangs while stroking a
VERY long line segment; so long that 'used' is sufficinetly large
that:
used += dash_segment_len
doesn't result in a change in the value of used. The fix is
to clip strokes to the edge of the gel's clip area, meaning
that this should never occur.
|
|
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.
|
|
|
