|
From: Ethan A M. <me...@uw...> - 2023-06-11 06:23:08
|
On Saturday, 10 June 2023 17:04:49 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
>
> > It is likely that the artefact is due to the viewing program rather
> > than being intrinsic to the pdf file output by gnuplot. I see no such
> > effect when viewing with the current version of okular
>
> Interesting. I tried mupdf and evince prior to writing the email, and
> they both don't look right. I just tried okular, and like you say, it
> looks ok. And gv looks ok too.
>
> I'd like it to look right in the others. Is this a BUG in the other
> viewers? I.e. is this something that a bug can be filed about?
Many years ago I identified the bug in gv and suggested a fix;
I do not know whether my suggestion was eventually adopted or some
other change was made. That was years ago and I do not recall
the exact details. I have never looked at the code for evince or mupdf.
Okular and Evince both claim to use the poppler library for rendering
pdf files, so I am a bit surprised thay behave differently.
Is it possible that the installations you tested were linked against
different versions of poppler?
> What if we change the code from
> calling term->filled_polygon() for each colorbox slice
> to
> calling term->image() once for the whole colorbox
In the case of pdf output it would mean going through the cairo library
either way. I wouldn't necessarily expect a difference.
Ethan
|