Re: [PATCH] cairolatex: respect transparency setting

On Thursday, 20 August 2020 20:17:44 PDT Henri Menke wrote:
> On 20/08/20, 20:01, Ethan A Merritt wrote:
> > On Thursday, 20 August 2020 18:34:54 PDT Henri Menke wrote:
> > > Currently the cairolatex terminal does not respect transparency options
> > > given in the terminal setting.  In this minimal example the
> > > notransparent option is ignored:
> > > 
> > >     set terminal cairolatex png notransparent
> > >     set output "test.tex"
> > >     plot sin(x)
> > > 
> > > Running this through gnuplot and then using `file' reveals that the
> > > alpha channel is still present:
> > > 
> > >     $ gnuplot test.gnuplot && file test.png
> > >     test.png: PNG image data, 1500 x 900, 8-bit/color RGBA, non-interlace
> > 
> > I think the raionale for the current code is that the png image created for
> > inclusion in a LaTeX document must have a transparent background in order
> > to support the "back" and "behind" attributes for text elements, since they
> > will be drawn by the latex engine and then covered by inclusion of the
> > graphics image.  The structure of the latex processing is:
> > 
> >     render text elements that are "behind" or "back"
> >     \includegraphics{gnuplot_figure}
> >     render text elements that are "front"
> > 
> > If you use a solid color background in the graphics image, it will hide
> > any previously rendered text elements.
> 
> The reason why I'm looking into this is that currently it is impossible
> to generate PDF/A when using plots generated by gnuplot.  PDF/A doesn't
> allow transparency, so I'm trying to remove all of it (or at least make
> it optional).  As noted in the patch, the default behaviour of using
> transparency remains, so this is entirely optional.

I am researching this as I type, so please bear with me.

From Wikipedia I see
	Transparent objects and layers (Optional Content Groups) are 
	forbidden in PDF/A-1, but are allowed in PDF/A-2.
PDF/A-1 was published in 2005; PDF/A-2 in 2011; PDF/A-3 in 2012;
So maybe this is no longer a limitation?

From my own knowledge, there are commonly available tools that 
render the transparency in a PDF document once, then save the result
as an embedded image that no longer contains transparency.
For example if you use gnuplot to create a PostScript file directly it cannot
use transparency because PostScript itself does not support transparency.
But if you use gnuplot to create a PDF file with transparency and then
convert it
	pdf2ps input.pdf output.ps
you get a PostScript file in which the transparency is "baked in" rather
than interpreted.   Logically then you could take that PostScript file
and convert it back to PDF, keeping the pre-rendered image that no
longer uses an alpha channel. 
	ps2pdf output.ps new.pdf
Whether that particular pair of tools produces a PDF/A compliant
file I do not know.

   best,

	Ethan

> 
> Kind regards,
> Henri
> 
> > 
> > 	Ethan
> > 
> > > 
> > > With this patch the transparency setting will be honoured.  The current
> > > default setting of implicitly assuming transparency is unaltered.
> > > ---
> > >  term/cairo.trm | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/term/cairo.trm b/term/cairo.trm
> > > index ee748dfe2..3ef76ecc6 100644
> > > --- a/term/cairo.trm
> > > +++ b/term/cairo.trm
> > > @@ -849,7 +849,7 @@ void cairotrm_graphics()
> > >  	plot.background.g = cairo_params->background.g;
> > >  	plot.background.b = cairo_params->background.b;
> > >  	gp_cairo_set_background(cairo_params->background);
> > > -	if (ISCAIROLATEX || cairo_params->transparent)
> > > +	if (cairo_params->transparent)
> > >  		gp_cairo_clear_background(&plot);
> > >  	else
> > >  		gp_cairo_solid_background(&plot);
> > > 
> > 
> > 
> > 
> > 





_______________________________________________
gnuplot-beta mailing list
[email protected]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta