From 4def00dfd482e7e45679e5fd44fea0a9863d98ab Mon Sep 17 00:00:00 2001 From: Igor Melichev Date: Tue, 5 Apr 2005 09:48:46 +0000 Subject: pdfwrite : Implementing a viewer's resource memory control, part 1. DETAILS : This patch implements a primitive viewer's resource memory control. A new device parameter MaxViewerMemorySize specifies the number of bytes available for storing resources in the viewer's memory. This parameter defined almost for future extensions. Currently we distinguish two cases only : if the parameter is greater than 10000000 bytes, no resource control is being applied, i.e. pdfwrite assumes that the viewer can store all resources of entire document. Othervise pdfwrite assumes that the viewer can store resources of a single page. In the second case pdfwrite cleans internal resource caches after each page, so that any new resource usage will generate another resource instance in the output PDF file. To inform the viewer that the resources may be cleaned, we add a new key to a page contents stream dictionary. This is our extension to the PDF specification in order to control the resource management in the viewer. The new key name is /.CleanResources. Currently we provide only the value /All. It means that resources may be cleaned *after* ending the contents stream. In future on necessity we can split a page contents stream into substreams and provide a finer control by resource types with providing more values for the key /.CleanResources. When the viewer is informed with allowing to clean resources, it is not obliged to do so. Further resource appearences simply replace old ones, if they have same resource name. Actually now this happens only with font and CID font resources. Other resource instances may persist in the viewer's memory until the viewer's garbager frees them when they are not referred from resource tree dictionaries. The resource control is mainly intended for ps2write. An implementation of the viewer's side (in opdfread.ps) will be a separate patch. Note that when a resource control is being applied, the output document size may increase significantly. Currently we don't add MaxViewerMemorySize to user's documentation, because it depends on another undocumenmted parameter ForOPDFRead through the ResourcesBeforeUsage flag. First we need to take a decision whether ps2write will become a new Ghostscript device or it stays a tool represented with a script. The latter gives more flexibility to users about composing the header procsets of the generated Postscript document. EXPECTED DIFFERENCES : None. git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@5826 a1074d23-0009-0410-80fe-cf8c14f379e6 --- gs/src/gdevpdfx.h | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'gs/src/gdevpdfx.h') diff --git a/gs/src/gdevpdfx.h b/gs/src/gdevpdfx.h index e02f5a871..61807c8c7 100644 --- a/gs/src/gdevpdfx.h +++ b/gs/src/gdevpdfx.h @@ -421,6 +421,7 @@ struct gx_device_pdf_s { with pattern color. */ long MaxClipPathSize; /* The maximal number of elements of a clipping path that the target viewer|printer can handle. */ + long MaxViewerMemorySize; long MaxShadingBitmapSize; /* The maximal number of bytes in a bitmap representation of a shading. (Bigger shadings to be downsampled). */ @@ -810,6 +811,10 @@ void pdf_reverse_resource_chain(gx_device_pdf *pdev, pdf_resource_type_t rtype); */ int pdf_free_resource_objects(gx_device_pdf *pdev, pdf_resource_type_t rtype); +/* Write and free all resource objects. */ + +int pdf_write_and_free_all_resource_objects(gx_device_pdf *pdev); + /* * Store the resource sets for a content stream (page or XObject). * Sets page->{procsets, resource_ids[], fonts_id}. -- cgit v1.2.1