| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
When called with the '-h' parameter, we don't fully initialise the PS
interpreter. In which case, we shouldn't try to use the PS interpreter
when we shut down.
No cluster differences.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before we start the process of shutting down the PS interpreter, disable BGPrint
(and set NumRenderingThreads to 0, just for safety). If we don't do this, the
"parent" rendering thread will continue preparations for the next page whilst
we shutdown the interpreter, and will thus attempt to access some objects
subject to garbage collection (such as the I/O device table).
Additionally, when a device switches from BGPrint enabled to disabled, make sure
we tear down the rendering thread(s) and get rid off the BGPrint related data.
No cluster differences.
|
| |
|
|
|
|
|
| |
When we (re-)initialise an allocator, we have to initialise the contents of the
current chunk (cc) entry - initialise to "false" since that's the common case.
No cluster differences.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #695484 "Regression: seg fault with debug build in pdfwrite starting with ceb5e2f006bf554a56701ee2f2c228841b324a4b"
The problem was caused because pdfwrite can maintain two copies of a font,
a subset and a complete copy, depending on settings. We were properly freeing
the subset, but not the complete copy.
This has been a long-standing undetected memory leak, but only on systems
without garbage collection, because the copied font is subject to GC, and
indeed this was causing the actual fault. When we restored at the end of the
file, the copied font was garbage collected, which caused it to try nd free
any glyphs from its font cache. But the font cache is now (since the commit
in the bug title) pointing at the pdfwrite font cache, and that has already
been freed before we get to the end of job restore, resutling in a seg fault.
Here we free the complete font copy if one has been allocated.
No differences expected.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The downloaded font in this file (the barcode) used the typeface
family designation of 0 which is reserved for the lineprinter font.
Our interpreter scales lineprinter specially and identifies
lineprinter with its typeface number (0), thus the barcode font was
scaled as if it were the lineprinter font. Now we check the typeface
number is 0 and the font is internal which will uniquely identify the
lineprinter font and not confuse other fonts with it.
Technically the font is broken and shouldn't be accepted, the typeface
family numbers documented by HP should not be reused by downloaded
fonts, but HP printers seem to print the job.
|
| |
|
|
|
|
|
|
|
|
| |
Remove epswrite (the final "subdevice" of pswrite) and references to it.
Also remove the gdevps.c source file.
Cluster differences only in files that enumerate the devices list, for
example:
430-01.ps
|
| |
|
|
|
|
|
|
| |
An extended version of lib/viewcmyk.ps so that "raw" output from
bit, bitrgb or bitcmyk can be displayed or converted. For example:
gswin32c -sDEVICE=bitrgb -dGrayValues=256 -o x.rgb examples/tiger.eps
can be viewed with:
gswin32c -dRGB -dBITS=8 -- lib/viewraw.ps x.rgb 612
|
| | |
|
| |
|
|
| |
No effect, just silences the compiler or scan-build.
|
| |
|
|
|
|
|
| |
Replaced (for now) with a brief message about being unsupported, and to use
configure --with-ufst=<>
No cluster differences.
|
| |
|
|
|
|
|
| |
When cross compiling between platforms of differening endianness, mkromfs will
now create output usable on the target architecture.
No cluster differences.
|
| |
|
|
|
|
|
| |
Fix an issue where the default fallback font could not be found if the
GenericResourceDir was a relative path.
No cluster differences.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #695468 "/rangecheck in .installpagedevice error when combining LockDistillerParams, setpagedevice, and restore"
Previously when LockDistillerParams was true the distiller param parsing
code did not get called. This left the Distiller parameter key/value
pairs 'untouched' in the parameter list.
Ordinarily this is not a problem, but .installpagedevice, which is called
during restore to reset the page device parameters, insists that all keys
must be consumed and throws an error if they are not.
This patch alters the distiller parameter parsing to read all the parameters
no matter what the setting of LockDisillerParams. The values are read into
a dummy parameter structure, when complete they are either copied back to
the real structure or, if LockDistillerParams is set, discarded. If we
discard the parameters we clean up the memory rather than relying on garbage
collection to do it for us.
I don't think the pdfwrite device currently does this when the device is
closed, which would be a memory leak, if we ever decide we need to address
this then we can use the code here.
No differences expected.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Bug #695307 "Preservation of PostScript form elides form content"
When a device (such as pdfwrite) hands back a matrix to set as the CTM
(pdfwrite does this to capture the form unscaled), we need to account for
that CTM when we reset the clip, otherwise we can end up clipping content.
Also, rather than using +/- page boundaries, we use +/- the form BBox.
This shows 2 minor progressions in the test suite.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #695017 "pcfont_do_reset() leaks memory"
The PCL interpreter should free its font cache on exit, but it does not.
This is because of the fact that when we copy fonts the font cache of the
original font is copied to the font cache of the copied font. Later, when
a high level device wants to retrieve glyph information, the font code
uses the font cache from the copied font.
This doesn't immediately seem like a problem, it seems like we should be
able to defer freeing the font cache until after we've closed the device,
and that would satisfy pdfwrite. However, the way that PCL 'passthrough'
works, the PCL interpreter can be run 'inside' the PXL interpreter. If we
free the PCL interpreter font cache when it exits then pdfwrite has font
copies which are still pointing at the freed font cache.
We did discuss having the PCL/PXL interpreter set the gs_lib_ctx font_dir
(it currently dos not do so) and having pdfwrite set the font cache of the
fonts it copies use that, instead of the font cache from the original font.
But this seemed to me likely to run into the possibility of the same problem
recurring in future.
Instead, we have pdfwrite create and maintain its own font cache. When pdfwrite
copies a font it replaces the font cache pointer (which is initially the same
as the original font) with the new pdfwrite-specific font cache.
This means that any interpreter can free its font cache and pdfwrite will
still be able to use its own font cache when retrieving glyph information.
This commit includes both the changes to pdfwrite to enable the new font cache
and the changes to the PCL/PXL interpreter to free the font cache when the
interpreter is done with it.
No differences expected.
|
| |
|
|
|
|
| |
Tweak to deal with off-by-one errors due to casting of doubles in trio.
No cluster differences.
|
| |
|
|
| |
No cluster differences.
|
| |
|
|
| |
No cluster differences.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 55bd0a59caf26a59f852e2dec5b76ad399d9408b fixed the problems with
RedValues and friends, but at the cost of preventing these keys being set
by setpagedevice.
This commit allows them to be set by creating a 'write only' dictioanry
whose keys are removed from the initial device dictionary before we make it
read-only and send it to setpagedevice.
See the comments in the commit for further details.
No differences expected.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #695439 "Reference to free memory, or segfault with release build"
The problem is the horrendous way our implementation of setpagedevice works.
Where we should query the device for its parameters, our implementation
maintains a dictionary (initially built by querying the device) which is
updated by calls to setpagedevice.
Clearly at some time in the past someone has discovered that this breaks
badly if the device changes a parameter itself, as this won't be reflected
in the saved dictionary. So the '.dynamicppkeys' dictionary was defined,
whose sole purpose is to hold a list of keys whose values must be refreshed
from the device.
However, this dictionary is *also* used to prevent those same keys being
sent to the device.....
This means that commit 2eda51b48c7e97adf7c46fc3d7eb34fcdf6061e6 prevented
any changes to OutputICCProfile being sent to the device.
So I've now made 2 dictionaries with separate purposes, one is for 'read only'
keys which should not be sent to the device, and one which contains the list
of keys which must be read back from the device to replace the stored values
in our dictionary. Keys may appear in both, either, or neither.
The problem in this bug is that we create our initial dictionary when the
device is in DeviceRGB, and we store the RedValues, GreenValues, BlueValues
and GrayValues from the device in our stored dictionary. Then we execute
code to change the ProcessColorModel to DeviceGray. This alters the values
of the RedValues etc in the device. But these are *not* copied into our
stored dictionary. Later we call .installpagedevice which does not change
the ProcessColorModel, but does attempt to set the RedValues etc, which are
invalid for a DeviceGray ProcessCOlorModel, leading to a rangecheck.
I had hoped that adding these keys to the volatile dictionary would be
sufficient to fix the problem, but it seems that we don't update our stored
dictionary with these parameters. The only way to fix this turned out to be
to add the keys to the 'read only keys' dictionary so that we don't try and
send them to the device.
I'm not completely sure this is sensible, it isn't obvious to me what these
values are for, so I can't be certain that they should become 'read only'.
However, its the simplest way to solve this problem.
Of course the right way to fix this is to change our horrible setpagedevice
code so that it works the way the spec says it should.
The fix described above resolves the memory warning for me as well.
No differences expected.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #695438 "AcroForm text fields not being rendered"
There are multiple parts to this fix.
1) Alter the default of the NeedAppearances key in AcroForms and AcroForm
field dictionaries to true so that if its not present we will generate
Appearances for fields which have none. (we still won't generate them if
the field is present and set to false, though Acrobat does)
2) Fix the Length key of the Form dictionary we generate for Tx fields,
previously it was set to 0, so the form wasn't ever executed.
3) If there is no 'V' key in the Field dictionary for a Tx field, use the
/DV key instead. If still no key then use an empty string.
These changes uncovered some interesting additional problems.
1) Bug687498 has an AcroForm with a Tx field, declared as multiline, where
the actual data is an empty string. Now that we actually execute the Form
this causes an error. Add a check to treat strings with less than 2 bytes
as single line, so that splitstring doesn't throw an error.
2) Bug692477.pdf, now that we default 'NeedAppearances' to true, we discover
that this file has a Fields array where every element is the null object,
which causes errors trying to extract dictionary key/value pairs from it.
Add a check to see that the Field element is a dictionary, and ignore it if
it isn't.
No differences expected, we don't test with -dShowAcroForm
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was caused by the gs_setpd.ps logic having a dictionary that has the
OutputICCProfile pointing to dev->icc_struct->device_profile[0]->name, but
when ColorConversionStrategy distillerparam is set, it does a rc_decrement
on the pdev->icc_struct which frees the entire structure, among those the
'name' (which was allocated in non_gc_memory).
Add the OutputICCProfile to the list of .dynamicppkeys in gs_setpd.ps so
that the string will always be updated and the dictionary won't have a
stale pointer.
Having a dict with a string in non_gc_memory is OK I guess, even though
we generally "hide" all non_gc_memory elements from the GC.
|
| |
|
|
|
| |
Customer 532 has done extensive testing and uses tags. This change
is in their code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #695359 "Wrong gradients after conversion to PDF"
The example file is a hand-coded shading of type 5 with the DataSource
being an array, but using a function to convert the parametric value at
each vertex into a colour value.
The PDF specification doesn't support this kind of shading, so we need
to convert it. In doing so we write out a Decode array, which needs to contain
the minimum and maximum colour values. Ordinarily we get these from the
shading dictionary, but when using an array for DataSource this is not
present. In the absence of the Decode array we were defaulting to 0 and 1
but the function actually has a range from 0 to 10. This meant we were
truncating the colour space.
This commit examines the Function (if present) and uses the Domain of the
function as the values instead of 0 and 1.
This may not be sufficient in the absolute general case, but all mesh
shadings are rare in real world files, and mesh shadings using array
DataSource are still less common, as are examples with a function which
does not have a Domain 0-1. So this will suffice until we see more
problems.
Note that Acorbat Distiller X produces different output if you run the
two shadings in the example file separately instead of consecutively. Also
Acrobat X displays the resulting file from both Distiller and Ghostscript
incorrectly (Acrobat XI displays them correctly)
No differences expected.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #695387 "PDF with jpeg2000 conversion problems"
The PDF spec states (table 4.39, BPX on page 340 of the PDF Rerference)
that the Bits Per Component value is to be taken from the JPX stream and
the image dictionary value should be ignored if present. We were only
reading the BPC if either that to the ColorSpace was missing from the
image dictionary.
In this commit we *always* pare the data out of the JPX stream (which is
a small performance penalty). However, this always overwrites the data in
the resource dictionary, which is fine for BPX< but not acceptable for the
colour space, because Acrobat favours the ColorSpace in the
image dictionary over the JPX colour space, and because we set the colour
space to be DeviceGray for softmasks.
So we save the colour space from the resource dictionary (if present), read
the BPC and colour space then, if we had a colour space in the resource
dictionary we restore it back again.
For some reason this causes problems on the cluster with the test file
Bug688845.eps. Since this change only affects JPX images, and PDF files, I
can't see any way that the change can be responsible for this. I am unable
to reproduce the problem on Windows or Linux locally.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is essentially the same patch as committed in:
4fc4b8410d35b193d549558ab212cc727db9460b
but that patch was missing white space at the ends of automatically
concatenated strings - hence the interpreter saw, for example:
".systemexecend" rather than ".systemexec end".
Additionally, to avoid that confusion in the future, I've removed the reliance
on the automatic string concatenation.
Also removed a spurious additional call to ".uninstallpagedevice".
No cluster differences.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
See bug #694160 and #695420. Somehow this patch ends up leaving 'quit'
undefined at the end of job, which breaks the '-o' switch. It also somehow
manages to break at least some pdfwrite incantations, leading to an undefined
error with a garbage caller. It kind of looks like the name table is
broken or similar.
Note that the undefined error on quit occurs when running GS interactively
and even when this happens, "systemdict /quit get exec" works, so its not
as simple as /quit being undefined.
No differences expected.
|
| |
|
|
|
|
| |
Fix the description comments.
No cluster differences
|
| |
|
|
|
|
| |
Practical Automation printers.
No cluster differences.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #695417 "gs(ps2write) produce invalid ps from certain LibreOffice print emission"
The code in the opdfread prolog for converting TrueType fonts to type 42
fonts was completely broken for fonts with a format 0 LOCA table (16 bit
offsets). The offending routine is StringToLoca.
The code was reading 32 bits instead of 16, which causes it to exhaust
the string data, leaving array members uninitialised, which is the inital
cause of the error. However, it also didn't multiply the offsets it did
read by 2 (format 0 LOCA offsets are multiplied by 2), and had a 'dup'
which resulted in the stack having the wrong value on top on exit.
No differences expected
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Bug #695407 "tiffsep should print out separation equivalent CMYK"
Patch supplied by Mateusz Lenik to print out the CMYK equivalents for every
ink in the job.
Controlled by the new PrintSpotCMYK switch, which is only supported on the
tiffsep device, documented in devices.htm.
No differences expected.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There was a logical error in the glyph encoding generation for TT fonts,
affecting fonts without post tables.
When handling the case where the same glyph name references two different
glyphs, the index in the glyph encoding we wrote the generated name to was the
GID (i.e. the index returned from the cmap table) rather the original index
we were handling from the glyph encoding.
No cluster differences.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #695403 "Error ocurred while reading XREF table"
The fix for bug #694342 treated an xref section with no entries as an error
and caused the xref to be rebuilt. However, if a PDF file is converted into
a hybrid file (one with an xref *and* an XrefStrm) by adobe CS 3, then it
does this by adding a 'dummy' xref which has a /Prev pointing to the real
xref, and a /XrefStrm pointing to the stream.
The dummy xref has a section "0 0", is first object 0, no objects defined
which falls foul of the test for Bug 694342 and causes the xref to be rebuilt.
This commit adds a boolean which is initially false and is set true in the
parsing loop for the xref section. When we encounter a /trailer, instead
of checking if 0 objects are defined, we now look at that boolean. If its
'true' then we have seen a section entry, and can treat this as valid, even
if no objects are yet defined. If we haven't seen a section then we treat
it as invalid and force an xref rebuild.
This causes sumatra/694313_-_empty_xref.pdf to stop producing errors as
well.
|
| |
|
|
|
|
|
|
|
|
|
| |
The PrintHex routine assumes that PostScript integers are 32 bits wide.
This is no longer guaranteed with GS. This fix ensures that after we do
the bit shifting to isolate 4 bits for conversion to hex, we don't have
a number > 15, which could occur if the integer was sufficiently large.
This prevents the code throwing an error when debugging.
No differences expected
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When creating glyph aliases for a TTF, we check for "formatted" unicode glyph
names of the form "uniWXYZ" where "WXYZ" is the glyph code point in base 16.
In doing that we use a temporary string which is 16 characters long (since the
formatted names we're interested won't be longer that 16).
So, check the glyph name is <16 chars long before checking if it's a "uni..."
style name.
No cluster differences.
|
| |
|
|
|
|
| |
Checks for integer overflow.
No cluster differences.
|
| |
|
|
|
|
|
|
|
| |
In the event of an interpreter triggered error during a transparency operation,
pdf14_discard_trans_layer() is called to clean up. It frees the context, but
didn't set the ctx pointer to NULL - thus we could try to free the already
freed context object when the pdf14 compositor device is shut down.
No cluster differences.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Certain chunks in the memory manager are used to contain only one (o_alone)
allocation: "large" allocations and "immovable" allocations specifically.
We need to be able to identify those chunks so we don't end up trying to use
any empty space in them for later allocations - these chhunks can end up with
empty space in them if the original object allocated in them is shrunk.
The problem that occurs is when we free an o_alone object, we immediately free
the chunk containing it, thus any other allocations in that chunk are also
freed.
Adding a c_alone flag to the chunk means we can trivially identify and skip
those chunks when searching for free memory.
No cluster differences.
|
| |
|
|
|
|
|
|
|
|
|
| |
A broken TT font could end up with us allocating a zero length array for
the for the glyph lengths, then later to attempt to access entries in that
array.
Thus, avoid allocating the zero length array, and treat a NULL glyph_len array
the same as a glyph_len of 0.
No cluster differences.
|
| |
|
|
|
| |
Minor issue, but I did find a case where the buf->backdrop was left
uninitialized when working on customer 532 issue with fts_25_2526.pdf
|
| | |
|
| |
|
|
| |
Thanks to Norbert Janssen.
|
| |
|
|
| |
Thanks to Norbert Janssen.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This feature is in response to the thread on gs-devel "pswrite and NOPLATFONTS"
Normally pdfwrite and ps2write try very hard to maintain fonts from the input
as fonts in the output, for reasons of output size, performance and qualiity.
It seems that some people are relying on using pswrite with -dNOCACHE in
order to produce PostScript output with no fonts at all. (As far as I can
see this is to address the limitations of other software). This was never
a goal for pswrite, but it seems that it works 'well enough' to be useful.
Sadly, despite us flagging the fact that pswrite had been deprecated, nobody
gave us any feedback until after (several releases after, in fact) we had
removed the device. We are not going to reinstate support for the pswrite
device, having spent effort to remove it in order to drop support for it,
so this commit adds a new feature which causes pdfwrite and friends to
write the glyph description into the content stream as it is used instead
of constructing fonts.
This is controlled with the new switch NoOutputFonts which defaults to false
There are no cluster differences with this commit. Using the switch causes
pretty much every test file which contains text to render differently.
|
| |
|
|
| |
...into "normal" marking ops if the glyph cache is disabled.
|
| |
|
|
|
|
|
|
|
|
| |
Initialise the "prev" entry in the top node in the x line list to null and
check it isn't null before we use it. If we reach that point, it indicates that
a) the current path reaches (and probably passes) the limits of our coordinate
space and b) the line list is already in the correct order - as best it can be,
anyway.
No cluster differences.
|
