Recent changes to patches

#835 DPI support for raster terminals

2026-04-26T20:49:22.076000Z

Understood, I will split the patch and hopefully submit them here within the next week.

Regarding your ideas on how to present this to the user: Currently, the user indeed has to specify both a physical size and a resolution to trigger the dpi render path. Previously, if the user specified a physical size (instead of pixels), the physical size was just transformed to pixels assuming 72 DPI and everything else stayed the same.

One more thing that we could integrate into the patch would be allowing to give pixel dimensions and still give a resolution. This could trigger the terminal to activate the DPI render path and convert the pixel resolution to some physical size (i.e., dividing the x- and y-dimensions by the DPI, which would yield the size in inches).

Another options would be to not give the resolution in DPI but to basically give a global scaling factor, with 1.0 = 72 DPI (no action), 2 = 144 DPI and so on, but I find this less intuitive than the DPI approach.

There would also be the option of renaming the resolution parameter to dpi, which would make it even clearer (in hindsight, I think I would prefer this).

Let me know what you think is the best approach.

#835 DPI support for raster terminals

2026-04-26T20:39:39.331000Z

Perfect. I will put some more work into the libgd part and provide two options: One that completely removes the clipping (which would make it symmetric to the cairo terminals) and one that properly clips with a layer based approach (such that clipping is not done any longer on every PNG_Vector call.

#835 DPI support for raster terminals

2026-04-25T06:07:19.483000Z

Cairo terminal thoughts

a) Everything pertaining to cairo (and maybe webp, as it is directly connected)
b) Everything pertaining to libgd
c) All the metadata injection.

Would this work better for you?

Yes. I'd like to see a patch that has just the cairo terminal changes to support the dpi adjustment. I agree it may end up being a rather small patch. I am dubious that the metadata is worth it unless it can be done via a library call, which I gather cairo does not offer.

