Recent changes to patches

#835 DPI support for raster terminals

Ethan Merritt — Sat, 25 Apr 2026 06:07:19 -0000

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

Ethan Merritt — Sat, 25 Apr 2026 03:04:57 -0000

[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

Sethur — Fri, 24 Apr 2026 22:53:39 -0000

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

Sethur — Fri, 24 Apr 2026 22:09:59 -0000

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

Ethan Merritt — Fri, 24 Apr 2026 21:01:55 -0000

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

Ethan Merritt — Fri, 24 Apr 2026 19:54:07 -0000

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

Sethur — Fri, 24 Apr 2026 11:32:47 -0000

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

Sethur — Fri, 24 Apr 2026 10:27:44 -0000

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.

#835 DPI support for raster terminals

Sethur — Fri, 24 Apr 2026 10:26:13 -0000

Regarding your comments on the Adobe glyph patch
Yeah, the LLM clearly tripped up here about when this issue was introduced. It probably saw a comment in the source's changelogs about when UTF-8/glyphshow was first introduced and hallucinated that this was when the bug was introduced. Carefully going over all commits (or being involved with the project for a longer time) would have avoided this, but I would probably have easily made the same mistake. I am not an AI apostle by the way, I hold the same view as Linus Torvalds, that they are useful tools.

Regarding your comments on the libgd clipping fix
The clipping optimizations/fixes for the libgd path indeed fixes some minor performance and rendering issues I have introduced myself with the previous libgd-dashtype-patch.

The whole reason for introducing clipping in the plot area in the first place was during my tests with thick dashed lines and various endcaps, I realized that, especially slanted lines stick out of the plot area. This looked ugly and in extreme cases, the parts that stick out can even overlap with the tick numbers. So I introduced clipping as an easy fix, but later realized, that the clipping:
a) Is done on every call of PNG_Vector(), which is needlessly expensive
b) Will clip thicker plot border lines (I saw this in colorscheme.dem) on the inside.

So the libgd part of this fix should take care of both the performance issues and the parts that were improperly clipped. Unfortunately, clipping in a way that leaves the plotting border intact is also significantly more complex and thus the code changes are not trivial.

That being said, none of the other terminals support this kind of clipping right now (although I would prefer they did and would also be willing to provide a patch for them as well), so an alternative would be to just remove clipping in the libgd terminals altogether to avoid this asymmetry.

I have meanwhile also found that the libgd clipping update of this patch does not yet work properly in some cases, so do not merge that yet. I will provided an updated patch that also splits the libgd clipping update from the rest of the changes.

#835 DPI support for raster terminals

Sethur — Fri, 24 Apr 2026 09:05:03 -0000

Hi @sfeam,

did the patch work for you for demo/armillary.dem and demo/charset.dem? This is where I found the issue and this patch fixed it for me, at least for these two demos.

From what the LLM claimed and what I just double-checked, the error indeed comes from Pango's pango_cairo_hex_box_render_glyph in pango/pangocairo-font.c. There, upon rendering a hex box for a glyph not found in the current font, the transformation matrix is reset to the identity matrix:

  cairo_save (cr);
  cairo_identity_matrix (cr);

cr is later restored, but the damage when rendering the hex box without using the scaled down 1/200 matrix that Gnuplot's cairo terminal uses internally is already done.

Now the question is, whether this really is a bug on Pango's side (seem like it to me), or whether this matrix-resetting has some internal reasons.

If you think it is a bad idea to try to work around this bug in Gnuplot, we do not have to merge this, especially since there seem to be problems on your side.

If you think it is worthwhile fixing it: Can you send me the script that fails for you so that I can investigate this further?