| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If for a job a custom page size is selected, indicated by something
like "-scupsPageSizeName=Custom.4x8in" or "-scupsPageSizeName=Custom",
do not try to match the requested page size, given by standard
Ghostscript parameters like
"-dDEVICEWIDTHPOINTS=... -dDEVICEHEIGHTPOINTS=...", with the supported
page sizes defined in the PPD file.
This avoids unwished rotations as reported in
https://github.com/OpenPrinting/cups-filters/issues/484
and also unwished size mismatches if the custom size is very close to
a size defined in the PPD file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PPD (PostScript Printer Description) files are deprecated for many
years now, after having PDF-based printing for more than a decade and
will finally get abolished completely with CUPS 3.x due end of
2023. Instead, printing will get completely IPP-based.
cups-filters is currently prepared for the transition to this New
Architecture of printing and this requires some changes in the
Ghostscript output device driver (cups/gdevcups.c) for accesing all
parameters without the need of a PPD file. These changes are done with
this commit.
For this the following new command line options got added:
CUPS Raster version (compression)
---------------------------------
The integer option "-dcupsRasterVersion=X" determines whether CUPS
Raster output is compressed (X = 2) or uncompressed (X = 3, the
default). This only applies to CUPS Raster ("-sDEVICE=cups",
MediaClass != ¨PwgRaster") and not to PWG Raster or Apple Raster/URF.
This option is equivalent to the "*cupsRasterVersion" PPD file
keyword.
Back side orientation for duplex printing
-----------------------------------------
The string option "-scupsBackSideOrientation=X" with X being one of
"Normal" (the default), "ManualTumble", "Rotated", or "Flipped" tells
the orientation of the back side raster images when printing
double-sided. Many printers feed the paper in another direction for
printing the back side and so for example start the printing at the
bottom of the page and not at the top, to make the duplexing mechanics
simpler, smaller, and cheaper. See
https://openprinting.github.io/cups/doc/spec-ppd.html#cupsBackSide
for the meaning of the orientations. This option is equivalent to the
"*cupsBackSide" PPD file keyword.
Flipping top/bottom margins on back sides when printing duplex
--------------------------------------------------------------
The boolean option "-dcupsBackSideFlipMargins" tells that when
printing double-sided for the back sides the top and the bottom
margins need to get swapped. See
https://openprinting.github.io/cups/doc/spec-ppd.html#APDuplexRequiresFlippedMargin
for more information. This option is equivalent to the
"*APDuplexRequiresFlippedMargin" PPD file keyword.
Manual copies needed
--------------------
The boolean option "-dcupsManualCopies" makes the raster image be sent
repeatedly for printers which cannot generate copies internally.
This option is equivalent to the "*cupsManualCopies" PPD file keyword.
Note that if you supply both a PPD file (via "PPD" environment
variable) and use these new command line options, the values defined
in the PPD file have priority.
|
| |
|
|
|
|
| |
Also cups device: Ignore deprecated function warnings
Using gcc pragmas
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apple Raster (aka URF) output: With -sDEVICE=appleraster or
-sDEVICE=urf (instead of -sDEVICE=cups) the output is in the Apple
Raster format and not in CUPS Raster format.
The format is used by Apple's AirPrint which allows printing from iOS
devices. Due to this practically all modern printers understand this
format and so providing it allows easy, driverless printing.
Before, in order to output Apple Raster, the gstoraster filter of
cups-filters had used the "cups" output device of Ghostscript to
produce CUPS Raster and after that the rastertopwg filter of CUPS had
to turn this into Apple Raster. With this commit a future version of
cups-filters can let gstoraster (the ghostscript() filter function)
directly output Apple Raster and this way save one filter step.
Outputting Apple Raster instead of PWG Raster (which we could already
do via -sDEVICE=pwgraster) is trivial. One has only to tell the
cupsRasterOpen() function of libcups to write Apple Raster headers
instead of PWG Raster headers by a simple flag, so this commit
consists mainly of the definition of the output device names
"appleraster" and "urf" and make the output device set said flag when
one of these device names is used.
I have defined two device names for exactly the same thing, as I am
not really sure which one is the better or if one could cause any
problems. We could remove one later if needed. The output is
absolutely identical for both.
Apple Raster support was introduced to libcups in CUPS 2.2.2, so the
CUPS 2.2 API does not contain it necessarily, therefore the 2.3 CUPS
API is the minimum requirement by the ./configure script to build
Ghostscript with Apple Raster/URF output support.
The libcups which is included with the Ghostscript source is too old,
and when you build with it (--with-local-cups) you will not get Apple
Raster support. But remember that this build option is only for
development and debugging and not for production.
The commit also contains a bug fix: devs.mak hard-coded -I./cups/libs/
in the compilation command line of gdevcups.c, making always the
included cups/raster.h being used instead of the system's one and so
always having a too old cups/raster.h which suggests that Apple Raster
is not supported. This I have fixed by removing the -I./cups/libs/,
--with-local-cups works also without.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, devices would call 'get_color_mapping_procs' to get
a procedure table from a device. They would then call those
procs, passing in the device as an argument.
For forwarding/subclassing devices, this is problematic, because
getting a child device's color_mapping_procs, and passing it a
parent's device pointer will lead to failures. Accordingly lots of
wrapping functions have to be written.
Here we try an alternative formulation. When we
'get_color_mapping_procs' we get both the procedure table, and
the device pointer to pass to them. For most devices this will
be the incoming device pointer parrotted back. For forwarding
and subclass devices, it will be the appropriate child device.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The device initialize function currently performs 2 jobs. Firstly,
it fills out the device_procs. Secondly, it performs any minimal
initialization required by the device (typically none).
At various points in the code we want to be able to copy procs
from one 'prototype' device to another, so we call initialize
for that. This populates the device procs, but does other work
that typically requires a 'derived device' structure rather
than a vanilla gx_device to work in.
Accordingly, we split the job into two; initialize_device_procs
(the first part) and initialize_device (the second part). The
initialize_device_procs function will set up the initialize_device
function pointer along with the rest if required.
|
| |
|
|
|
|
|
|
|
|
| |
Move the initialize procedure out of the device procs table,
and into a bare function pointer at the start of the device proc.
Devices just initialise this, and the rest should fall into place.
This means changes to the device instantion macros (and all the uses
thereof), but makes the code nicer overall. In particular, this
removes the vestigial 'static_procs' structure.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
It used to be that finish_copydevice(dev, const old_dev) would be
used to copy stuff from a prototype to a new instance of a device.
Now, no copying is ever done.
Also, it's a confusing name. Rename it to be 'initialize', which
is clearer. Also, it should become even more appropriate in
future, if we have this function be the one that is responsible
for filling out the procs.
|
| | |
|
| |
|
|
|
|
| |
The cups source has shtml documentation dotted through it, and that references
images in the "images" directory (which we removed originally, thinking it
wasn't necessary).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the capability to simulate overprint including that of
spot colors for all devices including gray and RGB devices. This
is achieved by having the PDF interpreter look if overprint
is present, the seting of -dOverprint (/simulate /enable /disable),
if the page has transparency, and if the page has spot colors. Depending upon
the color model of the device, and if transparency is present,
a special push of the pdf14 device may occur. The pdf14 device
buffer collects the data in a CMYK or CMYK+spots buffer and the
put_image method in the pdf14 device will map the buffer to
the target device color space. The code was tested with
devices that support and do not support spot colors, those that
support and do not support alpha channels, tag based devices,
gray, RGB, and CMYK devices. A special test file to check
multiple cases was added to the regression suite. By default
-dOverprint is set to /enable, which should result in the existing
behavior where by RGB and Gray devices do no show overprint or spot
colors and CMYK devices will handle CMYK overprinting and separation
devices will show spots and overprint of all colorants. With
-dOverprint set to /disable no device will show overprinting. With
-dOverprint set to /simulate all devices will show overprint and
spot colors. Ray Johnston did the work in the interpreter as
well as the device parameter default setup. I did the pdf14 device
changes and testing. Changes in a variety of locations were required
due to the fact that new combinations were encountered, for example
we had cases where devn colors were being used with a device that
supports tags (bitrgbtags device and pdf14 compositor setup for CMYK+spots).
One file:
tests_private/xps/xpsfts-a4/fts_34xx.xps.pdf ppmraw 72 now produces
an error. This file should have been throwing an error all
along but was being quietly swallowed. Acrobat will not open
the created pdf file and throws and error. I will open a bug
for the issue as it is a problem with the XPS interpreter.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The gdev_space_params structure is also known as gdev_prn_space_params,
which is slightly misleading as there is nothing prn specific about
it.
Rename all uses of gdev_prn_space_params within the code to be
gdev_space_params. Leave gdev_prn_space_params defined as a typedef
so that any customer code will not be affected.
Rename compare_gdev_prn_space_params to be gdev_space_params_cmp
to better reflect its non-prn-specific nature. Make it non-static
and move it to gsdevice.c.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Plus makefile updates to support it
Bug 701288: Handle SEAC ligature glyph metrics correctly.
As originally intended, a Type 1 SEAC charstring would be used for an accented
glyph (like an a-caron, or u-umlaut) where the advance with of the SEAC glyph
is the same as that of the 'base' glyph ('a' or 'u').
It this case, it is not uncommon for the SEAC to skip using an (H)SBW op code
and rely on the one from the base glyph.
But out of spec fonts also use SEAC glyphs ligature glyphs (like 'oe' or 'fi'),
and in those cases the overall advance width is greater than that of the 'base'
glyph.
In this case, we have to allow for the SEAC glyph having included an (H)SBW and
if it has, retain those values, rather than those from the base glyph.
Rename file and make file change to match
Avoids file name clash with freetype 2.4.10
Work around a change in the zlib API for 1.2.11
where it's used in the Freetype/zlib interface debugging code.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Our support of CMY devices is currently not ideal with
respect to proper color management and the transparency
imaging model as described in Bug 697965. My plan is
to make a psd cmy based device and get things working
properly in terms of spot colors and ICC color management.
This will take a bit of effort and likely have a bug
tail. For now for Bug 701625 an easy solution is to
treat the color space as additive. In this case, the
output looks reasonable.
|
| | |
|
| |
|
|
|
| |
This change lets complete LUTs in the debug output only be listed when
CUPS_DEBUG2 is set and not already with CUPS_DEBUG.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without special scaling/cropping options ("fit-to-page", "fill",
"crop-to-fit΅, ...) PDF and PostScript files printed with CUPS will be
printed with the page sizes of the document's pages and not the size
requested by the user via the "PageSize" or "media" option. This
allows correct printing of jobs with differently sized pages on
printers which have the appropriate sizes loaded without need of
manual intervention. Therefore the CUPS output device is matching each
input page against the sizes listed in the PPD to generate a correct
page geometry for the printer for each page.
Problem is if there are several equally-sized page size entries in the
PPD. Without further guiding always the first match is used, making
access to special functions provided by the others (like
full-bleed/borderless printing) inaccessible.
This commit adds the functionality of the user-requested page size
(via "PageSize" or "media" option) being preferred under the matching
page sizes, so that if for example a user selects a full-bleed version
of the desired page size and sends a photo, the photo gets rendered
and printed with the page geometry which the PPD reports for the
full-bleed version.
Nothing changes if the size of the user-requested page size does not
match the size of the input page at all.
|
| |
|
|
|
|
|
| |
This is a fix for one little oversight on the changes to support matching
the input page size against the imageable areas of the PPD's page sizes.
This completes the fix of bug 701438.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Applied the following improvements for finding the correct page size
of the PPD file for the input page:
- Do not try to match by page size name, the input files do not
contain page size names.
- Do not only match the input page size against the actual media sizes
reported by the PPD but also to the imageable areas. Media size match
is preferred but if there is no media size match, we accept also
a match of the imageable area. In case of a match of the imageable
area we position the input page in the imageable area of the output
page.
- More debug output.
- In case of a custom page size (no match with PPD sizes) the page
size name in the CUPS Raster output is a correct "Custom.XXXxYYY"
and not the default page size name.
This should fix bug #701438.
|
| |
|
|
|
|
|
| |
Before each page gets rendered its size is compared to the page sizes
of the PPD file to select the actual page size for the output. Reduced
the tolerances from 7% for the long edge and 5% for the short edge to
1%, as before easily wrong sizes got picked (See also bug 701438).
|
| |
|
|
|
|
| |
When building with CUPS_DEBUG now debug output for the process of
matching the page geometry with the PPD file's page sizes is
produced.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(squash of commits from filesec branch)
Most of this commit is donkeywork conversions of calls from
FILE * -> gp_file *, fwrite -> gp_fwrite etc. Pretty much every
device is touched, along with the clist and parsing code.
The more interesting changes are within gp.h (where the actual
new API is defined), gpmisc.c (where the basic implementations
live), and the platform specific levels (gp_mswin.c, gp_unifs.c
etc where the platform specific implementations have been
tweaked/renamed).
File opening path validation
All file opening routines now call a central routine for
path validation.
This then consults new entries in gs_lib_ctx to see if validation
is enabled or not. If so, it validates the paths by seeing if
they match.
Simple C level functions for adding/removing/clearing paths, exposed
through the gsapi level.
Add 2 postscript operators for path control.
<name> <string> .addcontrolpath -
Add the given <string> (path) to the list of paths for
controlset <name>, where <name> can be:
/PermitFileReading
/PermitFileWriting
/PermitFileControl
(Anything else -> rangecheck)
- .activatepathcontrol -
Enable path control. At this point PS cannot make any
more changes, and all file access is checked.
|
| | |
|
| |
|
|
| |
The RGBW color space needs to have the white value mapped properly during the encode process.
|
| |
|
|
|
|
|
|
|
|
| |
The cups device has a pile of different color spaces. It is up to the cups device to
ensure that the color is handled properly for these. RGBA should certainly be treated
as a 32 3 component color similar to our pngalpha device. RGBW will be treated the same way.
Note that I looked at the output using Mike Sweet's rasterview program. I suspect there
probably is some work that needs to be done on that viewer to ensure proper viewing of
this type of data. With this patch gs is doing all it can.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Custom device LeadingEdge logic in complicated as it potentially requires
equivalent changes to changing the page size.
For a device like cups which merely wants the LeadingEdge value stored in its
own place it makes much more sense to allow the Ghostscript 'core' to handle
all the logic (which it has to do anyway to ensure the rendering is correct),
and then just copy the value into the cups specific place.
This saves the problem, as in this case, of unexpectedly ending up with two
LeadingEdge parameters being included in a call to put_params.
|
| |
|
|
|
|
|
|
|
| |
Give the range of color spaces and models that cups supports, we can't
reasonably provide (or expect others to provide) output ICC profiles for all
cases.
For the purpose of profile validation, have it claim to be DeviceN and benefit
from the extra tolerance in profiles allowed for that class of device.
|
| | |
|
| |
|
|
|
| |
Somehow a few lines of code were duplicated, fortunately this was
benign, but lets remove the nonsense lines anwyay.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Because -dLeadingEdge=# sets the value in systemdict, we need to return
this parameter from gx_default_get_param and gx_default_get_params so that
the systemdict value will get sent to the device (putdeviceprops).
Also found that the JPEG device was using LeadingEdge, but not stripping
off the "LEADINGEDGE_SET" bit. Fix by anding with LEADINGEDGE_MASK.
Lastly, the cups device put_params needs to be able to accept a null
parameter type as the default put_params can.
|
| |
|
|
| |
bitmap of the full page, ignoring any unprintable margins suggested by the PPD file.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
|
| |
There are locations in the code where Coverity has complained about
code logic that resulted in passing of unintialized values that
could only occur if num_components < 0 . Since this should never
be the case, we will make it clear by setting num_components and
max_components to uchar. This will limit our support to 256 colors
by a device.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original fix replaced uses of strdup() (which caused a memory leak) with
a dynamically allocated temporary string which was freed at the end of
cups_get/put_params().
Unfortunately, as param lists simply take a reference to the key string, this
meant that the contents of the string were overwritten, and indeterminate
after being freed.
Switch to using lists of static const strings.
And add a stern warning to gsparams.h on the subject.
And squash a couple of compiler warnings in the cups code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Noticed while debugging Bug 694179.
The main leak here is due to the strdup in cups_get_params and cups_put_params.
The code was then refactored to have one exit point to catch the remaining
6K leak.
However, the final 6k is due to the global structure created in
cups_globals_alloc and later freed in cups_globals_free. The free function
call is only done on windows due to a #define WIN32 and not called on a
Linux machine where the server continues to run.
No cluster differences
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A large number of targets weren't depending on the makefile in which they were
defined.
Almost no targets were dependent on the top level makefile.
A significant number of targets were missing the "MAKEDIRS" dependency (which
is specific to GNU make as an order-only prerequisite).
No cluster differences
|
|
|
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.
|
