| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
If draw device is passed a pixmap with disabled separations, it
may have to push an extra group at the top to allow for the
actual rendering to properly happen in cmyk+spots, and then get
folded down at the end.
This pushing cannot happen at create time, due to it being
dependent on the defualt_cs settings. Accordingly, we push it
(just once) on the first drawing operation.
This means we need to be able to convert from "colorspace + set
of spots" to "different colorspace + different set of spots".
This in turn means we need to be able to drive lcms slightly
differently (to tell it whether to copy the spots unchanged
or not), so we have to amend the CMS interface code a bit for
that.
Currently we lack plotters to properly cope with plotting
images and shades with spots, so this will give a warning and
do nothing. To be filled in in future commits.
Ensure fz_get_icc_link accepts NULL to mean default color params.
Incorporates fixes from Michel Vrhel:
With transparency groups we can have RGB + spot pixmaps. When
drawing into those we need a mixture of colorant polarity. Ensure
that fz_convert_separation_colors takes account of this.
Fix C1 of Altona_Technical_1v1_x3.pdf (allow for output intent in
fz_clone_pixmap_area_with_different_seps).
|
|
|
|
Update separations interface further to cope with whether spots
should be rendered separately, or as composite colors.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Introduce FZ_PLOTTER defines to set which defines we required.
Add FZ_ENABLE define to set which document handlers are built
by default.
|
|
Use do {} while(--w) rather than while(w--) {} as this safes a
test each time around the loop.
|
|
For the common cases, avoid the loop.
|
|
Profilers can't identify which of the switch arms we are in for
the inlined function calls, so rejig the code so that each of these
is a separate function.
In theory this code should be faster too, as the function 'lookup'
is only done one rather than once per line, but I don't expect this
to make a huge difference.
|
|
Use this for plotters so we can see which ones are being used
in any given build.
Build with -DTRACK_USAGE to enable.
|
|
|
|
Converting a pixmap to an alpha only pixmap means "just keep
the alpha". If there IS no alpha, then a solid alpha is
assumed.
|
|
In the absence of the source image having an alpha plane, we were
dropping the constant alpha during linear interpolated plotting.
|
|
Only do int to int copying if we have an int to copy from.
Also, when copying int to int, copy int32_t to int32_t to make
us more future proof.
|
|
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.
|
|
When affine plotting with linear interpolation, we need to perform
different calculations for the texture and for the edge of the shape.
The edge of the shape needs to be calculated in exactly the same way
as for non-linear interpolated shapes.
The 'texture' position needs to be offset by 1/2 a texture unit in
each direction so that the 'pure' color is given in the middle of
the texture cells image, not in the top left corner.
To achieve these aims, we actually offset the u/v positions by 1/2
(32768, given the fixed point we are using) and adjust for this in
the boundary tests.
I have a test file that shows this working, which I will attach to
the bug, and add to the regression suite.
|
|
We had some code in draw-affine that we didn't really understand.
Change this for some code that seems more plausible.
The voodoo code was showing up problems with the plotter rework
(don't really know why), but the non-voodoo code seems happier.
|
|
|
|
|
|
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.
|
|
|
|
Set the hint in mudraw when AA bits is set to 0.
|
|
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.
|
|
|
