| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
This is needed for the pdfi interpreter.
|
| |
|
|
|
| |
If we fail to allocate even the graphics libaray graphics state, bail out
immediately.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The comments in zinitgrpahics and the PostScript definition of
initgraphics in gs_cspace.ps were incorrect, now that gs_initgraphics
does reset the colour space properly.
However, we do still need the /initgraphics override in gs_cspace.ps
in order to correctly set the colour space which we store in the
'interpreter' graphics state. We only use that to hand back in response
to a currentcolorspace, but we do need it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Firstly, remove the kludgy gs_initgraphics_no_cspace() and have the
PostScript operator zinitgraphics() call gs_initgraphics().
This meant fixing the gs_initgraphics routine; the previous commit
d527031607a881237819835c2b1045c81e24c387 simply overwrote the existing
colour spaces in the graphics state with the new DeviceGray space. This
could lead to memory leaks if the previous colour space had been
reference counted up. So now we call gs_setcolorspace instead, which also
correctly sets the current colour.
This led to the interesting discovery that the null brush in PXL has
never been handled properly by the high level devices. This is
handled by the PXL interpreter setting a DeviceGray colour space, and
then directly editing the device colour 'type' field and setting it to
'typ_null'. This doesn't seem like the best way to proceed to me, I
would have expected us to push the nulldevice, but its what is done.
No in gx_hld_is_hl_color_available() the code simply tested whether
the device color 'ccolor_valid' flag was set. Since the PXL interpreter
simply stomped on the type field, and did not update any of the other
fields, the result of this was unknown. Sometimes we would decide it
was valid, and sometimes not. If we did decide it was valid then we
used the DeviceGray space and colour (0, black) which was also set up
by the null brush code to draw the object, which means that we could
end up drawing objects which should not be drawn.
'Fixed' this by having the code explicitly test for the device color
type being 'null' as well as being valid. In passing, it did appear
to me that we do not always update the ccolor_valid flag in the device
color structure, which may well lead to more problems of this kind.
This does result in a number of differences in the output. Mostly
these are due to the error page now always being rendered in DeviceGray
which results in a slightly (invisible) difference in printed gray text.
A very large number of the Quality Logic files exhibit progressions
due to the fact that we are now correctly processing the null brush.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At some time in the past gs_initgraphics was altered for 'colour substitution'
so that it did not reset the colour space and current colour. This is
surprising because the PostScript initgraphics operator is supposed to
do exactly that.
Restoring the code resulted in many seg faults with the PDF interpreter
so this is obviously a requirement, even though I can't see why.
However, leaving gs_initgraphics as it is would mean that (as per the
comment above the procedure) that all the interpreters (clients) would
have to reset the colour space and colour after calling it, which is
entirely unreasonable. Not only that, it hasn't been done leading to
the PXL interpreter printing error pages in the wrong colour.
This commit restores the setting of the colour space and colour to
gs_initgraphics, but introduces a new gs_initgraphics_no_cpsace()
procedure to be called from zinitgraphics, which behaves exactly as
the modified gs_initgraphics did, and does not set the colour space
or colour values.
The PDF interpreter now continues to work and the PXL interpreter now
prints a number of error pages in black where it previously was using a
pattern, grey or in one case green colour.
|
| |
|
|
|
|
|
|
|
| |
Also update copyright dates.
Remove gs_cmdl.ps as we no longer use it, and remove its entry from
psfiles.htm.
Remove xfonts.htm as this feature (xfont support) is long, long gone.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #698619 "PDF 2.0 tests 'zero sized text'"
The PDF 2.0 specification permits font scale of 0 (!), but nothing
should be rendered....
We can't have a font scale of 0, because it breaks our arithmetic, so
we set it to a tiny value, unfortunately this still means that stroking
text rendering modes printed some small garbage.
After a lot of effort with the PDF interpreter, I concluded that there
was no reasonable way to address this in PostScript, as we didn't
retain the font size anywhere and had no reasonable, non-volatile,
place to store it (it needs to respect gsave and grestore).
So in the end I added it to the graphics state and created two new
operators to read and write it (and undefined them after startup).
Its an unfortunately brute-force approach, but it has the benefit of
actually working.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #696511 - "Move ExtGState parameters into the regular graphics state"
A long time ago a decision was made not to replicate the PDF ExtGstate
parameters in the graphics state. This has had long term painful consequences
because we were unable to do a gsave/grestore to simply preserve
parameters but had to jump throuhg a lot of hoops. Amongst other problems
has been confusion over when exactly a change in colour has taken place.
With this commit the ExtGState parameters are moved into the graphics state
and obey gsave and grestore.
This extensive commit was worked on in the PDF_gstate branch and the history
is preserved in that branch.
This does introduce a few differences in the test suite;
There are a few cases where broken files (recursive SMasks) now render
slightly differently.
Some files now exhibit progressions, especially with CMYK or DeviceN output
devices, this is because the 'default' colour space was incorrect, the code
was using DeviceGray instead of the device's colour space, and this makes
a difference for some types of transparency blending when the Group does
not specify a Blending space.
A few other files demonstrate progressions because a change in colour now
takes place before an error occurs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change how gstate initialisation is done:
Previously we relied on the imager state being a subset of the gstate (thus
assigning an imager state to a graphics state over wrote to the entries
common to both, and didn't overwrite any already set graphics state specific
entries).
Making the imager and graphics states the same means that approach doesn't work,
so this changes it to initialise the entries individually.
Renames gsistate.c->gsgstate.c and gxistate.h->gxgstate.h
Cleanup and fix the gs_state gc stuff.
Uses different check for pre/post clist pdf14 device
Previously, the code used "is_gstate" in the imager/graphics state object
to determine if the code was being called pre or post clist (post clist would
only ever have had an imager_state so is_gstate = false).
With no imager state any more, that test would no longer work (and I am dubious
about whether it was really safe, anyway). Other places check for the presence
of a clist reader device in the pdf14 device structure - so use that here
too.
Adds initial (NULL) value for show_gstate pointer in gs_state.
Removes the now pointless macro for the contents of the graphics state
Changes function names that had "imager" to use "gstate"
Removes the redundant 'is_state' flag
Cleans up gs_(g)state_putdeviceparams():
Previously we had to similar routines: one took a graphics state, and used the
device from the graphics state, the other took an imager state and the device
as an explicit parameter.
With the removal of the imager state, "merge" those two functions
Replaces gs_state with gs_gstate
It makes for less confusion as it really is a g(raphics)state
|
| |
|
|
|
|
|
| |
This does actually lead to a memory leak, but there is equivalent code
below (allocating prci) which potentially leaks in exactly the same
way, so I'm going to ignore the leak. A real VM error will quickly
cause the interpreter to exit anyway.
|
|
|
Squashed into one commit (see branch for details of the evolution of the
branch).
This brings gpcl6 and gxps into the Ghostscript build system, and a shared
set of graphics library object files for all the interpreters.
Also, brings the same configuration options to the pcl and xps products as we
have for Ghostscript.
|
