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. |