Menu
▾
▴
gnuplot-beta
|
From: Henri M. <hen...@gm...> - 2020-08-21 01:35:30
|
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
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);
--
2.28.0
|
|
From: Henri M. <hen...@gm...> - 2020-08-21 02:34:56
|
Now there seems to a problem with ordering of the elements in the resulting TeX file. The ticklabels are behind the background image. Even if transparency is enabled, this is probably a bad idea. I'll investigate. Cheers, Henri On 21/08/20, 13:34, 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 > > 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); > -- > 2.28.0 > |
|
From: Ethan A M. <me...@uw...> - 2020-08-21 03:16:16
|
On Thursday, 20 August 2020 19:34:40 PDT Henri Menke wrote:
> Now there seems to a problem with ordering of the elements in the
> resulting TeX file. The ticklabels are behind the background image.
> Even if transparency is enabled, this is probably a bad idea. I'll
> investigate.
That is controlled by a generic setting, not specific to the latex terminals:
set tics {front|back}
The default is "back".
Ethan
>
> Cheers, Henri
>
> On 21/08/20, 13:34, 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
> >
> > 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);
>
|
|
From: Ethan A M. <me...@uw...> - 2020-08-21 03:04:17
|
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.
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);
>
|
|
From: Henri M. <hen...@gm...> - 2020-08-21 03:18:05
|
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.
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);
> >
>
>
>
>
|
|
From: Ethan A M. <me...@uw...> - 2020-08-21 04:32:18
|
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);
> > >
> >
> >
> >
> >
|
|
From: Henri M. <hen...@gm...> - 2020-08-21 05:48:03
|
On 20/08/20, 21:31, Ethan A Merritt wrote:
> 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.
This is actually a pretty good proposal. In my actual plot I now have
added
set terminal cairolatex pdf standalone header '\usepackage[a-1b]{pdfx}'
set output "test.tex"
# ...
unset output
!pdf2ps test-inc.pdf test-inc.ps
!ps2pdf -dPDFA=1 test-inc.ps test-inc.pdf
!pdflatex --interaction=nonstopmode test.tex
and the resulting document validates correctly with VeraPDF. It's a bit
ugly and I don't know whether the ghostscript roundtrip would correctly
preserve fonts, but since the background image doesn't contain fonts, I
don't care. Note that adding the -dPDFA=1 flag will make the PDF
structurally PDF/A compliant, but will not add metadata or color
profiles, so test-inc.pdf does not validate. These extras are handled
by the pdfx LaTeX package.
To get my plots with PNG background compliant I use the patch from this
thread together with your suggestion `set tics front'. Another option
would be to run mogrify to remove the transparency.
set terminal cairolatex png standalone header '\usepackage[a-1b]{pdfx}'
set output "test.tex"
# ...
unset output
!mogrify -alpha remove test-inc.png
!pdflatex --interaction=nonstopmode test.tex
So bottomlined my thesis now validates as PDF/A-1b, which is really
nice.
Cheers, Henri
>
> 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);
> > > >
> > >
> > >
> > >
> > >
>
>
>
|
|
From: Henri M. <hen...@gm...> - 2020-09-24 18:30:41
|
Dear Ehtan, I just wanted to ask what is the status of this patch? It doesn't change the default behaviour but makes the notransparent option actually do something. If you want I can write sentence in the documentation about the layer ordering. Cheers, Henri On 21/08/20, 13:34, 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 > > 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); > -- > 2.28.0 > |
|
From: Ethan M. <eam...@gm...> - 2020-09-24 21:55:02
|
On Thursday, 24 September 2020 11:30:11 PDT Henri Menke wrote:
> Dear Ehtan,
>
> I just wanted to ask what is the status of this patch? It doesn't
> change the default behaviour but makes the notransparent option actually
> do something. If you want I can write sentence in the documentation
> about the layer ordering.
As I understand it, you want this not because of a problem in the gnuplot
latex output but rather because of a bug/misfeature/quirk of some downstream
program that fails to validate the pdf file produced by running pdflatex on
the gnuplot output. Do I have that right?
The thing is, if a user selects the "notransparent" option with your patch
applied then the output from gnuplot is incorrect.
It loses the "back" layer of text, including the default axis tic labels.
This can be partially worked around by
set tics front
set grid front
but then the axis borders and tics in a 3D plot incorrectly occlude the
plotted surface. This has the paradoxical effect of making the
"notransparent" option cause a pm3d surface to look transparent!
Therefore I do not like the patch as it stands. In order to produce
correct 3D output further changes to the program would be required
to separate the handling of border text and lines.
Would it not be better to document that for some purposes
it may be helpful to post-process the png image?
mogrify -flatten myfigure-inc.png
I think that achieves exactly the same result (including the problematic 3D border)
at the cost of one extra step. But I could be wrong; maybe your validation program
still doesn't like it eve after flattening?
] cheers,
Ethan
>
> Cheers, Henri
>
> On 21/08/20, 13:34, 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
> >
> > 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
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
|
Thanks for helping keep SourceForge clean.
X