Bug 702192 Map text to black

Map all text to black.  This is achieved by altering the
color space to DeviceGray with a fill of black during
gs_text_begin. When gs_text_release occurs, the color space
is restored.  This will only occur with the option -dBlackText
and if the text is actually to be drawn.

When going to a raster device, the stroke and stroke fill of
the text is handled with a stroke or stroke fill command.
My original plan of storing the old color spaces and client
color in the text enumerator will not work in this
situation as it the enumerator will have already been
destroyed when the stroke or stroke/fill command occurs.
For this reason I store the old color space information
for the current and alternate color spaces
in the graphic state.  The structure holding the information
is garbage collected as it is holding objects that may be
garbage collected.  We also need to know if the target
was a high level device like pdfwrite, as that device
will handle the fill AND stroke, and we will need to restore
the color space when we tear down the text enumerator.

gs_text_release needed to have the pgs added as a parameter
to allow the possible release of the blacktext structure
when the text is released from the other languages. This
did not seem to be too big of an issue as gs_text_begin
passes the pgs also.  If the pgs is not available, NULL can
be passed, and that is done in several locations.

A new special op was added to let us avoid doing the black
text setting if we are constructing a soft mask.  If we did not
do this the mask could result in the loss of the text.

Finally, Type 3 fonts will NOT be affected by this process.
Type 3 fonts are often used for actual graphic logos etc.
Ken Sharp suggested we not have them affected by this setting.
There were also issues with trying to do type 3 fonts in
in that the PDF interpreter does some color space settings
of its state when dealing with type 3 fonts and this put the
interpreter's state out of sync with the graphic library state.

This was tested with a forced setting of black text enabled.
No seg faults or errors occurred.  There were obviously a lot
of differences reported (over 33,000). All the images that were available
to me with bmpcmp were gone through.  Problems were found
and addressed (the soft mask issue for example was found,
as were issues with color spaces not getting properly restored).

1 files changed, 34 insertions, 0 deletions

diff --git a/base/gsicc_blacktext.h b/base/gsicc_blacktext.h
new file mode 100644
index 000000000..cfd45b9aa
--- /dev/null
+++ b/base/gsicc_blacktext.h
@@ -0,0 +1,34 @@
+/* Copyright (C) 2001-2020 Artifex Software, Inc.
+   All Rights Reserved.
+
+   This software is provided AS-IS with no warranty, either express or
+   implied.
+
+   This software is distributed under license and may not be copied,
+   modified or distributed except as expressly authorized under the terms
+   of the license contained in the file LICENSE in this distribution.
+
+   Refer to licensing information at http://www.artifex.com or contact
+   Artifex Software, Inc.,  1305 Grant Avenue - Suite 200, Novato,
+   CA 94945, U.S.A., +1(415)492-9861, for further information.
+*/
+
+#ifndef gsicc_blacktext_INCLUDED
+#  define gsicc_blacktext_INCLUDED
+
+typedef struct gsicc_blacktext_state_s gsicc_blacktext_state_t;
+
+struct gsicc_blacktext_state_s {
+    gs_memory_t *memory;
+    rc_header rc;
+    bool is_fill;                 /* Needed for proper color restore */
+    gs_color_space *pcs[2];       /* If doing black text, color spaces to restore */
+    gs_client_color *pcc[2];      /* If doing black text, client colors to restore */
+    float value[2];               /* DeviceGray setting blows away the client color
+                                     zero value */
+};
+
+gsicc_blacktext_state_t* gsicc_blacktext_state_new(gs_memory_t *memory);
+void gsicc_restore_black_text(gs_gstate *pgs);
+
+#endif