|
From: Dima K. <gn...@di...> - 2023-06-13 05:36:12
|
Ethan A Merritt <me...@uw...> writes:
> I do not see any such problem in the output from either pdflatex or lualatex as run here.
>
> [~/temp] pdflatex --version
> pdfTeX 3.141592653-2.6-1.40.24 (TeX Live 2022/Mageia)
> [~/temp] lualatex --version
> This is LuaHBTeX, Version 1.15.0 (TeX Live 2022/Mageia)
> Development id: 7509
>
> Output from pdflatex attached.
My bad. I gave you a pdf link in the last email that showed the issue.
But since then I've been working on my presentation, and in that process
re-generated my figures with the patched gnuplot, so the link in the
last email now points to a fixed image. This is what you used in your
attachment just now, and that's why it looks nice. You can confirm like
this:
dima@shorty:~/projects/gnuplot$ pdfimages -list /tmp/dima.pdf
page num type width height color comp bpc enc interp object ID x-ppi y-ppi size ratio
--------------------------------------------------------------------------------------------
1 0 image 60 40 rgb 3 8 image no 42 0 25 29 3602B 50%
1 1 image 1 128 rgb 3 8 image no 43 0 8 96 395B 103%
The 1x128 bitmap embedded in the .pdf is the colorbar, and its presence
indicates a patched gnuplot.
I'm attaching the pre-fix pdf file. I suspect you will see issues with
it if you pdflatex and the okular the output.
> So again, I do not think the problem is in gnuplot but rather in the
> pdf processing stage that comes after that.
Maybe. But if the issues in the surrounding tools are so pervasive that
things are broken more often than not, I'd be interested in tweaking
gnuplot to work well in the world that we have.
> But I'm not all that hopeful; variations of this sort of aliasing
> glitch persisted for years (decades?) in ghostview / gv despite it
> being a known and well-characterized bug
I haven't been fighting it for as long, so I remain optimistic :)
You raised some great points in your other email. I'll need a few days
to look at those.
Thanks much.
|