| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There were actually 2 bugs in here. The first one was spotted and
fixed by James Cloos - many thanks; the arguments to memcpy were
reversed.
The second one was to do with the fact that postscript operation
now thinks it has 14 colors. When we encode/decode, we were packing
the colors into a word in such a way that we were losing the interesting
ones off the top. Reverse the order of packing, and all is well.
This still leaves an "interesting" fact about this device; we loop:
for (chan_idx = 0; chan_idx < num_comp; chan_idx++)
...
for (j = 0; j < xc->height; j++)
...
get_bits_rectangle
So, in the case where we have n components, and more than 1 band
we'll be rendering the entire file n times - despite the fact that
we request all the colors each time!
|
|
This causes a validation to be run after every operator is interpreted.
Also, update the chunk validation code to give more informative error
messages when problems are found. (For instance, if a reference is
found to be duff, it's often the source of that reference you are
interested in, not the reference itself).
|
|
Commit:
9f656faebac150c6aceca16c5ef6a78b92b6da43
exposed a problem with this code, when we are stripping /OtherSubrs from MM
fonts, the new CharString could be larger than the original (this can't
happen for non-MM fonts). Because we only allocated a buffer big enough to
hold the original (unstripped) data, we ended up with a buffer overflow.
The code now calls the 'strip' routine twice, the first time to calculate
how big a buffer will be required, the second time to actually do the work.
This will fix the crash in test-setweightvector.ps introduced by the
earlier commit
|
|
Bug #693059 "Asian fonts placed badly with pdfwrite output"
The problem here was caused by the way that pdf_process_string deals with 'widths'
when responding to a strginwidth operation versus a regular show.
When handling stringwidth the width of each glyph is added to the enumerator
'returned.total_width'. However, when handling a regular show, the width of
the glyphs are simply stored directly into 'returned.total_width'.
To handle the latter case the higher level code maintains its own total width
but that was getting confused when a stringwidth was used.
Ideally we would fix pdf_process_string to behave the same whether in response
to a stringwidht or a show, but that routine is called from other places and
making it coherent looks difficult. Instead we now process stringwidth
differently form show, and don't accuulate wodths when we have a steingwidth
operation in the higher level composite font code routines.
No differences expected
|
|
|
|
|
|
|
|
Time to render first 10 pages of pdf_reference17.pdf to tiff:
@200dpi = 5.2s
@600dpi downscaled by 3 = 7.2s (before this)
@600dpi downscaled by 3 = 6.5s (after this)
|
|
Update tiffsep to call the downscaler. This means adding MinFeatureSize
and DownScaleFactor to tiffsep. Also add BitsPerComponent to allow us to
specify 8 (default) or 1 (monochrome). MinFeatureSize is ignored except
in monochrome mode.
This has meant slight reworking of the downscaler to cope with planar
buffers, and its use of get_bits_rectangle rather than get_bits.
Also updated docs, and fixed some leaks on memory allocation failures
within tiffsep.
|
|
I seem to have overlooked these operations when writing the original code,
probably because I couldn't' find any test cases. However PCL seems to make
extensive use of them, and the lack of code causes access outside array
boundaries.
Fixed here in a simplistic fashion, which seems to work well.
No differences expected, txtwrite is not cluster tested
|
|
Disable checking for the max pdf object number during PDF linearisation,
because linearisation adds a few new objects to the PDF file.
|
|
|
|
|
|
We were giving up dashing as soon as we hit the first gap in a path.
Fix by treating gaps as an 'ink off' dash segment.
|
|
Also have a better stab at handling spot equivalent colors.
CLUSTER_UNTESTED.
|
|
Currently Memento undefines MEMENTO_LEAKONLY at the top of memento.c.
Change it here not to do that, so it can be supplied as part of a
CFLAGS or XCFLAGS line.
CLUSTER_UNTESTED.
|
|
When Ghostscript shuts down, it closes its malloc handler, which frees
all the outstanding blocks it knows about. This is unhelpful behaviour
when checking for leaks, so we disable this freeing in MEMENTO builds.
Also, the Ghostscript arg handling code is quite keen on 'arg_copy'ing
args only to pass them into routines that immediate copy them again
into heap allocated buffers. These copies are then allowed to leak.
Where it is obviously safe, avoid these copies. Where it's not so clear
free them (using a new arg_free function).
|
|
After reallocing a block, it is best to avoid reading from the old
location. (Read flags, then realloc, then write flags).
Also some minor tweaks to avoid warnings etc.
|
|
CLUSTER_UNTESTED
|
|
We had worked around the lack of a ghostpdl configure script by calling the
libtiff configure from the Makefile - which is a horrible hack.
Now that ghostpdl has a configure script, we can do the right thing, and call
the libtiff script from the ghostodl one.
No cluster differences.
|
|
No cluster differences.
|
|
|
|
|
|
pdfwrite maintains a 'font cache' of PDF font objects which are related to
GS fonts. Previously these were tracked by adding a pointer to the GS font,
and freeing the memory when the font was unloaded, by using the gs_notify_register
callback.
This causes problems when we are in 'file per page' mode. We want to discard
and rebuild the font cache at the end of each page, so we don't try to
reuse font objects. But if we discard the memory, the font is still pointing
at it. This causes later memory problems.
The simplest solution is to stop tracking the elements in the GS fonts. This
means that an element will persist and be stale after the font goes out of
scope, but its a fairly small amount of memory per font. We now clean up the
PDF font cache and all the elements in pdf_close along with all the other memory.
The 'file per page' mode using the '-sOutputFilename=%d.pdf' syntax now seems
to work correctly. There does not seem to be any great amount of memory leakage
now either.
The next step is to implement a 'server' mode application and use that to
check that there are no remaining memory leaks
No differences expected
|
|
Somehow when applying this part of the reverted patch, this line (the
one that actually prevented the access to freed memory) was missed.
|
|
The outline objects are released in write_outline, but the entries in the
device were not previously cleared leaving them pointing to freed memory.
|
|
Annotations weren't being freed along with their enclosing Page structure
Add some comments about what is stored where, and when it is released, in
a few places
|
|
The image data is already scaled as needed for the ICC code to handle directly.
Vector colors require the decode from real CIELAB values. This fix was missing
in the in image interpolation code. Fix for Bug 692885
|
|
Obtaining the profiles handles for all the default profiles in
the ICC manager eats up a tiny amount of time on startup. For
some customers that start and stop gs over and over instead of
running in server mode, this startup time is an issue. This
fix performs the initialization in a lazy manner, obtaining the
profile handle only when finally needed.
This commit also fixed some issues with images that are in the
LAB color space.
|
|
The original fix (fe8d7b6) for 692372 released the semaphores, but resulted
in memory leaks of many other parts of the imager state. The leak was fixed
by reverting the above change. This change insures that sempahores are not
leaked by adding 'finalization' to the icc_linkcache and icc_link structs.
|
|
|
|
icc structs."
This reverts commit fe8d7b6aebfed3c724a860e31ff170764d5429dc.
This commit resulted in a subsantial memory leak detected with PCL. See
bug 693001. The finalization should be for the icc structs that have
semaphores.
|
|
No cluster differences.
|
|
Previously the code to free font resources was using the wrong memory
allocator to free some objects, fixed here.
It also seems that, contrary to what I thought Function resources *are*
tracked by 'last_resource' in teh pdfwrite device structure. So its important
not to free those twice.
No differences expected
|
|
No cluster differences.
|
|
|
|
When serializing a MultipleMaster font, we were writing both a 'boiler plate'
$Blend procedure, and a broken $Blend from the font dictionary - broken because
the code to read the procedure from the dictionary ignored name objects.
In general, this was fine, as all the current FAPI scalers ignore the $Blend.
A problem arose because the code which calculated size of the procedure did
handle PS name objects, so we ended up with unitialized bytes trailing the
dictionary data, which could cause the scaler to error.
No cluster differences.
|
|
Several issues and quite a bit of confusion in the code with respect
to this option. I believe this should clear some things up.
Documentation still needs to be updated as to how this option functions
and what devices it actually works with. Note that
SeparationOrder and SeparationColorNames really only works for the
tiffsep device. The psdcmyk device was never really set up for use
with this option. Not sure if we want to add it. Also, I discovered
that with the disabling of compressed color encoding, the tiffsep1
device renders incorrectly. I had not converted this device to planar
as I had thought that it performed halftoning during rendering. I
did not realize it was rendering 8 bit data and then doing
a thresholding operation. We may want to just move this to a planar
based device. In that case, we could use the fast planar halftoning.
Note that with this fix, the device will only create output for the
colorants listed in /SeparationOrder. The psdcmyk device was not
making use of the /SeparationOrder information properly. It is now
which makes for some different renderings in the ps3cet/29-07*.ps test
files which exercise /SeparationOrder changes. In such a case, the
device will not output any missing colorants, which previously
it was doing.
|
|
Move the code to free font resources from the 'pdf close' into a separate
routine in the font handling module. Additionally call it for CIDFont
resoruces as well as Font resources (the code copes with freeing both)
No differences expected
|
|
Old code processed all patterns as tiled patterns and missed the
shading color space.
|
|
Mainly autoconf source files like configure.ac
No cluster differences.
|
|
First pass at cleaning up pdfwrite's memory 'management'.
Add clean up code in pdf_close for fonts, font descriptors, type 3 CharProc
and Pattern resources.
Since we only need the object number for a reference we now create a new
type of cos object 'reference'. This only contains the object ID so that
we cna write out the reference. We also set the ID to 0 after we write it
as this will allow us to free the object. (id == 0 is a crazy reference
counting thing, it seems)
Free the 'aside' associated with a pattern after releasing it.
free ExtGState resources at close.
There was no code to free CMaps, none at all. Added routines to free regular
CMaps and ToUnicode CMaps, and added code to pdfwrite to call these in order
to actually free CMap resources.
When manufacturing a BaseFont, if we already have a BaseFont name, dispose
of it before assigning a new one. Previously this leaked the string
containing the name.
release font resoruce objects
when freeing a font descriptor, free the object as well as the glyphs
Free copied base font FontName string on close
This is opaque data specific to each font type, so we may need to add
specific cleanup routines, but this is a start.
Secondly, when pdfwrite copeis a font it makes 2 copies, a subset and a
complete copy. However the complete copy can fail because of an unused
glyph. So we dicard the complete copy and carry on with the subset. In
this case we didnt' clean up the 'complete' copy.
Modified the previous code into one routine to free copied fonts, when we
discard a (complete) copied font during font copying free the font copy.
free Encoding from copied fonts if present
Also, change the text for font freeing so it makes sense.
Free copied font 'data' when freeing copied font
Free the 'base_font' structure when freeing FontDescriptors
release colour spaces.
Make a routine to free colour spaces, and have it free the 'serialized'
color space memory.
Free the page dictionary when we free pages.
We seem to have (at least) two different kinds of param lists which are used
to deal with getting/setting device params. The PostScript interpreter uses
'ref_params' and the PCL interpreter uses 'c_params'.
The problem is that 'ref_params_end_write_collection' frees the list memory
but 'c_params_end_write_collection' does not. Since these are accessed through
methods in the list, we don't know whether we need to free the memory or not.
This leads to a memory leak when using the PCL interpreter.
I suspect this is a bug in the implementation, but for now I've modified
'ref_params_end_write_collection' so that it nulls the pointer to the list
when it frees it. The code in gdevdsp.c can then test to see whether the
memory needs to be freed (non-NULL) or not.
For some reason this leads to a Seg Fault with fts_09_0923.pdf, but I
can't see why. I believe this is unrelated, so will investigate it further
after this work is completed.
Also changed a typecast to eliminate a warning
create a routine to clean up the 'text data' and call it. Add the
'standard fonts' to the clenaup in there.
Clean up a number of allocations (name index stack, namespace
stack etc).
Add code to free Funtiocn resource dictionaries, objects and resources,
These were missed previously, because the development was done in PCL and
teh PCL interpreter can't trigger the use of Functions.
Add code to clean up Shading and group dictionary resources. Add code to
clear the resource chains on close so that we don't end up trying to use
freed memory pointers.
|
|
If an unknown PDF operator has only [-.0-9], consider it a malformed
number and replace with 0.
|
|
|
|
SMask with GreyBackground != 1.0 needs to use parent bbox, but image
SMask only paint the image area so the BC cannot affect areas outside.
|
|
The shading code was using the number of components of the target device
in making a linearity determination. It should make use of the destination
ICC profile in that computation.
|
|
There are calls made during filling with this device to get the black point
of the device due to some ROP related call. The device did not have any
procedures for mapping colors or for decode and encode. Fix for Bug 692720.
|
|
The tiffsep and tiffsep1 devices both get closed and reopen when the separations
change (communicated by put_params). Previously this caused the output files to
be closed and reopened - not a problem when writing each page to its own set of
files, but when writing multipage tiffs, it resulted in all pages up to that
point to be overwritten.
We now have tiffsep and tiffsep1 handle their own file "management", and prevent
output files from being closed and reopened when the device is closed and
reopened due to a put_params call.
No cluster differences.
|
|
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.
|
|
Memento_breakOnFree(address) will cause a breakpoint when the block
including a given address is freed. If the block is realloced (and
hence moves elsewhere) the breakpoint is not triggered until the new
block is itself freed.
Memento_breakOnRealloc(address) will cause a breakpoint when the block
including a given address is freed or realloced.
|
