| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8945 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
Bug 689865 "clist stores redundant patterns".
The change is pretty simple because the clist reader already implememnts
a pattern cache. We just add pattern id to gx_clist_state
and provide a short format (just the id) when writing and reading
a pattern color to/from clist at second time. A new function gs_dc_get_pattern_id
allows to access the pattern id through closures of color elements.
Note it remembers up to 2 pattern ids for a band
(one for the specific band, and another for "all bands").
A better way would be to remember all patterns cached for a band,
but it would need to save all cached ids individually for each band while clist writing.
We don't want to enlarge the clist writer storage now.
Minor change : Some dependencies of gxclpath.c were missed in makefile.
EXPECTED DIFFERENCES :
None.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8940 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
Bug 689966 "c329.bin hang with bitcmyk in clist code".
1. The stroking algorithm includes a branch for a 'faster' rasterizing
with an idempotential color. That branch paints each stroke independently of others.
However that branch doesn't apply an optimization for big patterns,
which the general filling algorithm implements. It caused the too slow rendering,
because a clist-based pattern is played back for each parallelogram.
This change disables the 'faster' srtoking with big patterns,
so that the faster filling algorithm works fine for stroking.
2. Revert the revision 8851 change, which was a temporary workaround for the problem,
The default value for MAX_PATTERN_BITMAP_SIZE is now restored back to 1Mb.
EXPECTED DIFFERENCES :
None.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8930 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
performed in the source colorspace as opposed to the device space. Custom color callback is no longer bypassed by direct concretization as it was previously.
DETAILS:
Previous code would take device color 8 bit values and do the interpolation. That portion of the code is the same. For cases where we have nondevice color the handling is now different. Indexed colors are mapped to their base space and interpolated. This is followed by a remap operation. Device independent colors are interpolated followed by a remap operation.
Note that for cases where there is a significant enlargement occurring and we are not in a device color space, there can be a performance cost due to current inefficiencies in our color remapping operations. This can be costly if you have a CMYK CRD MLUT for example. There is currently a project underway to improve the efficiency of the color flow. For the current time, if this is an issue, improved speed can be achieved by invoking -dNOINTERPOLATION
EXPECTED DIFFERENCES:
148-11.PS
12-07B.PS
23-32.PS
13-03.PS
13-12.PS
The first two files have interpolation defined as on for some of their images. Hence there will be differences. With this change we more closely match the AR output for 12-07B.PS. 148-11.ps has only a minor difference in its coloring due to the interpolation in the different color space. The other files are nondeterministic.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8868 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
It was inadvertently removed in r8828.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8835 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
library so it is available to all languages.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8829 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8811 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
Bug 688845 "Segmentation Fault on EPS 2 PDF conversion", comment #38.
Adobe Illustrator creates a Postscript document,
in which an image data procedure executes 'save',
and the corresponding 'restore' appears after the image end.
DCue to that the image enumerator is freed at a higher save level than
it was allocated, so that gs_free_object works idle.
Nevertheless pointers must not in the structure,
because they may point to blocks already released
by the client's subclass method for end_image.
Leaving them uncleaned caused a real crash in the garbager - see bug 688845.
The patch defines the new function gs_image_free_enum,
which is intendend for a safe releasing of an image enumerator
from Postscript interpreter.
It cleans the entire subclassed enumerator,
including all possible pointers created by subclasses.
All end_image implementations,
which may be called from Postscript interpreter,
must call this function for releasing image enumerators.
The 'memory' pointer moved from subclasses to gx_image_enum_common.
We believe that in the old code all subclasses define and initialize it.
Working on this patch we suspected memory leaks
from image enumerators with some devices.
Particularly we suspect that subclasses if gx_device_vector
(pdfwrite, ps2write, etc.) never release image enumerators (not sure).
This patch does not do any attempt to re[pair such leaks,
because we want the new code doesn't
change the behavour too much in order to simplify the testing.
A work on leaks to be done separately.
EXPECTED DIFFERENCES :
None.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8803 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
profiles are used. Bug 689863.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8781 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
to fail because the locking memory code wasn't included. Currently PCL
builds still had the bmpa devices included, so they failed.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8724 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
branch into the trunk. The default behavior is still the same, i.e., the
clist rendering is done in the same thread as the parsing (main thread).
The 'gsmalloc' memory allocator now ALWAYS uses a mutex to lock accesses
in case it is used by a multi-threaded client. This was determined to
result is less than 1% performance hit on a single threaded client.
Refer to the log messages on the mtrender branch for details on the
design of the multi-threaded clist rendering, but the summary is that
-dNumRenderingThreads=# (default 0) determines the number of background
threads REQUESTED for rendering bands. If the platform doesn't support
threads, or if there is an error starting the threads from the clist_
get_bits_rectangle_mt hook, single threaded rendering will be used.
The number of threads may be less than the requested number if the
number of bands is less than the request, or if there is an error
setting up threads (as many as can be created, up to the request will
be used). The -Z: debug switch emits status messages indicating how
many threads are requested (-dNumRenderingThreads) and the number that
is actually used.
Many files show little if any improvement with multi-threaded clist
rendering since they are dominated by the clist writing time, or by
the time required to write the output. No files seen to date show a
performance hit greater than aobut 3%. Setting NumRenderingThreads
to a count higher than the number of CPU cores available does not
seem to help or hurt much, but there is overhead (per page) with
starting threads and allocating band buffers, so a very large count
is not productive.
The best performance seen on an Intel Core 2 Duo system, on a
particular file is about a 75% performance improvement (completing
the page in 57% of the single threaded time). This time did not
include writing a file (output to /dev/null).
In order to prevent memory mutex (locking) contention from slowing
down multi-threaded clist rendering, each thread uses a 'chunk'
wrapper on NON-GC the non-gc memory allocator. Each chunk allocator
is thread-safe/instantiated, so the locking only occurs on chunk
allocations to the wrapped (target) memory allocator.
The 'BAND_LIST_STORAGE=mmeory' option has been supplemented to allow
multiple concurrent threads to read the clist 'memfile'.
The "autoconf" files (configure.ac and Makefile.in) have been improved
to hook the 'posix' pthreads if available, so linux and Mac OS/X will
be able to support the multi-threaded clist rendering.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8721 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
in custom color callback. Also, made the object based coloring an option define and fixed minor header issues.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8679 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
bug was related to a CIELAB image with a colorspace ICC profile (LAB to LAB). The image data was incorrectly being normalized between 0 and 1 (float). It is now properly normalized to the range of the CIELAB ICC space. There still exists an issue with this file as absolute colorimetry should be used. This is the source of the current difference between AR and GS. However, the image is no longer black now but should match the GS result prior to rev 8664.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8677 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
conversion: ignore transfer functions for non-black components. Bug 688360.
DETAILS:
On this topic, section 7.3 of PRLM-3rd (page 494) says:
"Note: When the current color space is DeviceGray and the output device's
native color space is DeviceCMYK, the interpreter uses only the gray transfer
function. ... This special case exists for compatibility with existing
applications." There is a similar comment in section 6.3 of the PDF 1.6
spec. (page 456).
DIFFERENCES:
None
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8666 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
interpretation.
DETAILS :
This is a preparation for fixing
the bug 689440 "PostScript file generates infinitely large temp file".
The old code decomposes the imagemask into rectangles,
each of which decomposed the pattern color into a huge list of rectangles.
See more about the old code in Comment #11 of the bug 689440.
Now we delay the decomposition until the page clist playback.
This patch reduces the clist file size for the bug 689440
from 355GB to an acceptable size of 316Mb. A further shortening
is possible as explained in (5) below. But the rasterization time is still
unacceptably long - more than 48 hours. It will be improved
in a next step with converting imagemask with pattern color
into a painting of a pattern color with a mask clip device.
1. The old functions gx_dc_pattern_write, gx_dc_pattern_read actually
are generic functions for multiple color types,
which simply return an error. Renamed them into
gx_dc_cannot_write, gx_dc_cannot_read.
2. Implemented new gx_dc_pattern_write, gx_dc_pattern_read for clist-based patterns.
They copy pattern clist data to/from page clist. Currently this code
doesn't try to compress the data, but probably we'll need to do that.
3. Changed a condition in gxclimag.c to pass imagemask
with a clist-based pattern color to clist writer.
Also moved some checks to provide image matrix to be computed
when the new condition is true.
4. Added more functions into gxclist.c, gxclist.h for accessing
data of a clist-based pattern.
5. gx_dc_pattern_read now constructs pattern cache and stores the
clist-based pattern "tile" to it. The clist reader releases the cache before exiting a band.
We will need an optimization agains redundant writing of patterns into page clist.
This necessary optimization to be done in a next step.
6. Propagated error codes in gxclread.c, gdevfax.c for easier debugging.
7. Improved debug printing in gxp1fill.c to designate
recursive calls to clist interpreter when a clist-based pattern
in interpreted while a page clist playback.
8. Added new accessors into gxpcmap.c, which are needed
to access pattern cache while a page clist interpretation.
9. Updated dependencies in makefiles.
10. Fixed the dependenco of gxdcolor.c on gxdevcli_h, which was missed before this change.
11. Added the pattern color type into the list in gxdcolor.c,
because now we need to write it into clist. An old comment
reads that it was not included against unuseful reference to
pattern stuff in a Postscript Language Level 1 build.
The reference now appears, and this is unfortunate.
We think that level 1 builds are not important in nowadays.
On necessity it may be improved in a separate change.
EXPECTED DIFFERENCES :
None.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8655 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
Bug 689588 "Unexpected InternalOverflow in ReadImage".
When strip_copy_rop recieves a big tile, it is being subdivided into line tiles
to fit into the clist buffer. However the line tile can be too big as well.
The new code narrows the line tile with the size of the rectangle to be painted.
For details see comments added into gxclrect.c .
Minor change (gdevddrw.c, gdevmr8n.c) Added visual trace commands for easier debugging.
EXPECTED DIFFERENCES :
None.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8605 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
with this one, but we can't commit to both trees atomically.
DETAILS:
Tested with Windows and linux. Needs OS/2 testing. Other build systems
may have bit rotted, and I don't hav them to test. Some of the changes
here are to allow working with a PCL or XPS only build where the PS
interpreter is not used/needed.
I noticed that the default systemparam value for FontResourceDir isn't
getting et to %rom$Resource/Font/ as it should, but GenericResourceDir
_is_ being initialized correctly to %rom%Resource/ which is _NOT_
fixed by this commit.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8559 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
This is a preparation for fixing bug 689708 "Long processing time of PDF file"
The last patch appears incomplete due to a missed dependence in makefile.
Now we see the mask pointer was used but it was always NULL.
EXPECTED DIFFERENCES :
None.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8550 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
Move function used by both fd and stdio implementations to a separate file
and compile it in both versions. Bug 688918.
DETAILS:
Although the patch fixes link errors, pdfwrite and other devices,
use stdio functions directly and generate incorrect documents in fd version.
DIFFERENCES:
None in stdio version.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8542 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
Ghostscript Bug 687345 "Image interpolation problem at a band boundary"
Ghostscript Bug 689718 "Regression: differences in FIG3.eps".
1. siscale.c : The revision 8529 patch part 4 tried to represent 'ceil' with rational
arithmetics. But when downsampling the argument still uses a floating
number WidthIn, so we still need 'ceil'.
This patch converts the formula back to floats,
assuming that double precision is enough for precise result
because source image size usually is smaller than 2^24.
The wrong rational representation of 'ceil' caused an array element index
to fall outside the array. Debugged with FIG3.eps.
2. Improved debug printing and visual trace.
EXPECTED DIFFERENCES :
The patch fixes regression with FIG3.eps .
Also it causes minor raster differences with following files :
"148-11.ps"
"A-12-3480-0109-5.pdf"
"B-12-3077-1831-7-001.pdf"
"C-12-2706-0239-9-001.pdf"
"john_clippedimage.pdf"
"mspro.pdf"
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8539 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
Ghostscript Bug 687345 "Image interpolation problem at a band boundary"
This is a further improvement to image placement precision.
Debugged with a.pdf .
The old code provides insufficientg precision when computing
transformation matrix for an image. This computation
include matrix inversion and matrix miltiplication.
The old code uses floats and causes a visible shift of subimages with banding.
The new code uses double precision.
We didn't test how it relates to the revision 7026 change,
which dectreased the matrix precision for CPSI compatibility.
It should be a separate job.
In the new gsmatrix.c code we simply duplicate old code fragments
and replace types for double. We don't want to define a template
for now. Will see after the code passes enough practical work.
Besides that, in gxidata.c replaced fixed2int_pixround
with fixed2int_pixround_perfect. It is not related to a.pdf,
but we believe it is an useful change.
In gxipixel.c the patch replaces dda_advance with a repeated dda_next.
The old code appears implrecise due to loosing fraction pixels.
It eliminates a 1 pixel difference with Bug688789.pdf .
Minor changes : inserted debug printing and visual trace.
EXPECTED DIFFERENCES :
The patch eliminates banding/nobanding difference with :
a.pdf
"Altona.Page_3.2002-09-27.pdf"
"Altona_Technical_1v1_x3.pdf"
Bug688789.pdf
D-12-2025-9478-9.pdf,
Also it causes minor raster differences with following files :
"119-28.ps"
"468-01.ps"
"Bug687724.pdf"
"Bug688308.ps"
"FIG3.eps"
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8536 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
Ghostscript Bug 687345 "Image interpolation problem at a band boundary"
1. The macro fixed2int_pixround returns a mathematically incorrect
result with negative half-integer arguments.
For example fixed2int_pixround(-2.5) = -3 when the math gives -2.
We guess it was designed for positive page coordinates only,
but later it was applied to objects with negative coordinates.
Particularly, an image can start outside the page with a negative coordinate,
and fixed2int_pixround causes distorsions with banding.
We do not update fixed2int_pixround for backward compatibility
of other parts of the algorithm. Instead that the patch defines
a mew macro fixed2int_pixround_perfect, and applies it to
images with Interpolate=true. (gxfixed.h, gxipixel.c, gxiscale.c).
2. Added gx_image_enum_s::yi0 to provide entire image origion in the page.
This value does not depend on band size, so it gives more stability -
see below. (gximage.h).
3. Added entire image sizes to stream_image_scale_params_s
for source image and scaled image. These values do not depend on band size
and provide more stability - see how they are used in siscale.c.
(sisparam.h, gxiscale.c).
4. (siscale.c) calculate_contrib now computes the filter kernel center
with global (page) coordinates of the image, using the right macro
fixed2int_pixround_perfect and with the rational arithmetics
instead floats. It gives the kernel center position relatively to source image
with no dependence on the band size. Also improved the debug printing
about that.
5. In siscale.c we keep track of some experiments done while
developing the patch. We need to save them to history because they're not trivial.
See comments in code. We'll remove them from trunk with a separate patch.
EXPECTED DIFFERENCES :
The patch eliminates banding/nobanding difference with :
148-11.ps
A-12-3480-0109-5.pdf
B-12-3077-1831-7-001.pdf
C-12-2706-0239-9-001.pdf
Note it changes both banded and unbanded rasters.
Unexpectedly it causaes a 1 pixel difference with
D-12-2025-9478-9.pdf,
which looks minor but needs a further investigations.
Minor differences (a small shift of an image due to better scale precision)
happen due to better image precision :
"Bug687660a.ps"
"D-12-2025-9478-9.pdf"
"E-12-1866-0406-7.pdf"
"FIG3.eps"
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8529 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
git-svn-id: http://svn.ghostscript.com/ghostscript/branches/mtrender@8525 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
Ghostscript Bug 687345 "Image interpolation problem at a band boundary"
This is another partial fix for the bug 687345 for portrait images with Interpolate=true.
Debugged with CET 148-13.
1. The old code inprecisely computes the scaling factor
when interpolating images with Mitchel filter.
The computation was done with the subimage rectangle,
which is different for different bands.
The new code always computes the scale from the entire image rectangle,
which's size is same for all bands.
2. New fields are inserted into gx_image_enum_s and stream_image_scale_params_s
to provide data delivery for (1).
3. In calculate_contrib in siscale.c the variable input_index
is renamed into starting_output_index for a better reflection of its semantics.
4. In calculate_contrib in siscale.c the new variable dst_offset_fraction
is added for a preciser positioning of the filter center,
when it fails between device pixel rows. The old code missed fractional
pixels when stepping to a next band. The expression for its value
was created empirically, so it may need further improvements.
5. Inserted visual trace instructions for easier debugging.
6. Improved the debug trace printing.
EXPECTED DIFFERENCES :
The patch eliminates banding/nobanding difference with C-12-2706-0239-9-001.pdf,
and with the box 148-13 in 148-1.ps .
Minor differences (a small shift of an image due to better scale precision) :
"148-11.ps"
"289-01.ps"
"A-12-3480-0109-5.pdf"
"B-12-3077-1831-7-001.pdf"
"C-12-2706-0239-9-001.pdf"
"D-12-2025-9478-9.pdf"
"E-12-1866-0406-7.pdf"
"FIG3.eps"
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8522 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
library. Bug 689688.
Details:
Previously, the core graphics library defaulted to including the
'no12bit' and 'no16bit' modules, which contained stubs. These modules
were replaced by full implementations when the psl2lib (12 bit) and
pdfread (16 bit) modules were included.
We now consider this build-time flexibility redundant. The extra code is
not large and the default build generally includes it as these images
are part of all the newer page description languages. We therefore
include the unpack routines directly in libcore and remove the
noi1xbit modules entirely.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8519 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
Ghostscript Bug 687345 "Image interpolation problem at a band boundary"
This is a partial fix for the bug 687345 for images with Interpolate=false.
Actually it is related to scaling raher than interpolation.
1. gx_image_enum_begin performed inaccurate coordinate computations,
which caused a different image bias for different bands
due to a wrong coordinate rounding.
The patch replaces it with a better code,
which provides same bias for all bands and for unbanded rendering.
But we're not sure that image placement is now perfect,
because the initial rounding looks strange.
We keep the initial rounding to be compatible with the old code
to minimize raster differences and easier visual analyzis.
For a while we keep the old code in #if 0 because
it may be useful for next patch.
2. image_render_frac contains optimized branches for the case when
image's axes are parallel to page's axes.
Those optimized branches convert parallelograms into rectangles,
except for the last parallelogramm in the chunk.
It caused the last parallelogram to shift in 1 pixel relatively
to the rectangles. This patch adds the optimized branch
for the last parallelogram, so that all image parts
are now placed with same rounding. It avoids rendering artifacts
with 148-05.ps and many other tests. Note that the patch does not fix
the rectangle shift from parallelograms,
so probably it still contain another bug,
which may need a separate fix.
3. While working on this patch we noted that update_strip
doesn't correctly preserve the fractional part for
dda.strip and dda.pixel . We include a track of that experiment
in the new code in #if 0 section for further development.
See comment in code.
4. Inserted visual trace commands for easier debugging.
EXPECTED DIFFERENCES :
This patch avoids difference between banded (MaxBitmap=100000)
and unbanded (MaxBitmap=100000000) rendering at 300 dpi for the following files :
035-01.ps
148-11.ps
148-16.ps
1_2001.pdf
455690.pdf
adesso4.pdf
Altona-Testsuite_p2_S_x3.pdf
Altona_Visual_bb_1v1_x3.pdf
Altona_Visual_sb_1v1_x3.pdf
bc_02a01_cal.pdf
BEST8-99-Path.fh7.pdf
Bug687724.pdf
Bug687832.pdf
Bug688308.ps
Bug688822.eps
dave.pdf
eric.pdf
file2.pdf
foo.pdf
H00216q.pdf
map.pdf
messenger.pdf
messenger16.pdf
ngnews1.pdf
Original.pdf
PixelisAd.pdf
ridt91.eps
S2_Digitalproof-Forum_x3k.pdf
SmoothShading.pdf
t1.pdf
time1.pdf
Also it causes minor differences for the following files :
"119-47.ps"
"468-01.ps"
"688645.jbig2.pdf"
"a.pdf"
"acrobat.pdf"
"ai2.pdf"
"Altona.Page_3.2002-09-27.pdf"
"Altona_Technical_1v1_x3.pdf"
"Bug687207.ps"
"Bug687840.pdf"
"Bug687889.pdf"
"Bug688308.ps"
"Bug688467.ps"
"Bug688639.ps"
"Bug689189.pdf"
"Bug689492.pdf"
"C-12-2706-0239-9-001.pdf"
"chstudy.pdf"
"D-12-2025-9478-9.pdf"
"dina4_tiffg4.pdf"
"Es001-01.pdf"
"jpx-file2.pdf"
"jpx-file3.pdf"
"jpx-flowcontrols.pdf"
"jpx-johnny1.pdf"
"little.guy.pdf"
"new_rect_nr.pdf"
"Openhuis_pdf_zw.pdf"
"sports.pdf"
"Svd.pdf"
"test.pdf"
Please note that the patch changes both banded and unbanded rendering.
In most cases the difference is a 1 pixel shift of
an image or a shift of an intersection of an image with a band.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8517 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
Bug 689660 "memory deallication problems with shadings".
The old code used pdev->memory for temporary storing
an intersection of clipping path with shading bbox.
This is the global memory space.
However if the intersection is trivial,
the path of the clipping path is copied from the
original clipping path, which is allocated in the local memory space.
Later it causes a freeing of path segments to a wrong memory space.
This patch chooses the original clipping path's memory space
when the clipping path is available, and the global space otherwise.
EXPECTED DIFFERENCES :
None.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8498 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8488 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
This really skips compositors which don't paint anything.
Compositor parameter list structures are extended with a new boolean field 'idle'.
These fields pass information whether something was painted to a compositor.
We choosen this way for passing this info because
(1) we can't change the device inteface with new function arguments, and
(2) we need to pass it through the device chain
(for example, when a clipper is installed onth the overprint device).
This patch only affects the transparency and the overprint.
Other compositors (gsalphac.c, gxropc.c) behave as before.
They may need further improvements.
This patch does not fix the bug 689492.
That fix may be done either before or after this one,
but in any case the patches need to adopt each to another.
The new compositor virtual method is_closing
checks whether a current compositor command
closes an older command, and finds the opening command.
Now we provide untrivial implementations for transparency and overprint compositors.
Would like to define an enum for return values of is_closing.
The old device method create_compositor now passes the 'idle' parameter via
gs_composite_s structure. By default it is false and the behaviour
is same as before. But the clist interpreter is modified
to provide true value when a compositor doesn't paint anything.
To compute this flag the compositor queue now works with its full power.
Note we changed the queue representation with a bilikned list.
This patch entroduces the concept of 'friendly operations'
for compositor operations. These are those operations, which
may interchange with compositor installation/deinstallation.
One example is halftone operations, which always affect
the device below the compositor device, i.e. the target device
of the compositor device. The new compositor virtual method
is_friendly is implemented in an intrivial way for the
transparency compositor especially to exchange with halftone
operations while queueing clist operations.
This especially helps to delay the pdf14 device installation
so that it may completely annihilate with its deinstallation
if nothing is painted through the compositor in a band.
Overprint and transparency compositor implementations
are changed with checking the idle flag.
If it is set, they don't perform neither color blending, nor
raster buffer allocation. Note the pdf14 device maintains the buffer stack
as before, but the allocation of buffers may be skipped.
It saves significant time from cleaning up raster buffers when they are idle.
This patch may need further improvements for the case when
different compositor types are mixed in one queue.
We could not fully test it due to absence of practical tests.
Another useful improvement would be to convert
"0 .inittransparencymask 1 .inittransparencymask dict .setblendparams"
into a single command. It would simplify the compositor queue logic.
Also we think that the name .inittransparencymask doesn't reflect the function purpose.
Will improve someday.
We're not sure whether this patch correctly works with idle masks.
We could not debug it due to no practical cases.
Possibly idle mask will need an additional effort to skip
the group painting to the band.
Also disabled cmd_put_halftone in c_pdf14trans_clist_write_update -
see comment in code.
Monor change : Inserted a visual trace support for transparency buffers.
EXPECTED DIFFERENCES :
None.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8484 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8479 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8477 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
Details:
It was originally added to support vga mode setting, and has been
used for a few minor optimizations since. We don't believe these
are worth the trouble with modern compilers, so it is removed to
simplify configuration management.
Expected Differences:
None.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8468 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
consistently defined.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8461 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8459 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS:
This was an attempt to implement PCL raster operations as an interposed
device which first rendered to an intermediate buffer and them
composited with the underlying device buffer, similar to how the
"PDF 1.4 Transparency" device works.
While this would be a nice approach, allowing raster operations to
function in more color spaces, it was never completed, and presents
a maintenance burden for ongoing clist improvements. We are therefore
removing it. It can be reinstated later as a starting point for further
development if needed.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8447 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
The clist writer writes the 'create compositor' operation to all bands,
including ones that are not covered by a transparency.
It does so because this operation changes the number of color components.
When rendering a specific band, it frequently happens that a compositor
is created and then immediately destroyed. Such thing happens outside
the transparency bbox, and within the transparency bbox if
the band has no transparent objects. When compositor is created,
it allocates a big raster buffer and cleans it.
Due to that we observe a significant CPU time expence
when running the test case of the bug 689155.
This patch is a preparation for further improvements.
This patch includes CTM into pdf14 compositor params
(see changes to c_pdf14trans_read, c_pdf14trans_write, clist_create_compositor).
The result should be same as the old code, but the algorithm is different.
The old code wrote CTM as a separate command before cmd_opv_ext_create_compositor.
The new code does not, and in many cases compositor commads
immediately follow each another.
The last fact changes the behavior of the compositor queue :
before this patch it consisted of 1 element maximum,
but after it the queue becomes longer (up to 10 elements
with SoftMaskGroup.pdf). A bug is fixed in the queue logic
in gxclrast.c ln 1355.
The queue is still immediately executed
when a non-compositor command appears in the input stream.
An annihilation of neighbour idle compositors will be a next step.
Minor changes:
- added a new method adjust_ctm to gs_composite_type_procs_t.
- added type checks with composite_*_proc macros to all compositor types.
- dependencies were broken for gdevp14.c in lib.mak .
EXPECTED DIFFERENCES :
None.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8426 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
typo that caused CMap files to be missing.
DETAILS:
This method of putting the gs_init.ps dependency down in lib.mak require
us to get gs_init.ps. This hack was discussed with Ralph and is an
alternative to adding a dependency to all of the top level makefiles.
The dummy gs_init.ps is only made when we are NOT including the PS
interpreter (PSI_INCLUDED) since we need the real one for the language
switch build. Note that the dummy file doesn't get added to the %rom%
file system since PS_ROMFS_ARGS is empty if int.mak is not included.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8374 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
without PS (PCL
only build). Make sure gs/src/ugcclib.mak does conditional assignment of COMPILE_INITS
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8367 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
build, which does not define CC_SHARED.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8270 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
Also, use the GS_INIT define instead of hard-coding gs_init.ps
as the root of the postscript library code.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8257 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
high level objcts.
DETAILS :
Bug 689186 "PDF segfaults or exits with no output".
With the test case the old code creates a 2.5Gb clist file,
because it transformes transparent paths and images into rectangles.
The new code writes them as high level objects,
so that the clist file reduces to 477Mb.
1. (gdevp14.c) The old code appears to provide all necessary
methods for writing paths and images to clist as high level objects,
but doesn't call them. To activate them we simply replace default implementations
with forwarding methods in pdf14_clist_*_device.
2. (gdevp14.c) The old code sets the lop_pdf14 flag to
the clist reader's imager state. Particularly
it may be set when calling p14dev->pdf14_procs->put_image.
It causes gx_image_enum_begin to fail,
and the image silently dissappers from the output.
We fixed it with resetting the flag immediately before
calling p14dev->pdf14_procs->put_image.
A better way would be to synchronize log_op
in clist_create_compositor, but we don't like to
write it to all bands as other compoitor commands do.
3. (gdevp14.h, gdevp14.c) New fields inserted into pdf14_device_t
to provide a synchronization of encode_color, decode_color, get_color_mapping_procs,
get_color_comp_index with changing color_info. Debugged with pkmraw -r300 Bug688631.pdf .
Without them the 1bpc color conversions
were called from pdf14_cmap_cmyk_direct with an 8bpc color,
causing an almost white page instead blue axial and radial shadings.
4. (gdevm4.c) The old code defines a wrong color_info for mem_mapped4_device.
It defines 3 components instead the correct value 4 (3 colored and 1 gray).
5. (gdevp14.c) During the clist playback the new code does not change color_info
for the clist writer (p14dev->target->color_info). We marked this change
with the comment :
/* Disabled because *p14dev has no forwarding methods during the clist playback. */
We ise #if 0 because we're not sure why the old code does so.
We suspect it was done by a mistake and has no any effect.
#if 0 will keep it for a while.
More possible optimization :
1. Use pdf14_buf::bbox when back dropping a transparency buffer.
2. Use pdf14_buf::rect to restrict bands which set up the transparency compositor.
Now it is written to all bands.
3. Write text to clist as high level object.
EXPECTED DIFFERENCES :
Note: We're unable to perform a full test of this patch locally
because it affects too many devices. We commit it after a partial
testing with most significant cases. We hope the cluster regression test run
will discover provlems if any.
A banded rendering causes minor raster differences with transparency :
ai2.pdf
Bug688631.pdf
dina3_watermark.pdf
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8170 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
linear color triangles (continued 8).
DETAILS :
This fixes (some) gcc warnings in the recently added code (part 2).
EXPECTED DIFFERENCES :
None.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8134 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
linear color triangles (continued 6).
DETAILS :
This is an initial commit for decomposition of linear color triangles
that the target device can't handle while a clist playback.
The new code is not called with practical cases
because currently we have no devices
with an intrivial implementation of fill_linear_color_triangle.
We commit this code for future if someone will want
to implement that function in hardware with a smaller number of bits.
To force an execution of the new code
one can change this switch in gxclrast.c :
if 1 /* Disable to debug gx_fill_triangle_small. */
We debugged the new code with setting this switch to 0.
In this case the decomposition code starts, and calls
fill_linear_color_triangle again with same arguments
(except converting frac31 colors to 'float',
rather it doesn't miss precision with comparefiles).
This test works fine with comparefiles.
If the device method would request a further decomposition,
an earlier debugged code works, so we didn't test it now
(Testing it with available implementations would require an additional effort
for rejecting regular triangles by the target device).
For more details see comments in code.
Note the clist playback now calls gxshade6.c .
EXPECTED DIFFERENCES :
None.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8132 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
and linear color triangles.
DETAILS :
This fixes the clist expansion problem for shadings.
1. New functions clist_fill_linear_color_trapezoid, clist_fill_linear_color_triangle
provide the writing of shading parts into clist
without a further decomposition into rectangles.
2. gxclrast.c is enhanced with reading the data from 1.
3. gxfill.c needs a special interaction with the clipper device
for passing the clipping path as a high level object.
The new request pattern_manage__handles_clip_path
checks whether the target device can handle a clipping path.
The clist writer can, so the graphics library first sends the
clipping path, and then decomposes the shading into
trapezoids without installing a clipper device.
Doing so because clipper device can't handle trapezoids.
See comments in gxclpath.c, gxfill.c .
4. The clist reader installs a clipper device when processes
trapezoids and linear color triangles.
The new flag clipper_dev_open controls that.
5. A new flag gx_device_clist_writer_s::cropping_by_path
controls an additional cropping of shading components,
which fall outside the shading path's bands.
See comment in gxclpath.c .
6. R_fill_rect_with_const_color is rewritten with linear color functions,
because the old implementation creates a rectangle, which is not clipped with
4,5. It gives an invisible slowdown for unbanded rasters.
There are few things, which need further improvements :
1. A better compression for frac31 values in clist.
Such values usually have many zeros in ending bits.
2. Crop bands with ybot, ytop, fa->ystart, fa->yend in
clist_write_fill_trapezoid.
3. The clist reader must handle cases when linear color functions return 0.
It must perform a decomposition of areas with calling
appropriate parts of gxshade6.c . The current code returns error,
which does not happen in practice.
EXPECTED DIFFERENCES :
There is a problem with pkmraw -r300 Bug689189.pdf
which has to be fixed separately.
This patch causes a minor raster difference with shadings :
with a banded rendering the shading area becomes some smaller
than the old banded rendering. It needs a further analyzis.
Here is a list of files with this problem :
"442-01.ps"
"446-01-fixed.ps"
"464-01-fixed.ps"
"470-01.ps"
"478-01.ps"
"483-01.ps"
"483-05-fixed.ps"
"Altona-Testsuite_p2_S_x3.pdf"
"Altona_Visual_bb_1v1_x3.pdf"
"Altona_Visual_sb_1v1_x3.pdf"
"BEST8-99-Path.fh7.pdf"
"Bug689189.pdf"
"chilis_black.pdf"
"chilis_red.pdf"
"Clarke Tate Manns Chinese.ai"
"gradmesh.ai"
"Openhuis_pdf_zw.pdf"
"S2_Digitalproof-Forum_x3k.pdf"
"self-intersect2.ps"
"shading_prob_800.ps"
"SmoothShading.pdf"
"STEUER-RollingMesh 1(linear).ai"
"STEUER-RollingMesh 2(radial).ai"
"STEUER-RollingMesh 3(Final).ai"
"Testform.v1.0.2.pdf"
This list may be related to bug 689338.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8118 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
Patch from Henry Stiles, needed for the gslt build.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8049 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8029 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
"gs-esp-gpl-merger")
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8026 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
to Artifex Software, Inc.
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8022 a1074d23-0009-0410-80fe-cf8c14f379e6
|
|
DETAILS :
This partially improves performance for the test case of
the bug 689189 "PDF fails with /unregistered in --shfill--".
While filling a shading, the old code
converts the clipping path into a path, then
converts it to a clipping path for intersecting it
with the filling path and with the shading BBox.
These manipulations are neccessary due to the
interface restrictions for gs_shading_fill_path,
which doesn't pass a clipping path.
It causes (1) a bad performance and (2)
a wrong fill adjustment, because the conversion
of a path to a clipping path and back to path
is not identity due to fill adjustment.
The new code is a 1st step for the elimination of gs_shading_fill_path.
This patch excludes this function for raster devices.
Excluding it for higth level devices will be a next step.
The new code moves path manipulation outside the
shading color painting. Now all 3 pathes
(the filling path, the clipping patrh, and the shading BBox)
are processed in gxfill.c . The painting
is done with gs_shading_do_fill_rectangle,
which does not manipulate with pathes.
The patch modifies gx_image_fill_masked_end
to comply with the new inplementation of
gs_shading_do_fill_rectangle when a mask
is converted into a clipping path.
Another optimization avoids the generation
of a filling path for 'shfill'.
Accorgong to PLRM, shfill deals with clipping path,
but it was converted into a path due to
internal Ghostscript constraint for the device interface.
When the device implements fill_path with
the default method gx_default_fill_path,
the conversion to a path is not necessary.
To make use of this fact for optimization, the graphics library
needs to know, whether the output device uses the default
function gx_default_fill_path. This patch introduces a new response
for pattern_manage, which is named 'pattern_manage__shfill_doesnt_need_path'.
The device must respond with 1 if it does not need a path.
The patch provides implementations for raster devices and
for forwarding devices. If some device provides an instandard
fill_path method, the optimization won't work for it
(i.e. it will work as before - will recieve a path for shfill)
unless it provides a proper response to pattern_manage__shfill_doesnt_need_path .
A minor change to gdevpdfb.c fixes a paranoid compiler warning
about a possible use of unubnitialized data.
EXPECTED DIFFERENCES :
The old code erroneusely applied fill adjustment two times
when filling a path with a shading color.
Also fill adjustment was erroneusely applied when
painting a characxter with a shading color.
With new code shadings paint fewer pixels at a shading boundary,
causing a minor difference in rasters :
72dpi :
"442-01.ps"
"446-01-fixed.ps"
"470-01.ps"
"Bug687546.ps"
"Bug689189.pdf"
"chilis_black.pdf"
"chilis_red.pdf"
"Clarke Tate Manns Chinese.ai"
"gradmesh.ai"
"muur.eps"
"S2_Digitalproof-Forum_x3k.pdf"
"shading_prob_800.ps"
"SmoothShading.pdf"
"Testform.v1.0.2.pdf"
300dpi :
"470-01.ps"
"Bug687546.ps"
"Bug689189.pdf"
"chilis_black.pdf"
"chilis_red.pdf"
"Clarke Tate Manns Chinese.ai"
"muur.eps"
"S2_Digitalproof-Forum_x3k.pdf"
"SmoothShading.pdf"
git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8017 a1074d23-0009-0410-80fe-cf8c14f379e6
|
