| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Plus dates
|
| |
|
|
|
| |
OpenJPEG enables it's SSE code based on the compiler defining __SSE__ so we
want to undefine that if we're not using SSE operations.
|
| |
|
|
|
|
|
| |
When setting up a traversal from a midpoint of the tree, we'd
immediately trip into the "has hit the endpoint" code.
Fix that.
|
| |
|
|
|
|
|
|
| |
If the PageSize was square, it would be treated as "not landscape",
but landscape pages in would be arbitrarily rotated.
Note this does not change the bahavior of PS or EPS page fitting.
TBD: Add an option to fit to a page and never rotate (FitPageNR)
|
| |
|
|
|
| |
When reallocing set the rawsize before attempting to write
the post guard block.
|
| | |
|
| |
|
|
|
| |
Rather than rolling our own memset prototype in this case, use
the one that gs provides.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function save_set_new() (where the original fix for 'has_refs' is located)
is called in two circumstances: when creating a save level, and when destroying
a save level.
We have to retain the 'has_refs' value for the latter case for the garbager to
function correctly, but doing so in the former results in the garbager
sometimes scanning more memory than is really necessary (it can end up scanning
ref memory from the previous save state, which is pointless since that cannot
change).
This change means that 'has_refs == true' will only be retained in the
'destroying a save level' case (which works correctly because, by the time the
function is called, we've already returned the relevant allocated to its
previous state).
|
| |
|
|
|
|
|
|
|
| |
The dda used to select the source pixel for mapping into the image
must use the same stepping for gray (monochrome) and color images
since an SMask is monochrome and the image may be in color. This is
primarily evident with the bug file since Matte is used to indicate
that the source data is premuliplied. Colors can shift a LOT since
the removal of the premultiplication can expand mistaked.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 093bd18bd923644fcd25c507088c0ebc63b4c320 included an
'optimisation' to prevent rescanning for transparency if we had already
scanned. However, this assumed that the function pdfshowpage_setup
had already been executed in order to set a variable.
This is always true when running files via Ghostscript, but any
application (such as GSView 5) which executes the PDF operations
individually need not execute this function. If the function was not
executed then an error occurred. From other comments in pdf_main.ps
its possible that customers may be using these functions as well (see
the comments above the definition of /pdfshowpage)
This commit checks to see if the variable has been set, if it has then
it is used, otherwise we rescan for transparency. This prevents the
error, but uses the optimisation if its possible to do so.
No differences expected
|
| |
|
|
|
| |
Although (likely) benign, solving this is trivial: give the rendering code
a ushort rather than a single byte.
|
| |
|
|
|
|
|
|
| |
Noticed in passing (thrown up by ASAN): the plmain code was not fully shutting
down the memory manager when using the chunk allocator.
This commit adds a convenient function (gs_memory_chunk_wrap) and a
pl_alloc_finit() function to ensure that all happens.
|
| |
|
|
|
|
|
|
|
|
| |
The code was casting to a gx_device_printer to get to the BLS_force_memory
value, but since the target device for a clist device is no longer
necessarily a printer device, it wasn't guaranteed that the struct contained
that entry.
So move BLS_force_memory to the base device type (gx_device), so it's always
available.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #697109 "Inkscape graphics in Latex PDF distorted on compression"
When starting a new substream the pdfwrite code always resets the current
graphics state to the 'initial' state. This seem, to me, utterly wrong,
if we have changed the graphics state, then it persists into any
'substreams'.
Indeed, in this case we set the dash array, then the fact that we have
transparency causes us to push a new group, this starts a new substream,
we reset the graphics parameters (including the dash). Then we set the
dash pattern to the default and stroke a path. If we didn't start a
group we would notice the dash had changed and emit the change. However
because the group causes a reset, we see the dash change to the same as
it currently is, so we don't emit it.
I'm not totally happy with this change, there are a *lot* of subtleties
in the code, not least the (bonkers) fact that starting a group *does*
reset 3 extended graphics state parameters (SMask and constant alpha).
It looks like we have some assumptions built in elsewhere as well. If
I don't reset all the parameters then some other files start to fail.
This fix doesn't reset the graphics state for XObjects, but does for
everything else. For XObjects it only resets the 3 group parameters.
I'd spend more time on this but I want to get some sort of fix into the
9.20 release. This definitely needs more investigation.
There are a number of diffs, most are definite progressions, a few that
I can't be sure of but they don't seem any worse (and in some cases the
original file is technically broken anyway). Oddly there are more
progressions when rendering to halftoned devices, I can only assume
that we were previously emitting a broken halftone.
|
| |
|
|
|
|
|
|
|
|
| |
Follow-on from commit 4b101952d81a5899972f81f7b18ef3becd5bd45e
There are several places that set, and check the value of file_limit for
streams. Ensure they all use the requisite value whether the gs_offset_t is
64 bit (normal) or 32 bit (abnormal).
To make it easier, and more consistent, pull the logic out into a macro.
|
| |
|
|
|
|
|
|
|
|
| |
The hpgl_map_symbol() function is modified to handle downloaded
(bound) pcl fonts correctly. HPGL and PCL now use the same
char_is_printable() function to detect printable characters.
modified: pcl/pcl/pcstate.h
modified: pcl/pcl/pctext.c
modified: pcl/pcl/pglabel.c
|
| |
|
|
|
|
|
| |
commit ab3a1249ce28e3cac629ce1466d17e635ff50fab introduced a check
to ensure a clip path wasn't null before using it. This caused Coverity
to then check the use of that clip path throughout the function, and
identify another area needing a check.
|
| |
|
|
|
|
|
| |
Hopefully the last missed increment of a loop variable in the image
interpolation code.
Thanks to Jonathan Dagresta for the patch.
|
| |
|
|
|
|
|
| |
configure.ac now finds the 'strip' exe.
There's a new target 'so-only-stripped' which builds the .so libs and then
strips them using the supplied strip exe
|
| | |
|
| |
|
|
|
| |
The unicode values were wrong for ff and fi. With this fix and the
new URW fonts the problem reported is fixed.
|
| |
|
|
|
|
|
|
|
|
| |
Bug #697098 "pdfwrite charpath conversion problem"
When the PDFCompatibilityLevel is 1.5 or above we can use reals with
sensible ranges, instead of the +/- 32767 that old versions of the
specification limited us to.
This results in a large number of small differences, some minor progressions
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #697098 "pdfwrite charpath conversion problem"
This is not a fix, but a work-around, especially for future files.
We currently limit the resolution by checking the media size to see if
it lies in the range +/- 16,000. This is because The PDF Reference states
that co-ordinates are real numbers, and versions of the spec prior to
1.5 have a limit of +/- 32,767 for real numbers. In practice it was
noted that Acrobat Reader couldn't even cope with numbers that large so
we arbitrarily settled on 16,384 and then allowed a bit of slop.
With the PDF 1.5 specification (now 13 years old) this limit was raised
to +/- 3.403x10^38
In the interim we have also raised our default PDF creation to 1.5 and
we have adopted other means (altering the CTM) to keep co-ordinates
in the 32,767 range. So there is really no reason to maintain this old
hack.
|
| |
|
|
|
|
|
| |
Noticed while doing other work, if we don't have a clip path, we must
not attempt to use it to clip text.....
No differences expected
|
| |
|
|
|
|
| |
Included getting the Matte color entries to the
transparency compositor action (Thanks to Ray)
and undoing the preblend with the Matte bias.
|
| |
|
|
|
| |
The file_limit was initialized in sread_file and swrite_file to the largest
gs_offset_t value, but the check only compared to max_long.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This appears to be used in the AI5 ProcSet of Adobe Illustrator (R)
Version 7.0 Full Prolog and allows us to construct a Separation
space that has a DeviceRGB alternate colorspace and tint transform.
There is no Adobe documentation that mentions this, but I found one
other implementation that had this procedure defined.
Also fix missing pop when setcustomcolor is invoked with tint == null
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The configure check for required pointer alignment works on Linux/SPARC, but
not on Solaris/SPARC - so reinstate the special case code in genarch.c
I'm including the HP/UX case as well since it's safer, and does not add
to the complexity of code.
|
| |
|
|
|
|
|
| |
The Sun cc compiler optimizer has bug that *seems* to result in the order
addition operations being changed (which isn't legal). In this case, we're
unpacking bytes from a stream, and reordering the operations means the
bytes come out of the stream in the wrong order.
|
| | |
|
| | |
|
| |
|
|
|
| |
The bad memcmp was part of an obsolete implementation to include icc
profiles in the photoshop device which is removed with this change.
|
| |
|
|
|
| |
Many HP printer and our PXL interpreter limit the dash element array
size to 20 so we shouldn't produce PCLXL that exceeds that limit.
|
| |
|
|
|
| |
If the vector device's begin image procedure fails fallback to using
the default image code instead of producing an error.
|
| | |
|
| |
|
|
|
|
|
| |
Add an explicit "gslib" target, and have the .a end up in the "bin" direstory
rather than the root of the tree.
So, to build the .a now, you'd do "make gslib"
|
| |
|
|
|
|
| |
abs() and memset() prototypes.
Also, dependencies as required
|
| |
|
|
|
|
|
|
|
|
| |
When the output intent profile is used it was cloned from
the target device, but it was not getting its initial settings
in place. The threads do not need the post render profile nor
the output intent profile (it is the device profile in this case)
This was tested on -dUsePDFX3Profile, -dNumRenderingThreads=4
-sPostRenderProfile="myprinter.icc" with the file Altona_Technical_v20_x4.pdf
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If the only occurrence of a spot color was in a pattern,
the equivalent CMYK values were not getting set for use
by a separation device during the installation of the
separation color space. This was due to the fact that
the pattern accumulator bits device (whose target is the
real device) has its update_spot_equivalent_color proc set
to default which ends up doing nothing. Instead we now
set the bits device proc to forward to the real target
device.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GC would run due to the 'system' VM which never had it's limit set (default
600,000), but after the GC ran the limits for all of the VM's were reset to
the current allocated plus the limit, so the local VM and global VM were not
in a state to be collected (pages ran in a save ... restore).
Setting the system VM limit to the same value allows the file to complete
in 84 seconds and only uses 74Mb (a cut down file that was 5k pages took 170
seconds and used 634Mb before the change). The entire large file only needed
725 GC's to complete and most were for the local VM (space==12), rather than
for the system VM (space==4).
Also change the formatting of one of the gs_debug['0'] messages to keep all
the relevant values on one line which makes searching/grepping easier.
|
