| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Unused variables, 'may be used unset' or implementations not
matching prototypes.
These show up now as the gcc version on the nodes has increased.
|
| |
|
|
|
|
|
|
|
| |
Bug #693637 "Some of user options are not working in windows printer driver when option QueryUser set to 3."
Some (undocumented!) User settings which can only be altered by
sending PostScript were not being applied when the QueryUser
setting was 3 (use system default printer). This was despite
the Copies being set in this case, so this was clearly an oversight.
|
| |
|
|
|
|
|
|
|
|
| |
Bug #693636 "Antialiasing options are ignored in windows printer driver"
This commit processes the Graphics and Text AlphaBits parameters and
stores them. When we later set the actual colour depth of the device
we set the device color_info structure anti-alias bits from the
requested AlphaBits, taking the actual colour depth of the device into
account for the purposes of setting the maximum.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OSS-fuzz #58582
The fundamental problem here is that pdfwrite was assuming that the
font WMode could only ever be 0 or 1 (the only two valid values) and so
was using it as a bitfield, shifting and OR'ing it with other values.
The file in this case has a CMap which contains :
/WMode 8883123282518010140455180910294889 def
Which gets clamped to the maximum unsigned integer 0x7fffff
This led to a non-zero value in the flags to the glyph info code, when
the value *should* have been 0, which caused the graphics library to
take a code path which wasn't valid. This led to us trying to use a
member of a structure whose pointer was NULL.
I can't be certain whether other places in the code use WMode in the
same way, so I've chosen to fix this at several levels.
Firstly, in the code path we shouldn't reach (gs_type42_glyph_info_by_gid)
check the value of pmat before calling gs_default_glyph_info. That code
will try to use the matrix to scale the outline, so if it is NULL then
the result is undefined. This prevents the seg fault.
Secondly, in gdevpdtc.c, scan_cmap_text(), set wmode to be either 0 or
1, to ensure that it does work as a bit, rather than using the integer
value from the font and assuming it will be 0 or 1.
Finally in the three places in the PDF interpreter where we set the
WMode for the font, check to see if the value is either 0 or 1 and if it
is not, raise a warning and make it 0 or 1.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #706551 "ps2pdf corrupts Unicode title in PDF 1.4 XML metadata"
This is not in fact part of the original report and should have been reported
separately. Still....
The bug arose from mer removing a partial implementation of surrogate
pairs when we started using Coverity, because Coverity complained about
the code and it was simpler to remove it. I clearly forgto to go back
and finish it.
This just adds code to deal with the (documented as unusual) case of
UTF-16 surrogate pairs. Seems to work with all the tests I can concoct.
|
| |
|
|
|
|
|
|
|
|
| |
Bug #706551 "ps2pdf corrupts Unicode title in PDF 1.4 XML metadata"
In fact the XMP metadata string is not 'corrupted' we simply replace all
UTF16 values > 0x800 with the Unicode replacement glyph. This was to do
with some investigations back in 2016 which never came to anything.
Simply promote UTF16 values > 0x800 to 3 bytes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #706523 "Error during merge Pdf Function : "*** C stack overflow. Quiting...""
The example file uses (on page 10) an enormously complicated clip path.
I suspect this was a chroma-keyed image or something similar which has
been downgraded by pdfwrite (which produced the original file) to a
fill and a complex clip.
The code for writing clips in pdfwrite uses a recursive function in
order to reverse the order of the subpaths. None of us can see a sane
reason for reversing the subpaths, so this commit simply does away with
that, which means we don't need the recursion and don't fall foul of
highly complex clip paths. (Note on Linux this did not fail, presumably
because the C exec stack is larger. But a more complex example
presumably would fail)
A few PXL files, when converted to PDF and the PDF rendered, show
dropouts at low resolution (65 dpi) but these files are already dropping
most of the strokes anyway at this resolution so I'm not going to worry
about the small difference. A few other files exhibit single pixel
differences at higher resolution, but again nothing of concern.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As requested by customer 1120. The PSPageOptions array is used to
specify strings to be inserted into the PostScript output of the
ps2write device; the intention is to permit device-specific code to be
placed on each page.
Ordinarily the array contains one string for each page of the output,
and that string is applied individiually.
To assist in the common cases where a pattern of different setup is
applied to pages, such as treating each of a pair of pages differently,
for every pair of pages, the processing 'wraps around' the array if
there are more pages than strings. So if we supply two strings the first
string will be applied to pages 1, 3, 5, ... and the second string will
be applied to page 2, 4, 6, ....
The customer wants to disable the 'wrap around' so that if they supply
fewer strings than pages, the device simply stops adding strings when
it runs out of content in the array.
There is no practical way to do this by altering the array content
because it is actually quite awkward to deal with heterogeneous
parameter arrays. Rather than rewrite the code extensively I've chosen
(reluctantly) to add a new parameter 'PSPageOptionsWrap'. When true
(the default value) then the behaviour is unchanged. When false the
ps2write device no longer wraps around the array, but simply stops
adding content to each page.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #706443 " AutoRotatePages=/PageByPage can be incorrect when there is text outside the TrimBox"
The bug file has text which lies off the page and so is entirely clipped
out and not passed through to the output file. However, because we count
text in pdf_text_begin, before we determine that the text is clipped,
it is still counted for the purposes of auto-rotation.
In this commit; add a new boolean in the pdf text enumerator to track
whether the text has been entirely clipped out. Initialise the flag in
gdev_pdf_text_begin. Move the counting for the purposes of auto-rotation
from pdf_text_begin to pdf_text_release so that we have a chance to
determine if the text is clipped before counting it. In
pdf_process_string, when we determine the text is clipped out, set the
flag.
I also fixed an annoying compiler warning at the same time, in
gdev_pdf_text_begin.
This causes changes in :
tests_private/comparefiles/541_623.pdf
tests_private/comparefiles/541.pdf
tests_private/comparefiles/Altona_Technical_v20_x4.pdf
tests_private/comparefiles/Clarke-Tate-Manns-Chinese.ai
tests_private/ps/ps3cet/13-29.PS
Because text that is clipped out is no longer considered, which
changes the orientation of these pages. One is a progression, one is
debatable and three are arguably regressions.
So I do not intend to commit this until after the release currently
underway is complete (10.1.0). This will give us some time to see
how it performs internally.
|
| |
|
|
|
|
|
|
| |
Chunky separations were SEGVing due to a the device proc for
fill_rectangle_hl_color not being setup.
Planar separations were buffer overflowing due to a short allocation
for the bitmap due to unknown number of separations.
|
| |
|
|
|
| |
Both planar and chunky separations need our own
fill_rectangle_hl_color routine.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The display device can be initialised in a 'disabled' form when
the callback is NULL. It seems we can get fill_rectangle called
when in such a state, and we may not have initialised it, causing
a SEGV.
The fix is to initialise this to the usual display_fill_rectangle,
function which will do nothing if callback is NULL, but won't
crash.
Thanks to Youngseok Choi for the report.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code is poorly documented, and an unholy mix of "int", "word"
and "ulong" pointers, but I think I've understood the problem
enough to solve it.
The bug uses a single pixel wide device. It's therefore dealing
with lines that are expected to be 3 bytes wide. It allocates
buffers based on this number.
But it actually processes a larger number of pixels per line -
namely the number of pixels that will fit into the expected
amount of storage, rounded up to a 'word'. When words are 64bits
this makes much more difference than when they are 32.
Accordingly, we allow for this extra when allocating our buffers.
This should be a harmless change, as effectively all I've done is
allocated a buffer to be slightly larger than before.
Thanks to Youngseok Choi for the report.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #706453 "Element missing while converting pdf from rgb to cmyk using Ghostscript"
When converting a shading to an image (for ps2write or certain cases of
colour converting shadings with pdfwrite) it is possible that the
shading functions only call fill_trapezoid() and not fill_path().
This can result in us reaching dump_converted_image with
cvd->mask_is_empty and cvd->path_is_empty both true and we would then not
write out the rendered image.
Because of the convoluted nature of this code (which I am convinced is
sub-optimal!) simply setting either mask_is_empty and/or path_is_empty
to false results in incorrect rendering. So here we add a new boolean
'filled_trap' and add a case to deal with that after testing all the
other conditions.
This results in distinct progressions with ps2write and thee files:
/tests_private/comparefiles/Bug689189.pdf
/tests_private/comparefiles/Clarke-Tate-Manns-Chinese.ai
The file /tests_private/comparefiles/Bug691775.pdf shows diffs that
are imperceptible by eye.
|
| |
|
|
| |
Thanks to Bruno Voisin for spotting this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we spot early on that that we can't create a complete copy of a font (i.e.
if the font is incrememntally defined), we discard the attempted complete copy
and set the "complete" pointer to the same as the "copied" (subsetted) pointer.
But it turns out that, later, there is also a code path that requires discarding
the "complete" font, which wasn't accounting for the possibility that the two
pointers pointed to the same font object.
So, we now check whether the two pointers are the same, and if so, we simply
null the "complete" pointer.
Fixes oddly hard to reproduce segfaults from the nightly and weekly tests.
|
| |
|
|
|
| |
If the font-specific glpyh name function returned an error then the
glyph name is not valid, don't attempt to use it!
|
| |
|
|
|
|
|
|
|
|
| |
In copy/pasting from one function to another, I had failed to
replace 'subfont' with 'font'. I thought tested this both
locally, and in the cluster. The cluster doesn't test this
file.
I can offer no such excuse for why my own local testing didn't
show it up. Apologies.
|
| |
|
|
|
| |
Not entirely sure when these became broken, but we now get results
in keeping with MuPDF's usage of extract.
|
| |
|
|
|
| |
The pgs doesn't change, and we only initialise once, so this
does the same thing, and is clearer.
|
| |
|
|
| |
Need to explicitly include extract src dir in the includes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #705865 "PDF Writer is dropping the /Alternate color space for ICC based color profile"
This commit starts off with the bug referenced above. Prior to this
commit the PDF interpreter never set the /Alternate space for an
ICCBased colour space. For rendering there is no need since Ghostscript
will always use the ICC profile, or will set the /Alternate instead
(if there is an error in the ICC profile) or will use the number of
components (/N) to set a Device space if there is a fault in the ICC
profile and no /Alternate.
However, this means pdfwrite never sees an Alternate space to write out
for an ICCBased space. This should not be a problem since the
/Alternate is optional for an ICCBased space and indeed the PDF 2.0
specification states "PDF readers should not use this colour space".
The file for the bug has a /ICCBased space where the /Alternate is
an Lab space. Obviously any PDF consumer should use the ICCBased space
but it seems that Chrome, Firefox, possibly other browsers cannot handle
ICCBased colour and so drop back to the Alternate. Surprisingly they
can handle Lab and get the expected colour. Obviously if we drop the
/Alternate then these consumers cannot use Lab and have a last ditch
fallback to RGB (based on the number of components, and that *is* in the
spec). But RGB != Lab and so the colours are incorrect.
Ideally we would simply use the existing colour space code and attach
the alternate space to the ICCBased space's 'base_space' member. That
would write everything perfectly well. But we can't do that because
when we are called from Ghostscript the ICC profile cache is in GC'ed
memory. So we have to create the ICCBased colour space in GC'ed memory
too. We have special hackery in the PDF interpreter colour code to do
exactly that.
Colour spaces call back to the PDF interpreter when freed (with more
hackery for ICCBased spaces), but if we create colour spaces in non-GC
(PDF interpreter) memory and attach them to the ICCBased space in GC'ed
memory then they can outlive the PDF interpreter, leading to crashes.
I did start down the road of making all colour spaces in GC-ed memory,
but that rapidly spiralled out of control because names needed to be
allocated in GC'ed memory, and functions and well, all kinds of things.
Without that we got crashes, and it quickly became clear the only real
way to make this work would be to allocate everything in GC'ed memory
which we really don't want to do.
So instead I added a new enumerated type member to the colour space, in
that member, if the current colour space is ICCBased, we store the type
of Alternate that was supplied (if any). We only support DeviceGray,
DeviceRGB, DeviceCMYK, CalGray, CalRGB and Lab. I also added the
relevant parameters to the 'params' union of the colour space.
In the PDF interpreter; add code to spot the afore-mentioned Alternate
spaces if present, and if we haven't been forced to fall back to using
the Alternate (or /N) because the ICC profile is broken. When we spot
one of those spaces, set the colour space ICC_Alternate_space member
appropriately and for the paramaterised spaces gather the parameter
values and store them.
In the pdfwrite device; if we are writing out an ICCBased space, and
it's ICC_Alternate_space member is not gs_ICC_Alternate_none, create
a ColorSpace resource and call the relevant space-specific code to
create a colour space array with a name and dictionary containing the
required parameters. Attach the resulting object to the ICCBased
colour space by inserting it into the array with a /Alternate key.
This also meant I needed to alter the parameters passed internally to
pdf_make_iccbased so that we pass in the original colour space instead
of the alternate space (which is always NULL currently).
There are also a couple of fixes; when finalising a colour space check
that the colour space is a DeviceN space before checking if the device_n
structure in the params union has a non-zero devn_process_space. The new
members in the union meant we could get here and think we needed to
free the devn_process_space, causing a crash.
In the PDF interpreter; there's a little clause in the PDF specification
which mentions a CalCMYK space. Apparently this was never properly
specified and so should be treated as DeviceCMYK. The PDF interpreter
now does so.
Finally another obsrvation; the initial code wrote the /Alternate space
as a named colour space, eg:
19 0 obj
<</N 3
/Alternate /R18 /Length 1972>>stream
....
Where R18 is defined in the Page's ColorSpace Resources as a named
resource:
<</R18
18 0 R/R17
17 0 R/R20
20 0 R/R22
22 0 R>>
endobj
But this does not work with Chrome (I didn't test Firefox). For this to
work with Chrome we have to reference the object directly, which should
not be required IMO. I believe this to be (another) bug in Chrome's PDF
handling.
|
| | |
|
| | |
|
| |
|
|
| |
Thanks to Michael Osipov for pointing this out
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #705476 "Some Russian letters disappear in PDF"
The problem here is quite subtle. We have multiple embedded TrueType
fonts which all have the same /FontName and so pdfwrite attempts to
'merge' the fonts into one, because it thinks they are the same font.
When the glyph cannot be embedded into the type 42 font we punt and
drop back to creating a type 3 font.
However.... Some of the glyphs in this file are compound glyphs, and the
first component can be added to the Type 42 font, but the second one
cannot. So we throw an error and don't add the second glyph, but we
leave the initial glyph in place. The error causes us to fall back to
type 3 for this glyph.
Then we encounter the same compound glyph again. Checking the font we
see that it is already embedded, and we don't check the components
because we assume that if we embedded the glyph we also embedded any
component glyphs. So we go ahead and use the embedded glyph and that
then fails to produce the correct outline.
When adding a component glyph to a font fails we need to 'unadd' the
initial glyph and any other components, so that we don't end up trying
to use any of them inappropriately.
For almost all fonts this is relatively straight-forward, but for
TrueType (type 42) fonts it is more complicated, so I've added another
member to the copied fonts procs so that we can have a specific method
for each font type.
So far the only case I've found is the TrueType font in this bug report
and since this has been present in the code forever it is clearly an
extremely rare case. Although I've added the code for the other font
types I'm not really able to test these terribly well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the display device with separations in chunky mode, we
insist on 8 components all the time.
In planar mode, the calculations go wrong, and we get crashes.
Update it here so that we don't crash.
Planar separations will use a maximum of 64 components.
In the case of a PDF file where the number of components in use
are known up front, we will run with the correct number of
components.
In the case of a PS file where the number of components is unknown
until rendering has completed, we run with the maximum number of
components, and the display device user can just take the required
number at the end.
|
| |
|
|
|
|
|
|
| |
The libtiff client was allocated using a different memory manager instance
than when it was freed - this coincidenally works when running gs, but segfaults
running gpdl.
Issue arose in the nightly regression tests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No bug, but the specimen file /tests_private/comparefiles/bug688967.ps
This turned up in weekly testing. The file output by ps2write was
producing errors. This (eventually) turned out to be because a type 3
font contained a CharProc which was using an ExtGState Resource which
was not in the /Resources dictionary of the Font.
Why this happens is not entirely clear to me, it doesn't with pdfwrite.
What seems to be happening is that we are only capturing the Resources
required for the font when we run the BuildChar. In this case we have
multiple instances of type 3 fonts which are using the same BuildChar
but only the first apparently has the full set of Resources.
Since we don't need to write stroke adjustment as an ExtGState for
PostScript, and PDF output seems to work correctly, just do it
differently for PostScript output and write the stroke adjustment
directly.
This is a fix for commit 95db9c543abdeb391d852aad7f0c5c419f808069 which
I hadn't realised seems to have actually added the ability to write out
stroke adjustment at all.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #706418 "Detect duplicate images with SMask"
We were not adding the SMask entry to the image dictionary until after
we had checked to see if the image (stream and dictionary) was identical
to a prior instance. The prior instance, of course, was written and
hashed with the SMask entry present, so the two instances never matched.
Fix by adding the SMask entry before we complete the image and check for
duplicates.
This exposed a bug in smask_image_check. The pointer to a character
being tested was never incremented, leading to an infinite loop, Clearly
this code was never previously being used.
|
| |
|
|
|
|
|
| |
This indicates that callers cannot assume that any calls to a
device will be clipped at device bounds. In particular the
alphabits device needs to set this as the width/height that
it uses are misleading at best.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No bug report for this one, the patch was submitted by Justin after a
conversation on Discord (#ghostscript, 11th February 2023).
The goal was to extend the 'NoOutputFonts' control, which turns all
text in a PDF file into linework, such that the decision could be
made based on the font name.
The supplied patch does so by adding two new controls, AlwaysOutline
and NeverOutline, which can only be set from PostScript (because
the font names are in an array). Text using fonts appearing in the
AlwaysOutline array will be converted to linework regardless of the
setting of NoOutputFonts. If NoOutputFonts is set to true, then text
using fonts appearing in the NeverOutline array will still use the
font, and will not be converted to linework.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #706353 " mswinpr2 device fails on printer names longer than 31 characters"
This commit was supplied by Bernd Watermann, so I'm not completely
competent to write the commit log. I believe the main chnages are
to use wide character versions of the API calls (and variables)
for better support of non-English printer names and because the
old version had a 31-character name limit.
I've tested this with the old bugs referenced in the report, a
regular cluster regression run (even though it does not test
this device, and by manufacturing and checking a number of
virtual printers with names intended to explore the limits.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #706407 "pdfwrite does not write /SA false unless it has previously been set to true"
The pdfwrite device only writes graphics state parameters which have
changed. The default value for the stroke adjust was set to false, so if
an input file set it to false, then pdfwrite would not write the value
to the output file.
The value is set to false because that is what the PDF Reference states
the default to be. However, it appears that Acrobat defaults to true.
This leads to different rendering for files which have /SA false and
files which do not set /SA. Interestingly at low resolution Ghostscript
also defaults to true.
The only way to deal with this is to have the initial value in the
viewer graphics state be neither true nor false. Then if an input file
never sets SA we will not write it, but if it does set it, no matter
what it gets set to, we will write it to the output.
This change results in a number of differences when cluster tested at
low resolution, and leads to a number of output files being reported as
increasing in size, naturally since we now write SA values when we would
not have before.
Checking the diffs we see that the files now match the rendering of the
original input file, whereas the file output by pdfwrite did not match
the original file, because the /SA false had been dropped.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The pdfwrite device can 'rewrite' the image matrixes in a
particularly nasty way that is not easy to avoid. It does this
to be able to capture images with masks of a different size.
Unfortunately, this breaks any possibility of us using the
imagematrix to figure out which source region of the image
we actually need for clipping.
Introduce a new flag to capture when this happens so we can
avoid relying on an untrustworthy imagematrix.
|
| |
|
|
| |
Mismatched function prototype warnings, and one uninitialised variable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #706128 "Scaling, translating, and writing text does not work properly with the new PDF Interpreter"
In fact all of these functions do work. The problem (or at least, the
problem I see) is that the original PDF file has a /CropBox entry for
the page, and this is automatically sent (via pdfmark) from the
interpreter to the pdfwrite device.
The result of this is that (when viewed using a consumer such as Adobe
Acrobat) the CropBox is used as a clip, and so the modified content
disappears outside the clip.
So, we need to be able to not send the various Box parameters to pdfwrite.
In fact, we already have a means to do that, and for exactly the same
reason, the Nup device needs to preven the CropBox being sent for the
pages too.
This is done by a device parameter 'ModifiesPageSize, which, along with
ModifiesPageOrder is always set for the Nup device to prevent Box
values, Outlines and Dests being sent.
This commit adds those parameters to the pdfwrite device; by default
they are false so that all the various pdfmarks are sent. A user can
either set them with -d on the command line or via setpagedevice in
PostScript.
When set ModifiesPageSize stops the interpreter passing along the
Box values, and ModifiesPageorder stops it passing along Dests and
Outlines.
Also fixed a typo in a comment, noticed in passing.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This started off with the file ContentStreamNoCycleType3insideType3.pdf
from the pdfa.org 'safedocs' project. We were not rendering the pattern
the way the documentation appeared to expect, nor the same as Acrobat.
The remainder of this commit log is lengthy....
To start with it was necessary to decide what we 'should' be doing
according to the specification, since Acrobat does not apparently do
what is expected. This is the text of my findings;
----------------------------------------------------------------------
The file consists of a single page whose content stream draws two glyphs
both in a type 3 font. One does nothing but draw a green triangle, we
can ignore that one and concentrate on the other.
The 'a' glyph from the type 3 font FType3A strokes a rectangle in red
and then draws three 'c' glyphs from another font. In this case another
type 3 font FType3B.
The 'c' glyph CharProc sets text rendering mode 2, a blue stroke colour
and a Pattern fill colour, and then draws the text 'ab' using the font
Helvetica. So we expect the 'ab' text to be outlines in blue and filled
with the pattern.
The Pattern sets the fill colour to magenta and then draws the text
'ba' using a font named CyclicFont which is an alias for Helvetica
again.
From page 422 of the 1.7 PDF Reference:
"Aside from the CTM, the graphics state is inherited from the environment
of the text-showing operator that caused the glyph description to be
invoked."
So looking at the first type 3 CharProc, we see that the gstate has text
rendering mode 2, the graphics state is otherwise the default (eg
colours fill=stroke=DeviceGray,0).
So we run the 'a' glyph from /FType3A which sets the linewidth to 20 and
the stroke colour to pure red and does a stroke:
20 w
1 0 0 RG
0 0 750 750 re s
We then draw the glyph 'c' three times from FType3B. This sets the text
rendering mode to 2, sets the line width to 10 and sets the stroke
colour to blue (0 0 1 RG). We then set the fill colour space to Pattern
and use Pattern P1. The Pattern draws the text 'ab'.
From step 2 of the pattern drawing sequence on page 294:
"2.Installs the graphics state that was in effect at the beginning of the
pattern’s parent content stream, with the current transformation matrix
altered by the pattern matrix as described in Section 4.6.1,
“General Properties of Patterns” "
So we have three possible 'parent' content streams at this point; the
Page, the first type 3 font and the second type 3 font. Depending on
whether we consider a type 3 font CharProc to be a 'content stream'.
Reading page 151 about content streams we see:
"Each page of a document is represented by one or more content streams.
Content streams are also used to package sequences of instructions as
self-contained graphical elements, such as forms (see Section 4.9,
"Form XObjects"), patterns (Section 4.6 "Patterns"), certain fonts
(Section 5.5.4 "Type 3 Fonts"), and annotation appearances
(Section 8.4.4 "Appearance Streams")."
So obviously each of our type 3 content streams is a 'parent' as far as
the Pattern is concerned. Therefore the graphics state the Pattern
inherits should be the graphics state at the time the 'c' glyph from
font FType3B is executed.
So starting from the beginning of the page content stream and continuing
until we get to the start of the 'c' glyph the following are encountered
(ignoring CTM changes)
2 Tr % Fill then Stroke Text render mode
20 20 Td
50 Tw
% start of 'a' glyph from font Ftype3A
20 w
1 0 0 RG
So the 'ab' text should be filled and then stroked (Tr 2), it should be
filled with Magenta (as per the Pattern explicit colour) and stroked
with red, because that's the stroke colour at the time the CharProc is
executed.
This does not appear to be what Acrobat does. It seems to be drawing the
'ab' text as a simple magenta fill. Which would only be possible if the
Pattern inherited the graphics state at the start of the Page, because
after that point all text is rendered in Text rendering mode 2. Removing
the '2 Tr' from the content stream for the 'c' glyph drops the blue
strokes, so it does indeed look like this is what is happening..…
Indeed, wrapping the original page content stream in a Form XObject, so
that we can control the graphics state at the start of the Form,
demonstrates that this is, in fact, exactly what Acrobat is doing. It
does not matter what the graphics state is at the start of the Form
(the parent content stream if we ignore the CharProcs), it still draws
the Pattern with the graphics state at the start of the Page.
----------------------------------------------------------------------
The reason this wasn't happening was because we had specifically coded
a hack into the type 3 CharProc processing which made the stroke colour
the same as the fill colour at the start of every type 3 CharProc. Why ?
Because that's what the old PS-based interpreter did, and it appears to
be what Acrobat does.
What was happening is that we were running a PCL file with the stick
font. That font, unlike 'normal' fonts, is always stroked, not filled.
That means that in PDF we need the colour that was set in the PCL file
to be the stroke colour, but the pdfwrite device was writing the colour
as the fill colour instead (because fonts are usually filled).
In fact you can get the same effect with PostScript input too, any input
where the act of setting a colour is expected to affect both stroke and
fill, but the text uses a stroke.
Acrobat draws the output from pdfwrite 'correctly', ie the same as the
PCL input, and the old PS-based PDF interpreter had been modified to do
so too, which is why we modified the pdfi interpreter the same way.
But in fact this is incorrect; Acrobat is clearly wrong in doing this,
though it is possible it only does it if the stroke colour is not
explicitly set.
So, in this commit we remove the hackery from the pdfi interpreter
which allows the safedocs file to run correctly. We also update pdfwrite
so that when writing the colour for a text operation if the font type
is 3 (might do any operation) we write the current colour as both the
stroke and fill colour.
It is just possible that we might need to take the text rendering mode
into account as well (might need to write the actual stored stroke
colour) but I'm going to wait until someone comes up with a test file
for that.....
This shows differences with a small number of files, some are tiny
text position differences (no idea why) and some are differences with
type 3 fonts and pdfwrite which seem to be progressions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #706116 "Segmentation fault when processing PDF with many vectors"
There are two problems here; first we should not crash, crashing is bad.
Fix that by initialising the PageHints and SharedHints to NULL and not
freeing the individual hints in the PageHints array if the array is
NULL.
The crash occurred because we got an ioerror from rewrite_object() and
that shouldn't happen either. This turns out to be because of an
optimisation. We expand the scratch buffer size as needed, and we use
that same buffer when writing out the modified object. But we were
always decreasing the amount left to write by the original size of the
buffer (16KB) even though we were writing > 512KB at a time.
Obviously this only happens with insanely large Form XObjects, 16KB is
normally enough to write any reasonable Form dictionary, and we only
expand the size if we need to write a larger dictionary.
|
| |
|
|
| |
... before returning the error.
|
| |
|
|
|
|
|
|
|
|
|
| |
Coverity ID 381906 this is actually a false positive from Coverity, we
can't restore the current_font, because we haven't saved it. Not only
that but the conditions under which we save and restore the current
font are different. We only do that for the fallback case and this is
a last ditch (and should never happen) error check.
But it makes sense not to corrupt current_font by assigning an invalid
font to it, so don't do the assignment until after the error check.
|
| |
|
|
|
|
| |
Promote previously windows specific functions to be
generically available (and give them names that
reflect that).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OSS-fuzz 53398 (and others)
Because xpswrite uses libtiff to write images to XPS files, and libtiff
won't offer us any way to use our memory manager, it is possible to
get a corrupted image which tries to use silly amounts of memory, which
leads to system memory being exhausted.
In this commit; change the gs_memory_status_s structure to include the
'limit' from the memory allocator. Alter the various allocators to fill
in the value (or set it to -1 if there is no limit). In the xpswrite
device calculate the amount of memory needed for an uncompressed image,
if it becomes negative we know we broke a 64-bit signed integer, so
abort. If it didn't go negative, and the memory manager has a specified
limit, check to see if the image will fit in that. If not return
VMerror.
This prevents at least some of the memory exhaustion errors with
xpswrite and OSS-fuzz, because OSS-fuzz sets -K to limit memory use.
|
| |
|
|
| |
Change the indenting to shut the compiler up.
|
| |
|
|
|
|
|
|
|
| |
In alloc_font_cache_elem_arrays() if we fail to allocate either the
glyph_usage or real_widths arrays, we free the other, and return an error.
But we weren't nulling the pointers, so if the function was called again (which
it is likely to be) we'd potentially "free" one or other pointer a second time,
causing memory corruption.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This started off with bug #706078, although the reporter did not
specifically mention this problem, and pdfwrite has always had this bug,
we'll fix it here.
The linearisation code was not updating the usage record for the 'final'
page in the output file. If that happened to be the only page then we
could write an invalid number to the page offset hints table, claiming
that the least number of objects on the page was 0, which it cannot be
because we include the page object, so there must be at least 1 object.
|
| |
|
|
|
|
|
|
|
|
|
| |
This came up while working on bug #706078; an intermediate version of
the fix for that code ended up writing 0x0a as '\012', the code in the
pdfmark handling spotted that and replaced it with '\n', which meant
the string needed to be resized.
The string resizing worked fine, but the code did not then alter the
actual 'size' member of the 'cos_value', so it ran off the end when
writing it out.
|
