| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
| |
Ghostscript reapplication of the fix for bug 706497.
Thanks to Chamal Desilva for the report!
|
| |
|
|
|
| |
The actual file supplied gets caught earlier by other checks, but just adding
this for one more level of security.
|
| | |
|
| | |
|
| |
|
|
| |
Ensure we don't access beyond the font->data size
|
| |
|
|
|
| |
Avoid overrun of fixed sized array by doing dynamic
allocation and reallocating when needed.
|
| |
|
|
|
| |
No actual SmartOffice code here, just the framework for adding
the (private) "SO" interpreter.
|
| |
|
|
|
|
| |
Added check to an offset while reading the index header in
xps_count_cff_index. If the offset was read as negative, the function
will return a pointer outside the range of the buffer.
|
| |
|
|
|
|
| |
Fixed and issue in xps_init_postscript_font where a font table would
be outside the range of the buffer as well as no integer overflow
occurs when computing the size of the table.
|
| |
|
|
|
|
| |
Previous fix in commit 7642e51271eafd012a80722b5f82226188de90a2
did not correctly fix the issue. Integer overflow is now checked
which was allowing the issue to persist.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Supports out-of-order ranges (if the parser allows it and disables the
PageHandler, i.e., flp device). Also adds support for ranges appended
to the "even" and "odd" keyword following a ":".
As before a trailing "-" in a range implies the last page, and as was
supported by the previous 'gxps' code, a leading "-" also is the last page.
For example, with XPS or PDF: -sPageList=odd:3-7,even:4-8,1-,-1,9
prints pages: 3, 5, 7, 4, 6, 8, 1, 2, ..., last, last, last-1, ..., 1, 9
The PageList string is parsed using C code into an array that consists of
an initial int that is > 0 if the list is ordered, followed by sets of
3 integers per range, even/odd flag (odd=1, even=2), start, end. The
final 3 ints are 0,0,0 as a marker.
The initial int is used by 'pagelist_test_printed' as an index to the next
range to be processed when the PageList is used for languages that can only
be processed sequentially (e.g. PS and PCL) and is updated when the page
passes the end of the current range. A value of -1 means the ranges are
not ordered (not strctly increasing).
The flp_fillpage is changed to ignore errors from processing the PageList
performed by ParsePageList (called from SkipPage) when PageCount is 0
so that parsers that support out of order processing (PDF and XPS) can
continue until later. This should have little or no performance impact
since it is limited to PageCount == 0.
Note that the new PDF parser also uses the C code parser and then uses
the array of ranges returned by ".PDFparsePageList". The old PostScript
based parser has not been updated, although it is easy to do so.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It seems that the logic was inverted here, we should check that the size
of the font is enough to satisfy the absolute minimum for the number
of fonts in the collection.
The previous commit was throwing an error if the length of the font was
more than the minimum. Basically all TrueType collections were detected
as being in error. This was causing incorrect output, non-deterministic
output and, on 32-bit tests, seg faults. The latter problems I find
surprising.....
|
| |
|
|
|
|
| |
Fixed a buffer overread in xps_find_sfnt_table. Function now checks
to make sure the font's buffer is long enough for the number of
subfonts it reports.
|
| |
|
|
|
|
| |
Fixed an issue in which deobfuscating a font file that was less than
32 bytes would cause buffer overflow. A warning is now signaled when
this happens.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In PDF, only symbolic Truetype fonts draw marks from the glyph at GID zero
(the TTF notdef). But the default TTF notdef is an empty rectangle, rather than
the Postscript style non-marking glyph.
The FAPI/Freetype incremental interface integration includes code to spot that
case, and return an empty glyph.
Since PDFs don't do incremental font definitions, the pdfi code simply passed
the TTF into FAPI, and onto Freetype as a complete font, so all the glyph
lookups were handled inside Freetype, not using the incremental interface.
Thus we lost the ability to do that "filtering".
Equally, we don't want to take the time to break down the font and "reassemble"
it as the Postscript interpreter is forced to do.
This implements a hybrid approach where we still pass the font data unchanged
into Freetype, but we still use the incremental interface, allowing that
notdef filtering to happen.
This commit affects a heuristic in freetype which autmatically enables
autohinting, meaning we'll no longer get autohinting in cases where we
previously did. That gives a perceived drop in quality at low resolutions.
Since autohinting can be enabled at the command line, it's not a serious
concern.
|
| |
|
|
|
|
|
| |
Fixed buffer overflow issue in xps_read_zip_part. Caused by part
sizes resulting in integer overflow to a number less than the actual
size of the sum of the parts. Fixed by detecting integer overflow and
throwing an error if detected.
|
| |
|
|
|
| |
Removed unnecessary control statement, and added new one for error
checking.
|
| |
|
|
|
| |
Fixed buffer containing uninitialized data on return
in xps_read_dir_part().
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Bug #705333 "Uninitialized read in xps_parse_color"
The code was assuming that if there was too little data for a 4
component colour then it must be a three component colour, but didn't
check to see there was enough to satisfy that.
Check the data, and if there is insufficient, then ignore the colour
(warn in a debug build). We can't return an error as this is a void
function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #705079 "Blending issue with the drop-shadow image"
This turns out to be because the new PDF interpreter was not setting the
current colour space to be the /CS from the XObject group attributes
dictionary.
Attempting to do this turned out to be well nigh impossible. We can't
(not sure why but it certainly doesn't work) use gsave/grestore to
preserve the colour space. Attempting to replicate the old PDF interpreter
in PostScript behaviour and copying the current colour and spaces led
to seg faults.
On closer inspection, however, it turns out that the only reason for
setting the current colour space is because the pdf14 compositor
discards the ColorSpace passed in from the interpreter. The interpreter
passes a gs_transparency_group_params_t structure, which cotnains an
entry for the ColorSpace, the graphics library however copies the entries
into a gs_pdf14trans_params_t which does *not* contain a ColorSpace.
I've no idea what the point of this was, but it seems mad. This commit
adds a new member 'ColorSpace' to the gs_pdf14trans_params_t
structure, and initialises it from the gs_transparency_group_params_t
structure. We then modify pdfwrite to use that instead of the current
colour space.
The PostScript and C based PDF interpreters both already initialised
that member so nothing further needed to be done there. The XPS
interpreter did not initialise that member, and so we also update it
to do so.
This fixes the bug and shows no diffs on the cluster.
Finally update the PDF interpreter, it seems that the old code
accepted a /ColorSpace in place of a /CS in the group attributes
dictionary even though this is technically invalid.
Fall back to the current colour space if no /CS or /ColorSpace is
present in the group attributes dictionary (this is illegal but
it might 'work').
Finally add a check, as per the old code, to see that the number
of components for the colour space matches the number of components
in the /BC array if one is supplied. Unlike Acrobat we choose not
to ignore the SMask if they don't match.
We do emit warnings/errors for all the above conditions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the stack based halftone, we want to set the reference counting data to
zeros/NULLs - in this case, it is later copied into an actually reference
counted, heap allocated object.
Equivalent to 6849cc4774817a2afa2e6f4d77c1aa63e432352f in pdf/
Coverity 375605: Init ref counting entry for gs_halftone
For the stack based halftone, we want to set the reference counting data to
zeros/NULLs - in this case, it is later copied into an actually reference
counted, heap allocated object.
|
| | |
|
| |
|
|
|
| |
It seems xps_doc_trace and xps_zip_trace are never actually used
other than to be set.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
plmain.c should not be setting the PageSpotColors
value. This should be set by the individual
interpreters on a per page basis. This change
fixes a crash (Bug 704660) reduces the number of
closing and opening times of the device with pdfi
and pdfi renders more than 4 spots to the separation
devices just fine. Also for gpdl with HEAD, the subsequent
execution of a PS file following a PCL file
did not properly reset the PageSpotColors to -1
as is required for PS files, resulting in improper
output when going to a separation device. This commit
includes a fix for that. Tested with command line
gpdl -sDEVICE=psdcmyk -r72 -o ./myoutputs/pdl_input_%d.psd
./myinputs/owl.pcl ./myinputs/Ad_InDesign.ps
./myinputs/spots_multi_page.pdf ./myinputs/input.xps
./myinputs/deviceNImage.eps ./myinputs/DeviceN_20Colors.pdf
./myinputs/page_spots/Ad_InDesign.ps
to verify that the number of spots was getting properly
set with each interpreter and page (when applicable) change.
|
| |
|
|
|
|
|
|
|
| |
The manufacturer, version and build date entries in the
pl_interp_characteristics_t were never really used except for version, which
was just set to the GS_VERSION.
Remove the pointless entries, and use a more direct approach to version
reporting.
|
| |
|
|
|
| |
Store and act on error return code from gs_type42_font_init() in
xps_init_truetype_font()
|
| |
|
|
|
|
| |
When calculating the stroke width without the font scaling we do still
need to account for the scaling in the CTM caused by the resolution
as pdfwrite uses that.
|
| |
|
|
|
|
|
|
|
|
| |
The scaling of the stroke width when rendering text in mode 2 (fill and
then stroke) works for rendering but when preserving the text rendering
mode for high level devices it ends up scaling the width too much.
By applying the horizontal scaling from the CTM, when preserving the text
rendering mode, we return the width to a reasonable value without
affecting rendering.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PostScript 'sethalftone' has an optional parameter "ObjectType" that allows
one of the three object specific types to be set: Vector, Image or Text.
Also add a new PostScript operator to set the current halftone (dev_ht,
set by sethalftone) as the device halftone to be used for an object type:
path, image and text.
For non-PostScript clients, the gs_halftone structure adds a 'objtype'
element (enum) that can be set prior to calling gs_sethalftone.
The gs_gstate_s dev_ht is now an array of HT_OBJTYPE_COUNT elements,
indexed by the gs_HT_objtype_t enum, with HT_OBJTYPE_DEFAULT (value 0)
used for prior sethalftone/setscreen/setcolorscreen operations.
NOTE: adding object types beyond the default+3 entries will require modification
of gx_select_dev_ht since it only uses 3 bits of the 'tag' to get the index
for the dev_ht[] array.
For code style, change to use != NULL instead of != 0 in most places that
this commit touched (but we may want a general cleanup of this everywhere).
TBD: Command line options for all PDL's will need a method to take a
halftone specification -- most likely a file that may be "PS-lite" syntax
and may be limited to a threshold array. Discussions are in progress.
|
| |
|
|
|
|
|
|
|
|
|
| |
We decided to follow the ObjectFilter subclass device's naming convention
for objects that are not Image or Text. This patch makes them all the same.
NOTE: The GS9_Color_Management.pdf document also needs to change since we
are changing the external names as well. Before going 'live' with this non-
backward compatible change (admittedly to something that has probably not
been widely used) we may consider issuing a warning for the previous option
names, or even a warning with automatic use of the new name.
|
| | |
|
| |
|
|
|
| |
Caused by my "fix" for the pattern issue. I was inadvertently setting
ca and CA to 0 during the gradient strokes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patterns that are filled with glyphs and then subsequently
filled with another pattern (Visual brush in XPS) was not
working when going to pdfwrite due to the fact that
gs_text_begin gets called by the XPS interpreter
before we have finished the pattern fill of the glyph.
This ends up referencing the pattern that is not done
which ends badly for high level patterns. Instead
if we are already in a high level pattern, set the color
to just a gray. Then after the gs_text_begin, the XPS
interpreter sets the brush to the visual brush which is
subsequently collected. Fixing this, has revealed another
XPS to PDF bug where we are not doing shading fills of glyphs
correctly (at least when dealing with patterns).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the capability to simulate overprint including that of
spot colors for all devices including gray and RGB devices. This
is achieved by having the PDF interpreter look if overprint
is present, the seting of -dOverprint (/simulate /enable /disable),
if the page has transparency, and if the page has spot colors. Depending upon
the color model of the device, and if transparency is present,
a special push of the pdf14 device may occur. The pdf14 device
buffer collects the data in a CMYK or CMYK+spots buffer and the
put_image method in the pdf14 device will map the buffer to
the target device color space. The code was tested with
devices that support and do not support spot colors, those that
support and do not support alpha channels, tag based devices,
gray, RGB, and CMYK devices. A special test file to check
multiple cases was added to the regression suite. By default
-dOverprint is set to /enable, which should result in the existing
behavior where by RGB and Gray devices do no show overprint or spot
colors and CMYK devices will handle CMYK overprinting and separation
devices will show spots and overprint of all colorants. With
-dOverprint set to /disable no device will show overprinting. With
-dOverprint set to /simulate all devices will show overprint and
spot colors. Ray Johnston did the work in the interpreter as
well as the device parameter default setup. I did the pdf14 device
changes and testing. Changes in a variety of locations were required
due to the fact that new combinations were encountered, for example
we had cases where devn colors were being used with a device that
supports tags (bitrgbtags device and pdf14 compositor setup for CMYK+spots).
One file:
tests_private/xps/xpsfts-a4/fts_34xx.xps.pdf ppmraw 72 now produces
an error. This file should have been throwing an error all
along but was being quietly swallowed. Acrobat will not open
the created pdf file and throws and error. I will open a bug
for the issue as it is a problem with the XPS interpreter.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Map all text to black. This is achieved by altering the
color space to DeviceGray with a fill of black during
gs_text_begin. When gs_text_release occurs, the color space
is restored. This will only occur with the option -dBlackText
and if the text is actually to be drawn.
When going to a raster device, the stroke and stroke fill of
the text is handled with a stroke or stroke fill command.
My original plan of storing the old color spaces and client
color in the text enumerator will not work in this
situation as it the enumerator will have already been
destroyed when the stroke or stroke/fill command occurs.
For this reason I store the old color space information
for the current and alternate color spaces
in the graphic state. The structure holding the information
is garbage collected as it is holding objects that may be
garbage collected. We also need to know if the target
was a high level device like pdfwrite, as that device
will handle the fill AND stroke, and we will need to restore
the color space when we tear down the text enumerator.
gs_text_release needed to have the pgs added as a parameter
to allow the possible release of the blacktext structure
when the text is released from the other languages. This
did not seem to be too big of an issue as gs_text_begin
passes the pgs also. If the pgs is not available, NULL can
be passed, and that is done in several locations.
A new special op was added to let us avoid doing the black
text setting if we are constructing a soft mask. If we did not
do this the mask could result in the loss of the text.
Finally, Type 3 fonts will NOT be affected by this process.
Type 3 fonts are often used for actual graphic logos etc.
Ken Sharp suggested we not have them affected by this setting.
There were also issues with trying to do type 3 fonts in
in that the PDF interpreter does some color space settings
of its state when dealing with type 3 fonts and this put the
interpreter's state out of sync with the graphic library state.
This was tested with a forced setting of black text enabled.
No seg faults or errors occurred. There were obviously a lot
of differences reported (over 33,000). All the images that were available
to me with bmpcmp were gone through. Problems were found
and addressed (the soft mask issue for example was found,
as were issues with color spaces not getting properly restored).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has the obvious benefit that the interpreter will skip processing
pages except those that lie in the FirstPage LastPage range.
If the PageList is used, the XPS interpreter will create a new
list of linked pages to process. The XPS interpreter handles all
the PageList cases currently implemented by the PDF interpreter
including even and odd. In addition, the XPS interpreter will handle
backward indexing (e.g. 100-1), as well as starting from last page
to another page (e.g. -2 which means from last page to second page),
and page repeats (e.g. 1,2,1,2,1,2 or 1-3,3-1 or 1-,-1 which is
do page 1 to end and end to page 1) Also, setting -dFirstPage=4
-dLastPage=1 will create pages 4,3,2,1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To do this, we introduce gp_unlink and gp_rename, and call those
as appropriate.
Also, make gp_open_scratch_file add the file to the permit list.
When such a file is closed, it will be deleted from the permit list.
It will also be removed from the permit list if the file is deleted
using the PS deletefile operator.
On closedown, if scratch files haven't been deleted, then we'll
delete them as part of the closedown of gs_lib_ctx.
This means that 'purging' the control lists must not remove scratch
file paths from the list.
Also, ensure that gsapi callers can't maliciously (or accidentally)
remove scratch path paths from the list so as to leave them around
after closedown.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Colour spaces have had a client_data member for some time (only used
with Pantone colour replacement) but no means to signal to the client
that a colour space was going to be freed.
In addition, its terribly hard for an interpreter which uses complex
colour spaces (such as Separation and DeviceN, for Patterns see below)
to reliably track when a colour space is freed.
This commit adds a new 'interpreter_data' pointer to hold data allocated
by the interpreter which is associated with a colour space. We also add
an 'interpreter_free_cspace_proc' to be called when a colour space is
about to be freed. This gives the interpreter an opportunity to clean
up the memory it has associated with the colour space.
Similarly pattern instances (as opposed to Pattern colour spaces) have
long had a client_data member, which was previously stored in the
'template' (which is a terrible misnomer) for both type 1 and type 2
patterns. However there was no procedure to notify the client when the
pattern was freed! The PCL interpreter (which was the only one using
this type of pattern) dealt with this by replacing the 'free' routine
in the structure with its own routine which first freed the client data
and then called the original free routine. This seems like a hack.
This commit moves the client_data out of the pattern instance and into
the pattern structure proper. It also adds a 'notfy_free' member which
holds a pointer to a function to be called when a pattern is freed. This
gives the client a reliable opportunity to clean up the client_data.
These changes involve updating the PostScript, PCL and XPS interpreters
to point to the new location of the client_data, as well as similar
changes in the graphics library. pixmap patterns now use the notify_free
functio0n instead of patching over the structure's free routine.
|
| | |
|
| |
|
|
| |
Never used.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A lot of the FAPI methods made no account for errors (i.e. a call to return an
unsigned 16 bit value would return an unsigned short int). In various places
that meant we ended up using unlikely (in practice, impossible, yet still
"valid") values to indicate an error condition.
This commit changes those calls to have a conventional Ghostscript "int"
return value and (mostly) take pointer to the storage into which they should
write their value. We can now return meaninful error codes.
Secondly, in several places, the FAPI methods and code used integers to store
character codes, cids, gids etc. This is less than ideal because we potentially
have to handle 4 byte codes (especially for gids), and we also use some
special 64 bit values (when available) for specific meanings. There were
several workarounds for that, in various places.
This commit also changes the FAPI API and code to the gs_glyph type for all
such values, removing the need for those workarounds
|
| | |
|
| |
|
|
| |
Avoid masking overflows through relying on implicit casting.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit removes shape.alpha and opacity.alpha from the
graphic state. This involved removal of methods in the
postscript based PDF interpreter, changes in the pdf14 device,
changes in pdfwrite, the XPS interpreter, and the PS
transparency test file that is present in examples and on
the cluster. The goal of this commit was to avoid
confusion and conflicts between shape.alpha opacity.alpha and
the stroke and fill alpha values (CA ca). This change
resulted in progressions in the XPS file. There were changes
in a couple PDF files that required some investigation. In
particular, the change in the dashed lines of Bug694981.pdf. Robin
and I looked at this. Robin determined it was due to
differences in stroke_add and stroke_fill not giving identical results.
In the end, the new output looks closer the what AR provides.
|
| |
|
|
|
|
| |
Introduce a PRI_INTPTR and use that to consistently display
pointers. We avoid using %p, as that displays inconsistently
between platforms. Sometimes it does 0x%x, sometimes just %x.
|
