| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The changes here are largely forced upon us by the rop source device,
the internal mechanism used within the gs lib to cope with performing
rop operations with drawing operations. The rop source device is
created and is given a 'source'. Any operations then done to that device
are then passed on to its target device rewritten into a form that will
cause the output to be ropped with the source.
This causes problems when the source is in planar format (such as when
the source is a pattern tile intended for use on a planar device). There
is no way to call strip_copy_rop with planar data currently, neither
can it easily be shoehorned through. We therefore add a new
'strip_copy_rop2' entrypoint that takes an additional 'planar_height'
parameter that gives the number of lines of data before the next
planes data starts.
We add implementations of this call throughout the code; some are
very simple (bbox, null, trace, clip, clip2, clip2, tile_clip etc).
Others 'common up' with the strip_copy_rop (gx_default,
mem_planar).
The underlying memory devices should never be called with strip_copy_rop2
as the planar data will always be rewritten to chunky format before
this happens. We are free to change this approach later if we want.
The gx_rop_source_t structure used by the rop source device is extended
to have a new planar_height field, and the rop source device itself
extended to pass this on. Various places that create this structure now
initialise that correctly.
The clist reader/writer is updated to send the extra planar_height
field through and call strip_cop_rop or strip_copy_rop2 as appropriate.
In a similar vein, we are forced to change the copy_plane entry point
to be copy_planes (as it is impossible (or very hard at least) for the
rop source device to implement copy_plane).
This incorporates changes from Michael to the new "fast threshold" image
halftoning code to make it use the new copy_planes operation.
|
|
CLUSTER_UNTESTED
|
|
The memory->gs_lib_ctx->BITTAG hack was inherently NOT safe for use by multiple
rendering threads. Devices that want to encode the tag info in the gx_color_index
need the tag, so we have moved this to the device structure. Multiple rendering
threads each have unique buffer devices, so this allows clist playback to set
and use the appropriate tag as the bands are played back without thread
interference.
Rename the gs_object_tag_type_t to gs_graphics_type_t to make it more unique for
grep based searching and prevent confusion with other uses of the term 'object'.
Move the enum to gscms.h with the 'set' functions prototyped in gxdevcli.h.
Just as for the device's cmm_dev_profile_t information, the tag needs to be
forwarded by devices in the chain (clipper, compositor) so that these 'helper'
filtering devices don't interfere with the setting of the tag. The tag value is
maintained in all devices in the chain so a 'get_graphics_type_tag' dev_proc
is not needed -- the dev->graphics_type_tag can be access directly.
Previously, tags were not recorded except for devices that enabled tags.
Now tags are tracked for all devices for use in selecting an ICC profile
and a device can signal that it maintains tags by setting GS_DEVICE_ENCODES_TAGS
for use by compositors that want to know whether or not to maintain a tag
plane, such as the pdf14 device.
Also replace the old 'get_object_type' that the anti-aliasing used with the
single approach for consistency and to cure problems (not identifed) with using
AA when other devices are interposed in the chain (clipper, compositor).
EXPECTED_DIFFERENCES:
Various 12-07D.PS PS LL3 CET files will show color differences on page 3 (GLOBINT)
as described in Bug692334.
|
|
This was caused by a clip device created for tiling a mask with a transparent
pattern rendered with a clist. The clip device used for rendering did not
get its color_info updated when its target (pdf14) changed the color_info,
specifically the depth.
Fixed by grabbing the target color_info after calling the target's compositor.
|
|
|
|
This is the major portion of the code needed to achieve object dependent
color management. This fixes the problems that existed in the
previous code with the device parameters and introduces an array of
ICC profiles in the device structure. The code was cluster pushed and
showed some very minor differences in a couple files but they appear to be
OK with bmpcmp. I still need to do further testing to verify that all the
functionality is correct (e.g. make sure setting the text profile properly
affects the text only). In addition, the rendering intent options need to be
implemented.
I also need to check that nothing was broken with respect to MT
rendering and some of the devices that are not tested with cluster
pushing (e.g. the display device and the x11alpha device).
|
|
Remove unused variable, left over from merge.
CLUSTER_UNTESTED
|
|
Conflicts:
gs/base/gdevnfwd.c
gs/base/gxdevice.h
gs/toolbin/bmpcmp.c
All trivially resolved except for gdevnfwd.c where I backed out one of the
fixes from 8ae4342 on instruction from Michael.
|
|
The nullpage device previously used a 1"x1" default page size, this changes it
to use the same default setting as other page devices (this can be Letter or
A4, set in a makefile).
Also, add some lower bounds checking to gslp.ps so that it will error out if
the page size is too small to hold at least one line of text.
No cluster difference expected.
|
|
change adds in a new device procedure called get_profile, which is going to
typically be set to gx_forward_get_profile or gx_default_get_profile. Most
internal devices like the pattern accumulator, the clip device, memory devices,
will use the gx_forward_get_profile procedure. In this way, the profile is
typically only maintained by the the target device. The gdevp14 device is the significant internal device that takes special handling due to the way that it
can change its ICC profile based upon the current transparency group color space. The get_profile procedure also passes along information about the object
type so that we will be able to easily add in the device dependent color
management. The rendering intent, which can also be object dependent is also returned by the call. This change has been cluster tested and showed no differences.
|
|
Fix up some stray trailing whitespace.
Also, gx_forward_create_compositor was neglecting to return a value.
|
|
compositor, the ICC profile of the clip device needs to be updated if the compositor action results in a device profile change. Also fix so that when the soft mask ICC profiles are swapped in or out the graphic state ICC profiles are also updated.
|
|
In DEBUG builds gx_device_dump(gx_device *dev, char *text); prints a
recursive listing of devices, their refcounts and names, and targets.
If anyone spots a forwarding device this doesn't work with, please let me
know.
No cluster differences expected.
|
|
At some point around the creation of this branch (which corresponded to our
move from SVN to git) we lost a line in gdevnfwd.c that sets up a default
forwarding for map_rgb_color. We don't know why it went, so we're putting it
back in. This probably hasn't caused any problems as it's a deprecated
function now.
|
|
A squashed and rebased patch based on the following svn commits.
Author: robin <robin@a1074d23-0009-0410-80fe-cf8c14f379e6>
Date: Tue Apr 19 12:40:00 2011 +0000
Various fixes to the transparency clist branch to correctly use
just the subrectangle of transparency tiles that is actually present.
Getting this in before the Great Git Change this afternoon.
git-svn-id: http://svn.ghostscript.com/ghostscript/branches/patt_trans_clist_gs@12407 a1074d23-0009-0410-80fe-cf8c14f379e6
Author: ray <ray@a1074d23-0009-0410-80fe-cf8c14f379e6>
Date: Fri Apr 8 16:56:48 2011 +0000
A couple of minor fixes that help things along, get past compile errors.
git-svn-id: http://svn.ghostscript.com/ghostscript/branches/patt_trans_clist_gs@12379 a1074d23-0009-0410-80fe-cf8c14f379e6
Author: mvrhel <mvrhel@a1074d23-0009-0410-80fe-cf8c14f379e6>
Date: Wed Feb 9 21:38:24 2011 +0000
Initial commit of work so far on getting the pattern transparency
clist code working. Much of this comes from work that Ray and I did
for customer 532. The remaining portion of the work is primarily
in pdf14_tile_pattern_fill in gdevp14.c, where we need to make
sure that the group that we are going to push is the intersection
with the rect from trans pattern since we only use the part that we
drew into in the pattern creation and not the whole group buffer. I
had not worked on this in a few weeks so I don't have more details
right now. I will spend a day on it this week to see exactly what
remains to be done.
git-svn-id: http://svn.ghostscript.com/ghostscript/branches/patt_trans_clist_gs@12137 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
|
|
This involved the addition of a copy_alpha procedure for the gdevp14 device. In addition, the anti-aliasing parameters for the target device are passed along to the gdevp14 device. The gdevp14 clist device uses the forward copy alpha operation, so that we end up using the clist_copy_alpha operation. Then during the clist reading phase we use the gdevp14 device's copy_alpha command.
There are two things that I do need to do in relation to this commit. One is that the operation that actually computes and applies the alpha associated with the transparency needs to be optimized so that we are not doing floating point math. Also, support needs to be added for knockout fills. However, for the vast majority of files with transparency we should now have support with -dGraphicAlphaBits and -dTextAlphaBits.
I will open a bug on the two outstanding issues so that I don't forget.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12338 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
to the 'default' (or base) implementations for unknown operations. Stupid
of me to have got this wrong initially, as it is one of the main purposes
of this mechanism.
No cluster differences expected.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12327 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
that defines the operation enumeration for it.
Move existing calls of pattern_manage across to using dev_spec_op instead.
Add comments to the pattern management definitions noting that it is
deprecated and should not be used.
No cluster differences (aside from indeterminisms).
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12326 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
target device does not have standard color mapping procedures. This occurs for example, in the case for the CUPs device where the color mapping procedures map CMYK, RGB and Gray to the current CUPs device color space. For standard gray, RGB and CMYK devices these procedures are avoided as the CMM performs all the required mappings. This commit will show differences in the files for the cups device as well as the psdcmyk device, which also should be using the non-optimized flow due to the use of CMYK + spot colorants, which will not be managed correctly by the CMM in general. The differences int the psdcmyk files that do not have extra spot colorants are tiny. This should fix bug 691760.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12005 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
This will make it easier to handle dynamic changes that may occur to the process color model for the device. Also a move of device profiles into non gc memory and removal of any references to profiles to the GC. A few progressions occur with this commit including Bug689918.pdf testpage.pdf.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@11619 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
caused by revision 10391, where I pulled the rectangle special cases into
line with the more general case. Sadly, the more general case appears to be
wrong in the way it rounds lines lying on integer values.
The fix is to correct the rounding in the general case, and to keep the
rectangle special cases in line with this. Unfortunately this produces
unacceptable results with the PCL interpreter.
We therefore commit a compromise solution, whereby we make the code do the
'correct' thing (or what we believe the correct thing is) for postscript,
and leave operation alone for the other languages. We spot this by examining
the fill_adjust values. This seems to works, with the minor problem that we
still see some changes in PCL due to it sometimes using non-zero fill_adjust
to thicken lines. A visual check shows the diffs to be reasonable.
Expected Differences: MANY. But extensively checked with htmldiff and they
seem OK.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@10620 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
was NULL. This occurred with the standalone 'bbox' device.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@10395 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
was not being properly maintained when put_params resulted in a target device
closing due to DeviceN color state changing.
DETAILS:
The check in zputdeviceparams relied on code > 0 or the width or height change
in order to determine that the device needed to be reinitialized. The put_params
forwarding needed to check if the target device closed (such as when DeviceN
parameters changed) and return code=1 to trigger the device reinitialization.
Also the forwarding of close_device needed to make sure and set is_open=false
if it called the target device procedure directly instead of using gs_closedevice
(which takes care of this detail).
EXPECTED DIFFERENCES:
The following 9 regression file(s) stop producing a Seg_Fault:
tests/pdf/pattrans_30.pdf.psdcmyk.72.0
tests/pdf/pattrans_45.pdf.psdcmyk.72.0
tests/pdf/pattrans_big.pdf.psdcmyk.72.0
tests/pdf/pattrans_scaledown.pdf.psdcmyk.72.0
tests/pdf/pattrans_scaleup.pdf.psdcmyk.72.0
tests/pdf/pattrans_simple.pdf.psdcmyk.72.0
tests/pdf/pattrans_solid_nonrect.pdf.psdcmyk.72.0
tests/pdf/pattrans_solid_rect.pdf.psdcmyk.72.0
tests/pdf/pattrans_translate.pdf.psdcmyk.72.0
--This line, and th se below, will be ignored--
M gdevp14.c
M gdevnfwd.c
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@10369 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
The new method improves the handling of 'erasepage' and 'fillpage'
for high level devices, bbox device. Also it is a preparation for
optimizing 'erasepage' for printer devices as for bug 690131.
When erasing a page, the old code passes fill_rectangle through
the device interface. However some devises need to recognize it
as a special high level operation and distinguish from an usual
rectangle filling. The old code implemented some trics for that.
This patch replaces the tricks with a strong logic for bbox device.
The pdfwrite device to be improved separately.
The old function gx_fillpage is now splitted into two parts,
one of which works before the device interface, and another one
after it. The second one looks as a default implementation
for the 'fillpage' device virtual method. Forwarding devices
implement new function gx_forward_fillpage.
EXPECTED DIFFERENCES :
None.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9288 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
PSSRC files are now in 'gs/psi'.
GLSRC files are now in 'gs/base'.
This is to facilitate build modularization and merging in the ghostpdl
tree.
NOTE: msvc32.mak is now in psi, not src.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9048 a1074d23-0009-0410-80fe-cf8c14f379e6
|