It may be worth discussing how this is best shown to the user. As I understand it the current patch only kicks in if the user specifies both a physical size and a dpi. That makes sense for preparing an image to be sent to a specific printer. It makes less sense for viewing on the screen, where the nominal size and the displayed size are often quite different. And in my experience you often do not know the true dpi of the eventual output device (journals used to print at something like 3000 dpi; I don't know what they do now). You only know the desired physical size. Same for displaying on a screen; you don't know in advance whether your plot will be displayed on a 95 dpi monitor or a Retina device. Would it make more sense to offer something like "rendering quality" where 1.0 = current behavior and higher values are treated internally as <new dpi="">/72 or something like that? </new>

#835 DPI support for raster terminals

2026-04-25T03:04:57.050000Z

[PATCH 6/8] Fix libgd clipping and libgd/cairo border rendering

I have extracted and committed the parts of this patch that add term->path to the cairo terminals and gd terminals. Thanks.

#835 DPI support for raster terminals

2026-04-24T22:53:39.766000Z

I don't get it. When or why would someone use one of the gnuplot raster terminals on a high-DPI monitor rather than a vector-based terminal based on a graphics layer that scales properly - qt, wxt, aqua, or svg?

I agree that vector based output is usually the best choice if the viewer supports it, but there are many cases where vector output is impractical:

MS Office historically had very poor vector support (might have gotten better in the meantime)
I personally often use scatter plots with thousands of rendered dots. Having a viewer render then several of these plots, for example side-by-side, will quickly lead to problems
I also have had many situations where I had to review hundreds of plots in quick succession and using vector output for this is impractical because it takes a while to render one plot so quickly switching back and forth between plots to compare output is only possible when the images are already rasterized.

Now you will probably say: Why not rasterize then from pdfcairo or svg output? Yes, you could do that, and I was doing so before but it takes additional effort and with this argument you could also say that Gnuplot technically does not even need any raster terminal drivers, as they could all render their output from one good vector driver internally and just convert the rasterized output to the target image format. Indeed, this would probably even make this feature irrelevant, as if Gnuplot worked this way, there would probably already be an option to specify DPI when rendering to a raster output format.

Maybe I'm missing an important use case for this, but I think as currently stated this goal misses the mark. It shouldn't be framed as "how do we make it easier for people to use the PNG terminal at high resolution?". A better goal would be "how do we make it easy for people to choose the right terminal for something that requires high resolution?"

As stated above, the right terminal for a high-resolution plot, in my mind, is not always a vector terminal. I was recently in need of a hjgh-res rendering of a high-point-count scatter plot for a large Powerpoint poster and I had issues with the vector approach. In this and many other cases it is just simpler to directly render to a raster format with your desired resolution.

As a last point: I think, if we strip out the meta-data embedding, the code changes actually needed for this feature are not that complex. They mainly touch the scaling of different plot elements where there already is scaling involved due to other reasons.

eah you might then notice poor resolution, but if that really matters then the embedded image should have been generated differently - maybe SVG or maybe PNG but with scaleable text overlay.

It is not only the text that is an issue. The raster terminal drivers were designed to produce text, lines and points at a size and thickness that looked nice on monitors when Gnuplot was conceived (CRT monitors with 72 - 96 DPI). Today, this is not the default any more. Yes, a viewer (e.g. a browser) can upscale a low-res png rendering, but this will result in an interpolated blurry looking image (depending on how much it is upscaled).
When I use Gnuplot personally with raster terminals, the first thing I usually have to do is to increase all line thicknesses, font sizes and point sizes (as well as the output dimensions) because the defaults are just not working, and with good reason.

There is also another point here that I already mentioned, but I want to emphasize it here once more: Gnuplot already allows giving sizes in cm or inches, which are then interpreted for a resolution of 72 DPI. So, implicitly, DPI support is already a part of the raster terminals. The argument now is: Why is this locked to 72 DPI? Would it not be a natural generalization to allow for other DPIs?

There is also another way to think about DPI support that maybe makes the whole think more palatable: Think of it as a global scaling factor for the output This is something that is currently missing in Gnuplot, although there are several terminal dependent factors like fontscale, linewidth or pointscale, but nothing that just scales all elements synchronously. Do you not think that this would be a very useful feature?

In fact, as I already mentioned, most other plotting engines explicitly support exporting to raster terminals with a given DPI. Look at MatPlotLib or MatLab with its exportgraphics(f,"barchart.png",Resolution=300) command, but there are many more.

t may be worth breaking out any discussion of webp format separately. I wrote the current webp terminal as a quick-fix alternative for making animations, since animated gif has pretty much died out, and constructing animations by post-processing individual PNG or JPEG frames is laborious. Because it was easiest, I based it on the WebPAnimEncoder API. But that API is for a stripped-down toolkit that doesn't provide many features you would want for serious animation. If someone wants to start over and write a webp terminal based on one of the more complete APIs for webp generation, that's great. It would be more work, but then you'd have higher quality output, easy generation of EXIF metadata, and probably more stuff like hooks for audio synchronization. Or maybe write an AVIF terminal instead; I have not looked into that.

Rewriting WEBP support to allow for easier EXIF metadata creation, etc. would certainly be a good idea, but I would be careful with pulling too many heavy dependencies to make this possible. I like Gnuplot because in a sea of bloatware, it is small, compact and fast. For now, if you don't like the byte-by-byte creation of the EXIF header that works with WebPAbimEncoder, I would just not embed the resolution. As a matter of fact, not embedding resolution in any of the metadata where it is still missing is definitely an option. I would find it much more important that the base DPI feature is realized.

#835 DPI support for raster terminals

2026-04-24T22:09:59.027000Z

Ah, you are probably using a different fallback font that has all the glyphs of armillary.dem, while my fallback font was missing a glyph.

The boxed text you requested in your script indeed poses a problem for the current patch. Your suggested alternative approach sounds feasible, I will try to come up with a workaround that involves this strategy.

#835 DPI support for raster terminals

2026-04-24T21:01:55.232000Z

Now for the goal and what we are trying to achieve: The main issue is that right now, the raster terminals are not very useful any more if you are working with high-DPI monitors, which is getting more and more common. A plot that looked great previously on monitors that were using resolutions below 100 DPI will not work any more for today's Retina, 4K, etc. displays.

I don't get it. When or why would someone use one of the gnuplot raster terminals on a high-DPI monitor rather than a vector-based terminal based on a graphics layer that scales properly - qt, wxt, aqua, or svg? And even in the case of, say, a PNG image displayed on a web page, the browser knows how to scale the image larger. Yeah you might then notice poor resolution, but if that really matters then the embedded image should have been generated differently - maybe SVG or maybe PNG but with scaleable text overlay.

Maybe I'm missing an important use case for this, but I think as currently stated this goal misses the mark. It shouldn't be framed as "how do we make it easier for people to use the PNG terminal at high resolution?". A better goal would be "how do we make it easy for people to choose the right terminal for something that requires high resolution?"

It may be worth breaking out any discussion of webp format separately. I wrote the current webp terminal as a quick-fix alternative for making animations, since animated gif has pretty much died out, and constructing animations by post-processing individual PNG or JPEG frames is laborious. Because it was easiest, I based it on the WebPAnimEncoder API. But that API is for a stripped-down toolkit that doesn't provide many features you would want for serious animation. If someone wants to start over and write a webp terminal based on one of the more complete APIs for webp generation, that's great. It would be more work, but then you'd have higher quality output, easy generation of EXIF metadata, and probably more stuff like hooks for audio synchronization. Or maybe write an AVIF terminal instead; I have not looked into that.

#835 DPI support for raster terminals

2026-04-24T19:54:07.063000Z

armillary.dem works for me without any missing glyphs, so the patch is not relevant. I.e. the glyph/font support provided by some underlying library (in my case libfontconfig) is also a contributing factor. charset.dem does indeed show that the patch removes over-large garbage from the output; note, however, that since the entire point of the demo is to determine what can or can not be printed with the current settings a better solution might be to simply skip the unavailable characters altogether rather than dealing with improperly rendered replacement glyphs. See proposed alternative approach below.

I figured out that the garbage output I saw before is because my script requests boxed text. The patched code suppresses the bad glyph rendering but still reports text metrics that are off by a factor of 200. That produces a box around the text drawn as a huge rectangle with the wrong center. The incorrect centering is true even for unboxed text, so I suspect the patch results in incorrect placement for all right- or center- justified text longer than a single character.

I definitely think this is a pango bug and that is where it should be reported and hopefully fixed.

I wonder if a different work-around is possible in gnuplot that would be simpler and possibly more generic. The current patch uses pango_layout_get_unknown_glyphs_count() to detect the error case. If this routine can be used iteratively to drill down and find individual problem characters, then gnuplot can simply delete that character from the output text or replace it with what Unicode calls a ".notdef glyph". Unfortunately there is no Unicode code point for this symbol. Some rendering environments use � (U+FFFD REPLACEMENT CHARACTER) instead. That is what you see in the qt output I attached. Other possibilities are ▯ or ⍰ or a blank space.

#835 DPI support for raster terminals

2026-04-24T11:32:47.685000Z

Hi @sfeam,

let me try to make a strong case here for this patch:

First, I agree that the meta data (resolution) injection introduced for cairo and webp is probably not the cleanest solution, but it seems cairo really does not provide a way to set PNG's pHYs and Gnuplot also does not link libpng. It also really seems that libwebpmux does not provide a way to contruct the EXIF/TIFF payload. Do you have an idea of how to do this better?

If you prefer, we could leave out the ugly part of the meta data manipulation altogether and just accept that the so created files will not have the resolution embedded. This might, however, lead to printing and text layout issues in some cases that users will not understand.

As a start, I will separate out the DPI meta data embedding into its own commit, so it can be easily dropped and the code complexity of the main commit is reduced.

Now for the goal and what we are trying to achieve: The main issue is that right now, the raster terminals are not very useful any more if you are working with high-DPI monitors, which is getting more and more common. A plot that looked great previously on monitors that were using resolutions below 100 DPI will not work any more for today's Retina, 4K, etc. displays. Most other plotting libraries support either a global scaling factor (e.g. ScottPlot, see https://scottplot.net/faq/dpi-scaling/) or explicit DPI settings (see savefig in MatPlotLib's docs: https://matplotlib.org/stable/api/_as_gen/matplotlib.pyplot.savefig.html)

It is true that there are some scaling options in Gnuplot already, but look at this Stackexchange post to see how cumbersome it is to get them all right to produce a plot at the proper size and DPI combo: https://unix.stackexchange.com/questions/617823/gnuplot-setting-image-width-with-pixels-for-specific-dpi

Also, pointscaleis not even available for the libgd terminals.

So my point is that producing good-looking plots at journal-prescriped mandatory DPI is not the only advantage of implementing this patch: Many users that currently work with raster terminals have high-res monitors (think about all the Apple users out there) and would want to user thicker lines, larger symbols and larger pixel dimensions per default. Currently, that means that they need to carefully set all the proper scaling themselves.

Finally, parts of this were already implemented in the cairolatex png terminal, so this patch uses an existing approach, at least for the cairo path. Since setting the size in cm or inches is already possible with the size parameter and the scaling currently defaults to 72 DPI, it seems to be a natural extension to me to allow to set the resolution explicitly.

And yes, users could alternatively go the route of producing vector output with pdfcairo and then rasterizing at a preferred DPI, but this requires knowledge about vector and raster graphics that many users do not have. Also, it requires additional processing steps that could be avoided.

My suggestion would be to split this larger patch into several smaller:

a) Everything pertaining to cairo (and maybe webp, as it is directly connected)
b) Everything pertaining to libgd
c) All the metadata injection.

Would this work better for you?

#835 DPI support for raster terminals

2026-04-24T10:27:44.207000Z

I have a Windows system on hand and can check whether this patch will fix the bugs you mentioned. I will post here again if I have an answer.