| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This change in these devices was made to remove the 64 bit limitation of
our existing color encoding which limits us to 8 colorants without
compressed color encoding. The motivation for this work is that even
with compressed color encoding we were starting
to encounter files with transparency in particular that exceeded the
capabilities of encoding, leading to dropped colors. With this fix, we
encode through the clist the DeviceN color values. The buffers for the
devices are maintained as planar buffers and fills occur with the high level
device colors.
Support was added to handle the devn color type through the shading code. The old
code would have supported only 8 colorants in a shading.
Support was also added to the transparency code to enable the use of the put_image
procedure which for the planar device saves quite a bit of time since we can do the
copy_planes proc directly from the pdf14 planar buffer to the planar memory device buffer.
The pdf14 device also had to support fill_rectangle_hl_color.
Changes were also made to the pattern tiling code so that we avoid any planar to chunky and
back to planar conversions. These were being done to handle ROPs. Even when there were
not any ROPs to perform we were going through strip_tile_rop operations since the
gx_default_strip_tile_rectangle did not support planar to planar. That support is added
with this commit.
Support had to be added to the overprint compositor to support the new color type with
fill_rectangle_hl_color.
Support had to be added to the clist for fill_rectangle_hl_color. This required changes
on both the writing and reading side. It is possible that the amount of data written
for these commands could be reduced and that is commented in the code.
Support also had to be added to the clip device and the mask_clip device as well
for uncolored patterns. Also the tile clip device required support and the transparency device
required support for copy_planes. This last function needs to be optimized.
Both of the separation devices (tiffsep and psdcmyk) that we currently have are updated to
support this method. There is an #if option in each device file to return the
code back to the old chunky format.
A new device procedure for handling strip tiling of masks with devn colors had
to be added. Functionality was only required for the mem planar and clist devices.
Also, it was found that the tiffsep and psdcmyk devices were maintaining separations
(spot colors) across pages. That is if page 1 had a spot color, subsequent pages
created a separation for that spot
even if those pages did not contain it. This was fixed so that separations for a page
are only created for the spots that occur on that page.
A fix was also made to ensure that we had proper handling for the None colorants when
they are part of the DeviceN color space.
|
|
Actually two problems showed up after the previous commit related to this bug. A crash
could occur (or cause "Object not in any chunk") because the pdf14 device did not use
stable_memory for separation names. The second issue was a VMerror when the decision
for banded (clist) mode was flawed, because if the device supported separations the
estimates for transparency buffers was too small because the call to
gdev_prn_allocate_memory was sometimes called with new_width, hew_height = 0,0 which
expected the 0,0 to be ignored. The new_width and new_height are only used from
gdev_prn_reallocate_memory.
The non-encodable pixel issue still remains.
|
|
The relocation code for memory devices had not been updated to cope
with planar stuff; as such only the first 'mdev->height' line pointers
were being updated. This was showing up in plank vs pamcmyk4 testing
as some planes of patterns being corrupted.
|
|
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.
|
|
are obsolete.
The encode_color proc replaced this and devices may not have it set to a valid proc.
Detected under certain circumstances with the tiffsep device using compressed color
encoding.
|
|
Add new 'plan' family of planar devices.
Equivalent to the plib devices, but without the necessity to always band,
and not using the band donor.
From the end users point of view, these output ppm etc and are probably
therefore not that useful as is. They serve the twin purposes of allowing
us to test planar output, and to act as a basis for devices that need
planar non-interlaced output.
The development of these devices showed a problem with
gx_get_bits_return_pointer in the planar case. When called, it would
assume that the start of the first line of the first plane was at
'base', and that subsequent planes could be reached by adding
raster * height to it. Unfortunately, clist_rasterize_lines resets the
buffer device at the end, so that height is unrelated (often 1).
The fix implemented here is to change gx_get_bits_return_pointer to take
a pointer to the line pointers, rather than a direct base value. This
means we can always find the subsequent planes correctly.
In my initial attempt at this, I broke the code by failing to notice that
gdevmem.c passes the same base pointer to gx_get_bits_copy. Fixed here.
Cluster testing shows it be OK this time around.
|
|
The previous commit caused large numbers of changes. Back it out while
I investigate why.
|
|
Equivalent to the plib devices, but without the necessity to always band,
and not using the band donor.
From the end users point of view, these output ppm etc and are probably
therefore not that useful as is. They serve the twin purposes of allowing
us to test planar output, and to act as a basis for devices that need
planar non-interlaced output.
|
|
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.
|
|
|
|
AND the clist. An issue was that the pdf14 encode and decode procedures are used as opposed to the target device encode and decode procedures and it is through a value in the color index that we currently communicate the object type through the clist. When we are in page rendering mode, it is easy to get the current object from mem->gs_lib_ctx->BITTAG, but this is not set correctly in clist rendering if for example a glyph is stored in the clist as a mask fill. Instead the information about the object is extracted from the color index. So, to make this work, we had to introduce an encode method for the pdf14 device that incorporates the tag information and also make sure that the bit depth for the pdf14 color info value is incremented appropriately so that the extra byte is stored and extracted from the clist. The object type is then recovered during the pdf14 mark fill rect procedure. This was tested with the updated bitrgbtags device using a custom file that has overlapping text, image and path objects with varying transparency amounts.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@11739 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
|
|
(gs_make_mem_device_with_copydevice) to replace gs_make_mem_device and
fixes several device reference counting problems (leaks) which
affected all the the client languages. No expected visual
differences.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9968 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9965 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
palette should not rely on color_info.polarity, but instead needs to
be determined from the value of color black. Inverted if black is not
0. Bug 690314 for customer #661.
DETAILS:
In page buffer mode, the 'palette' was set up during the first ht painting
operation from gdevmr1.c. This code was only used in clist mode when making
the 'buffer device' for the band.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@9621 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
|
