| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
As before; better to define and use a specific warning because that only
appears once, unlike the printf messages.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test file Bug688485.pdf
If a SMask is missing the Group (/G) raise an error rather than
a dmprintf.
Same for a missing or unrecognised Subtype (/S)
And for XObjects with the /PS (PostScript) subtype.
Errors and warnings are preferred to printf because we only report them
once at the end rather than on each occurrence which can be annoyingly
verbose.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #705966 " Problem with transparency of a white box turning black (PDF exported from LibreOffice)"
The PDF file has a Form XObject which fills a rectangle but does not
set the colour or colour space before doing so; it 'inherits' the
colour and colour space in force at the time the Form is executed.
However, the Form also has a transparency Group, and that Group has a
/CS (colour space) which differs from the parent.
We were preserving the current colour space by retrieving the space
before calling pdfi_trans_begin_form_group(), which sets the colour
space before calling gs_beging_transparency_group(), and the setting
the space back after pdfi_trans_begin_form_group, but we were not
preserving the color value(s).
This commit additionally retrieves the current colour, and modifies
pdfi_form_execgroup() to take a client_color as well as a pointer to a
colour space, and set both the space and the colour before running the
Form content stream.
This retains the colour and space at the time the form was executed
while still setting the colour space correctly for the Group.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This spins out of bug 705260.
The main focus of this commit was to get the alphabits stroke
fill operation to work properly with the pdf14 device. When
fill stroke operations occur with overprint and transparency
there are specific pdf14 setups required as outlined by the pdf
spec.
Prior to this, the pdf14 stroke/fill method would do all the
required setup within that method. This setup needed to be
accessible to the abuf device when it is doing its stroke/fill
method. This was achieved through the use of a special operation
which has been renamed from gxdso_overprint_op to gxdso_abuf_optrans
to make it clear that it is really only used by the abuf device
for communicating to the overprint and transparency compositors.
Essentially the parts that handled all the special transparency
operations were pulled out of the pdf14 stroke/fill method and made
available for use during the special operations call of
gxdso_abuf_optrans. A state variable was maintained to pass information
as we move from fill to stroke.
There were several additional issues found during this work.
1) The pdf14 op_state which tracks if we are doing fill or
stroke was not getting updated in pdf14_set_marking_params
which caused the wrong overprint state to be used when we
had stroke/fill operations with differing overprint settings
during clist reading.
2) The alpha buffer device must clear its buffer between
the fill and stroke operations and before the overprint state
is restored to its prior state. Otherwise data can remain in
the memory buffer and is not released until the device is closed,
at which point the overprint state may have changed.
3) From careful review, it was clear that when the stroke
and fill alpha both equal 1 and the blend mode is normal
no special groups are pushed in the presence of overprint.
4) The interpreter was pushing a group during stroke/fill
overprint cases. This has been removed as the pdf14 device
will handle all of these decisions.
In case git messes up the attribution, this code was originally
written by Michael Vrhel, and then the gxdso behaviour was
altered by Robin Watts. Credit to Michael, blame to Robin as
usual!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a typo in pdfi_trans_set_mask() which meant that if we had
an error from pdfi_form_execgroup() we would overwrite it with the
(probably successful) return code from gs_end_transparency_mask() and
would ignore any error code from that function.
In addition pdfi_trans_set_params didn't pass back any errors from
pdfi_trans_set_mask() leading to them being lost.
Finally, in pdfi_trans_set_mask() if we have already processed a SMask
then don't return 1, return 0 to indicate success.
This series of problems was preventing the gs_error_Fatal code in
gdevp14.c, pdf14_pop_transparency_group() being propagated back to the
caller. Since this is intended to prevent a seg fault on a serious
(should never happen) error condition it's quite important not to lose
it.
|
| |
|
|
| |
No allocation/deallocation required.
|
| |
|
|
|
| |
All code now reads pdf obj types using pdfi_type_of rather than directly
accessing obj->type. This will help us in the next optimisation step.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #705079 "Blending issue with the drop-shadow image"
This turns out to be because the new PDF interpreter was not setting the
current colour space to be the /CS from the XObject group attributes
dictionary.
Attempting to do this turned out to be well nigh impossible. We can't
(not sure why but it certainly doesn't work) use gsave/grestore to
preserve the colour space. Attempting to replicate the old PDF interpreter
in PostScript behaviour and copying the current colour and spaces led
to seg faults.
On closer inspection, however, it turns out that the only reason for
setting the current colour space is because the pdf14 compositor
discards the ColorSpace passed in from the interpreter. The interpreter
passes a gs_transparency_group_params_t structure, which cotnains an
entry for the ColorSpace, the graphics library however copies the entries
into a gs_pdf14trans_params_t which does *not* contain a ColorSpace.
I've no idea what the point of this was, but it seems mad. This commit
adds a new member 'ColorSpace' to the gs_pdf14trans_params_t
structure, and initialises it from the gs_transparency_group_params_t
structure. We then modify pdfwrite to use that instead of the current
colour space.
The PostScript and C based PDF interpreters both already initialised
that member so nothing further needed to be done there. The XPS
interpreter did not initialise that member, and so we also update it
to do so.
This fixes the bug and shows no diffs on the cluster.
Finally update the PDF interpreter, it seems that the old code
accepted a /ColorSpace in place of a /CS in the group attributes
dictionary even though this is technically invalid.
Fall back to the current colour space if no /CS or /ColorSpace is
present in the group attributes dictionary (this is illegal but
it might 'work').
Finally add a check, as per the old code, to see that the number
of components for the colour space matches the number of components
in the /BC array if one is supplied. Unlike Acrobat we choose not
to ignore the SMask if they don't match.
We do emit warnings/errors for all the above conditions.
|
| |
|
|
|
|
|
| |
If begin transparency group returns an error, do not set the
GroupPushed state variable to true. Otherwise we will end
up doing an unmatched end group command later, leading to
the seg fault.
|
| |
|
|
| |
Fixes compiler warning comparing different enum types.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In cases where -dOverprint=/simulate and -dUsePDFX3Profile
are used, if the page has overprint and no transparency push the
pdf14 device and render the page to a transparency buffer
to the Output intent color space. If the target device has a
different ICC profile than the output intent (specified
with something like -sOutputICCProfile="Fogra39.icc") then
convert the output intent rendered buffer to the target
device color space. Also make sure that the tiff device do
not use the wrong profile in the header.
Additionally, a problem was found where the pdf14 device
was setting up color conversions using the perceptual rendering
intent. Those transforms should be using the colorimetric
rendering intent.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When simulate overprint is set for a sep device, there is no
need to do a simulation as the device already supports spot
color overprinting. This will change in the future for cases
dealing with rendering to the output intent but the target
device uses a different ICC profile. This issue occurred only
with pdfi.
There was also a problem with the use of patterns in the
case where we are doing overprint simulation. If the pattern
accumulator target is the pdf14 device and we are doing
overprint simulation, then it is necessary
that the pattern accumulator uses transparency. This problem
occurs for the old PDF interpreter and pdfi. This commit
fixes the issue for pdfi. The old PDF interpreter needs an
additional fix.
Example command line with issues
-sDEVICE=bitrgbtags -dMaxBitmap=10000000000 -dNEWPDF=true/false -dOverprint=/simulate -r72 -o testout.ppm -f Bug693541.pdf
|
| |
|
|
|
|
|
|
| |
The setting of -dOverprint=/simulate /enable /disable
is handled as a device parameter and not a command line
option. Make the changes so that gpdf and gs with -dNEWPDF=true
provide the proper rendering. Tested with RGB, CMYK,
and separation devices for each of the three settings.
|
| |
|
|
|
|
|
|
|
| |
For various operations (text/shadings/images), we currently find
a bbox (which involves a gsave/grestore pair) regardless of whether
we actually need the bbox.
Here we add some simple code to short circuit this work if transparency
in use. The big win here is with text.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the pdfi graphics state.
Previously, we relied on pdfi_gsave/pdfi_grestore to keep the reference count
correct for pdfi font from which the current gs_font in the graphics state is
derived. This was, at best, a compromised approach, since it meant the lifespan
of the font object was not directly tied to the graphics state which referenced
it. We opted for this because, at the time, we wanted to avoid the upheaval of
implementing a pdfi specific graphics state.
That approach also couldn't account for graphics state copies created and
destroyed by means other than gs_gsave/gs_grestore - such as saving the graphics
state for subsequent use when evaluating an SMask group.
Subsequently, other requirements made it clear a pdfi specific graphics state
was absolutely required.
As such, it makes sense to store a reference to the current (pdfi) font in the
pdfi graphics state and, since the pdfi graphics state lifespan is tied to the
gs_gstate lifespan, thus we can now connect the font objects' reference count
to the graphics state(s) that refernce them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In gs_begin_transparency_mask() the code uses any supplied transfer
function, and assumes it will be a 1-in, 1-out function, so it only
supplied a single float (rather than an array) for the output value.
But the code does not check the transfer function only has a single
output before calling the function to sample it, which would lead to the
evaluation code running off the end of the array.
Since the transparency code doesn't validate the function, do so in
the interpreter code. If the function isn't valid just ignore it.
|
| | |
|
| |
|
|
|
| |
The group that we push for dealing with the softmask should
not be isolated if we have a normal blend case.
|
| |
|
|
|
|
| |
If we are in an overprint situation with an image that includes
a softmask, we may need to use a compatible overprint blend mode
for the group that follows the image softmask.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we encounter an image with an SMask we must push an Isolated group
to render the image. If the SMask image has a /Matte entry, then we need
to push the group with the colour space of the image.
Since the image code is the only client for the transparency routine
pdfi_trans_begin_isolated_group() it's simples to make that routine take
an additional parameter which is the colour space to be used for the
group, or NULL if none.
We can then directly use the passed in colour space to set the params
ColorSpace member for the group.
To facilitate determining whether an image SMask has a Matte or not,
its convenient to modify pdfi_image_get_matte() to return a boolean
indicating that. This was in fact already being used for that purpose
(pdfi_image_setup_type3x) by checking the return value was positive,
but I think it's more obvious to have the function update a specific
boolean parameter.
This is propagated back through pdfi_do_image_smask() for the benefit
of pdfi_do_image().
This fixes 4 files:
tests_private/pdf/PDF_1.7_FTS/fts_26_2605.pdf
tests_private/pdf/uploads/bug700571.pdf
These 2 files only exhibited a problem with psddcmyk16 for some reason.
tests_private/pdf/sumatra/uninitialized_value_with_JPX_images.pdf
tests_private/pdf/PDF_1.7_FTS/fts_17_1718.pdf
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The initial fix here is from Michael who has done all the diagnostic
work on this.
The original code was always pushing an Isolated group, if it pushed
a group. This was incorrect.
Michael then pointed out that pdfi_shading_setup_trans()
does a gsave/grestore around pdfi_trans_setup(). But that function
can potentially change the blending mode (and push a group) and if
we grestore after it, then we throw that away.
The reason we do the gsave/grestore is because we must create a path
so that we can give a bbox to the group. If we have a BBox in the
Shading we can just use that. If we don't then we need to use the
current clip. In order to use the current clip we call clippath() to
create a path from it in the graphics state.
Obviously this changes the graphics state, which is something we don't
want to happen, so we gsave/grestore round it. There is similar code in
pdfi_image_setup_trans().
To avoid this, we no longer use the original pdfi_trans_setup() which
was in any case a one line wrapper around the code doing the real work.
Instead we always call the old 'inner' routine, which means we must
always either supply a bbox, or ensure that the current path is valid
and supply NULL for a bbox.
For stroke and fill the current path is fine. For shadings and images
we now gsave, construct a path, get its bbox, grestore and then pass
the bbox to the new pdfi_trans_setup() function (which is the old
'inner' function renamed). This avoids doing a gsave/grestore round
the potential change in blending mode.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This file was originally copied from the XPS interpreter verbatim, and
included a load of .h files which were then included needlessly in
all of the C files.
This removes almost all the .h files from ghostpdf.h; we keep gserrors.h
since so many C files do actually use it to report errors, and
gxgstate.h which is used in ghostpdf.h
The various C and H files have been updated to pull in the include
files they actually need.
|
|
|
This is a commit of the pdfi branch to master, eliminating
the traditional merge step.
The full history of the pdfi branch can be seen in the repo,
and that branch is effectively frozen from this point onwards.
This commit actually differs from pdfi in a small number of
whitespace changes (trailing spaces etc).
|
