| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This is the first part of making it possible to produce PDF/A-2b output from
pdfwrite.
The PDFA switch has changed from a boolean to an integer, where the value gives
the level of PDF/A compatibility. This has knock-on effects throughout the
C and PostScript code which has been revised to expect an integer instead
of boolean value.
When PDFA has the value 2 we no longer flatten transparency, and we write
'2' in the pdfaid field in the XMP metadata.
PDF/A-1b output still seems to work correctly, but it is unlikely that the
work so far is sufficient for correct PDF/A-2 output.
No differences expected as the cluster does not test PDF/A output.
|
|
Implement a missing case of Luratech JPX with components > 1, and
bps < 8. Also fix incorrect bit shift calculation in OpenJpeg
part.
|
|
This reverts commit 93bf2df8f6a6b2ed60a8c3f5037865b8646243db.
|
|
|
|
separations.
Previous to this commit the tiffsep device would always write out
an uncompressed composite file; the separation files were lzw
compressed by default and this could be changed via the -sCompression=
option. Now the compression of the composite file is the same as
that of the separation files.
Fixes Bug 692907.
|
|
HPGL handles paths slightly differently to the postscript imaging model.
When a path is filled, successive moveto's are treated as linetos.
(i.e. the 'place we close the path to' is left at the first moveto,
and the area remains fillable). Stroking is unaffected however.
To model this in Ghostscript we add a new path segment type 's_gap'.
The filling code treats this as a lineto. The stroking code is updated
to not stroke such edges (and not to break the subpath at this point).
We add a new parameter to the imager state (hpgl_fill_mode), new
accessor functions (gs_sethpglfillmode, gs_currenthpglfillmode),
and new postscript operators (.sethpglfillmode and .currenthpglfillmode).
If hpgl fill mode is set to a non-zero value, then path construction
treats movetos in an open subpath as gaptos.
Still to do:
* Double check the output from this code matches HPGL.
* Update the clist code to send hpgl fill mode changes.
* Update PDF write to spot such paths and to convert them as
appropriate when writing out.
|
|
Committed before VS had saved out. Sorry.
CLUSTER_UNTESTED.
|
|
Bring in Memento from MuPDF (where it has had some more tweaks
added). Fix the nested display code. Add hack to ignore prev/next
pointers in chunk blocks.
CLUSTER_UNTESTED.
|
|
Windows makefiles were failing to pass the MEMENTO flag down due
to some makefile wackiness.
CLUSTER_UNTESTED.
|
|
Bug #692884 "Empty Spotcolor Name in generated PDF"
The ink name wasn't being marked as 'in use' by the colour space structure
and so was being freed by a garbage collection, resulting in an empty name.
Robin Watts supplied this patch which allows us to *much* more easily mark
names as in use, and also kindly updated the colour handling as well.
No differences expected.
|
|
the imager state.
|
|
Cope with -r command. Add /Q flag to erase call (so it doesn't prompt
before deleting).
|
|
From investigations of a problem reported by customer 532.
When imaging a cached glyph, if the glyph bitmap cannot be inserted into the
clist tile cache, we'd normally resort to degenerating the glyph bitmap into
rectangles, and writing those to the clist. When the glyph is filled with a
tiling (Type 1) pattern, this means going through the pattern tiling code.
The problem is when transparency is involved (i.e. if the pattern is in a trans
group, or contains a transparency group) the tiling code cannot reliably
degerate to rectangles at this stage. This usually just works due to the various
fallbacks in the clist writing code and the glyph imaging code, but
occasionally glyphs can either disappear, or other problems occur.
This change makes us use that "fallback" route for all glyphs when we're
filling a glyph with a type 1 pattern, with transprency involved and we're
writing to a clist device.
NOTE: this is analogous to what the FAPI does in similar circumstances for
uncached glyphs.
No cluster differences.
|
|
e954dd4683c35dbd66de3e045d979ebbf20c4d72
Henry pointed out that my e954dd4683c35dbd66de3e045d979ebbf20c4d72
fix was incomplete; this commit replaces the remaining max_long
references with 2^32-1.
|
|
The TIFF spec limits files to 4 Gigs. The code to detect attempts
to write files that were larger than this in gdevtsep.c was broken
on systems were a long != 32 bit.
Fixes Bug 692896.
|
|
If the user params end up getting set during a vmreclaim
while we are in a swapped icc profile situation when
processing a softmask we were ending up freeing profiles
that should not have been freed. This issue was masked
by a check that was disallowing profiling settings in
the manager once they were already set. Also discovered
issues with a corner case where we have a softmask that
includes a pattern with a softmask.
|
|
Improve the distclean target so that the Memento obj and bin directory
contents are deleted and also remove the debug, pg, memento, and
production obj and bin directories.
|
|
When linking with a shared libjpeg library, don't include the non-public
libjpeg API hack to replace it's low level memory manager with Ghostscript's.
But still do so when using our "local" libjpeg source.
No cluster differences.
|
|
...so it uses the $(D_) and $(_D_) variables instead of -D directly.
No cluster differences.
|
|
Bug #692629. PCL TrueType fonts are missing some important tables for the
purposes of pdfwrite. In particular the CMAP table, which makes it impossible
to create glyph names.
This causes an error which *should* have resulted in pdfwrite falling back to
bitmaps. In the case of a single glyph, or a string where the fiirst glyph fails,
this did work correctly, but when one or more initial glyphs did work, the
calling code did not expect an error from TrueType fonts and failed to cope
properly by continuing to process the remaining glyphs.
Added TrueType fonts to the list which may error in this fashion.
Expected Differences:
AS40AOJ3.BIN
LW97DOJ2.BIN
SW108OJ2.BIN
VerdanaItalic.prn
bug689100.xl
bug689905.xl
All exhibit significant progressions (text was previously missing)
|
|
This reverts commit 43f3cdae4bdf00c09fdd69c53c03fb99d0b4aca1.
This caused unexpected changes in many postscript files. Reverting
until I can figure out why.
|
|
The XMP metadata Modification date was being written using the Creation
date instead of the Modification date.
No differences expected, metadata is not checked by regression tests
|
|
HPGL handles paths slightly differently to the postscript imaging model.
When a path is filled, successive moveto's are treated as linetos.
(i.e. the 'place we close the path to' is left at the first moveto,
and the area remains fillable). Stroking is unaffected however.
To model this in Ghostscript we add a new path segment type 's_gap'.
The filling code treats this as a lineto. The stroking code is updated
to not stroke such edges (and not to break the subpath at this point).
We add a new parameter to the imager state (hpgl_path_mode), new
accessor functions (gs_sethpglpathmode, gs_currenthpglpathmode),
and new postscript operators (.sethpglpathmode and .currenthpglpathmode).
If hpgl path mode is set to a non-zero value, then path construction
treats movetos in an open subpath as gaptos.
Still to do:
* Update PDF write to spot such paths and to convert them as
appropriate when writing out.
|
|
The code that set the system/user params related to ICC profiles was
contained in the zusparam.c file. This file is not used with the
other languages (e.g. xps and pcl). The functions that do the actual
work have been moved to gsicc_manage reducing any code duplication for
the other languages.
|
|
The XPS interpreter was still using Device color spaces for its default
color spaces. This fix has it use ICC color spaces by default which
is required by the spec. This revealed an issue with the color space
handling of the opacity masks. These were getting drawn in sRGB color
space but the transparency group is linear gray. Since we are drawing
the opacity mask as a luminosity mask that is gray we ended up
mapping through a nonlinearity.
|
|
Reject setcachedevice arguments that are too big and, probably, invalid.
The threshold, 32000, is arbitrary. Normal fonts have the values about 1000.
|
|
Fix packing of multi-component color values with bps < 8 into the
output stream. This results in progressions on Bug691843.pdf, and
minor differences in Bug690147.pdf
|
|
Thanks to Peter Skarpetis for finding this.
|
|
WMB1102317A01.pdf (supplied by a customer) shows a problem with
Interpolation of Index colorspaces.
Specifically, we have an Indexed DeviceGrey space (which is, in
the new world order, an Indexed ICC space, with 1 component).
At line 678 of gxiscale.c we correctly detect that pcs->type->index
is Indexed, and therefore use the base space as the 'actual' space.
At line 683 we find the concrete space (which in this case is
exactly the same space). We then decide whether we are working in
an icc world, or a device_color world by checking for the presence
of icc data. The old code used to (incorrectly) check pcs (the
indexed space), when it should really have checked the concrete
space.
The remaining changes in the code are purely tidying:
* avoid calling concrete_space a second time (when pconcs already
holds the answer)
* pass pconcs as an arg when calling pconcs->type->remap_concrete_color
rather than pactual_cs. At that point pactual_cs and pconcs must
be identical, but it's nicer to be consistent.
This produces 3 differences in the cluster tests, all in the cups
tests. These can be reproduced locally using tiffsep.
comparefiles/148-11.ps.cups.300.1
Definite progression
PDFIA1.7_SUBSET/CATX1028.pdf.cups.300.1
Looks like progression to me
ps/ps3cet/12-07B.PS.cups.300.1
Definite progressions on page 12-15. A problem still exists on
page 12 though, but that's unaffected by this change.
|
|
Currently we just raise a rangecheck, which can be very confusing.
CLUSTER_UNTESTED.
|
|
A second list of compressed colors was recently added to the
gdevn_params structure, but this wasn't added to the garbage
collection routines. Fixed here.
|
|
If we find we are scaling an image to be zero width or
height, handle the image without interpolation.
|
|
A previous commit (cf37ea5) changed the prn device macros to
duplicate map_color_rgb/map_rgb_color to encode/decode_color.
I thought this was safe as the default color encoding/decoding
functions were actually implemented as encode/decode, rather
than map_ variants.
Unfortunately, this falls down when other devices (such as the
tiffscaled ones) provide genuine map_ functions rather than
encode/decodes.
So, a small tweak to the macros is required; we now duplicate
to encode/decode only if specifically told to - and the macros
that use the defaults specifically say to. Other devices should
remain unchanged.
|
|
This commit puts into place the c-code for making use of an
ICC profile stream from the PDF interpreter for setting of the
output intent. This is done through the use of zset_outputintent.
This function will make the various settings of the icc profiles
in the device and in the icc manager based upon the process model
of the target device and the icc profile of the output intent. It
will be up to the interpreter to make the call to .set_outputintent
with the proper output intent ICCBased dictionary on the top of the
stack. This should be done in the interpreter after the device has
been set up and all the default ICC profiles are in place. The
interpreter should make the call if we have specified -dUsePDFX3Profile.
The first output intent that is present in the file should be used,
unless someone specifies a different intent through the use of
–dOutputIntent=x . In this case, the x+1 output intent (if it
exists) will be used. Note that if the particular output intent does
not include an ICC profile entry (DestOutputProfile), then the output
intent will not be used. In this case, we will eventually want to
specify what the OutputConditionIdentifier was for that particular
intent if it was missing the DestOutputProfile.
|
|
When clipping the region to be used for an image plot, reduce the
rectangle by the outer box of the clipping path before checking to
see if a clip is needed or not.
This enables us to avoid a clipping device in more cases.
|
|
At the moment, prn devices do not implement encode_decode/color,
choosing instead to provide map_rgb_color/map_color_rgb which
just get called through a 'backwards compatibility' layer.
In fact, they actually implement encode/decode_rgb rather than
map_rgb_color/map_color_rgb, so we just copy the entries here.
No changes expected in cluster.
|
|
CLUSTER_UNTESTED
|
|
enumerator is in local VM
As described in the bug, it seems to be technically possible for a local font to be
referenced from a show enumerator. If the enumerator is in global VM this
causes a garbage collector crash.
This code modifies the PostScript 'show' family of operators so that the
enumerator is always allocated from local VM, avoiding the problem.
There is no specimen or method of reproduction supplied in the bug report so
this is rather speculative, however it runs a cluster test without problem.
If it does cause any problems we should simply revert this change.
As part of this change it was noticed that there are a number of procedures
defined in gschar.c which are apparently dead code and these have been removed.
No expected differences.
|
|
conversion
Some of the PDFSETTINGS collection of settings set the ColorConversionStrategy
to spaces which may not be possible (in the current architecture) to convert
every colour space into. For example ICCBased spaces. This causes a fairly
incomprehensible error to be thrown.
In future we intend to do a better job with colour taking advantage of the
built-in colour management, but for now we simply choose to change the
ColorConversionStrategy to 'LeaveColorUnchanged' and emit a warning.
Bug #692030 and Bug #692108
No Expected Differences as this is not tested by the cluster
|
|
When filling a mask, check any clipping path given; if it trivially
includes all the mask, then don't bother creating a clipping
device. If it trivially excludes, then don't bother plotting at all.
If the bbox partially covers the area, then reduce the area
of the mask.
This gives a 6-8% speedup of customer 532's test files; they are
filling a mask with a halftone, which breaks down into lots of
short run, 1 pixel high rectangles. Avoiding the clipping device
avoids lots of function call overhead.
|
|
Investigation of customer 532's problem files lead Ray to
spot that we are blowing away the color clues on every call to
image_render_mono (called for every scanline in an image at
least), rather than just once per image.
Here, therefore, we change to call image_init_clues in
gs_image_class_3_mono (the function that returns image_render_mono)
rather than in image_render_mono itself.
|
|
Back in 2002 code was committed (as part of the DeviceN work) that
removed the halftone cache from the image state. The last vestiges
of this were functions:
gx_check_tile_cache_current
gx_check_tile_cache
gx_check_tile_size
All these were hardwired to return a constant value, but the calls
to them were never removed from the code.
Here, we remove those calls. No differences should be given.
|
|
Commit 75ff1314c3de8fb5df702211b6effb6df2b87faa broke building against the
system zlib by adding an explicit dependency on a file in the "local" zlib
source directory.
Ensure that dependency only applies when building non-shared zlib.
Also, at some point, the mkromfs with shared zlib has been broken, so fix that
by passing the "-lz" option to the CCAUX compiler variable.
No cluster differences.
|
|
|
|
Patterns inside patterns were not working properly, because PDF and PostScript
handle this differently. opdfread.ps resets teh graphics state CTM to the
identity when drawing patterns, because the PDF spec says patterns are always
referenced to the default co-ordinate space and in order that the matrix gets
applied correctly we need to reset the CTM.
However, when the pattern is inside another pattern, the defualt co-ordinate
space is that of the enclosing pattern, so restting the CTM is a problem. We
can't simply avoid the reset as normal patterns would stop working. We can't
'undo#' the pattern matrix in PostScript, because we don't know what the
resolution scaling was.
So we track the pattern depth in ps2write, and the accumulated matrix transforms
from all the patterns so far. Then we apply that accumulated matrix to any new
pattern when the pattern depth is not zero.
This works, but is not 100% reliable, 2 patterns inside a single parent would
be concatenated, resulting in the second pattern being incorrect. However the
nested pattern situation is rare enough that I'm going to leave this as it is.
Expected Differences:
09_47N.pdf
Bug6901014_org_Chromium_AN03F.pdf
these files now work correctly with ps2write.
|
|
When I brought the Makefile into line with convention for some of the FLAGS
variables, I forgot to add the new 'AC_CFLAGS' value to the subtarget for
the dynamic library build.
No cluster differences.
|
|
If a proofing profile or a device link profile are
specified, the link transform is more than likely not going
to be identity. This fix ensures that the transform
is properly applied.
|
|
add error handling.
The device link profile handling was put in place when we had lcms 1.8 but was not ported
over to the 2.0 interface.
|
|
Picked up by scan-build; presumably this only gets run for commits, not
for regular cluster tests as it didn't show up previously.
|
|
Previously we handled ICCbased spaces by pretending they were device spaces
with the same number of components as the ICCBased space. This works
suprisingly well, but fails utterly for Lab spaces where images come out
completely incorrect.
We now convert the image data to the current device space. We do not yet handle
vector colour spaces, this will be handled by a future rewrite of the colour
handling to permit much better control over colour space handling.
This change causes quite a number o differences in the regression suite.
These fall into one of 4 causes:
1) Colour space conversion; previously ICCBases spaces with 1 or 4 components
would be handled as grey or CMYK respectively. They are now converted to the
device space (RGB by default). This causes some colour changes, especially
in halftoned output with a 1 component space. These are not incorrect as can
be seen from the contone output
2) There are some minor shifts in colour caused by correctly handling the
ICCBased space, in general these are progressions (especially the Altona
suite).
3) Handling of Lab colour spaces. These now work correctly where previously
they did not. Especially catx4929.pdf and IA3Z3476.pdf
4) Honouring rendering intents. Files hwich used a rendering intent now are
correctly converted. cf Bug #691926, comment 3.
5) There seems to be a possible problem with converting some CalRGB spaces,
the resulting output seems 'blue' with respect to the Acrobat otuput. In the
case of 1 file which contains scanned images of books, it is clear from the
original book covers that the output is incorrect. Michael suggest this may be
a White POitn problem. A separate bug report will be filed for this. Ghostscript
rendering of the original matches the ps2write output.
|
