pdfwrite - address memory leaks

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.

0 files changed, 0 insertions, 0 deletions