#835 DPI support for raster terminals

[Sethur]

Hi @sfeam!

During the last weeks, I spend considerable effort on implementing a new feature for Gnuplot that I was sorely missing for many years, and that is the ability to render rasterized graph output to an arbitrary resolution, i.e. DPI. As with my last patch, I used AI (Claude Opus 4.6 and 4.7) to help with the code generation and generation of accompanying patch commentaries, but I reviewed everything the AI produced throughly. I also spended many hours testing this patch, including side-by-side comparison of the relevant new output.

The motivation for this patch, provided in raster-term-dpi-and-various-fixes.mbox is as follows: Although it is most efficient and recommended to use vector graphs for publications, etc., it is often still required by many journals or even by programs like MS Word (which historically struggled to render supported vector output like EMF in many cases) to use raster graphics at high some mandatory minimum DPI, so it was often required to take your PDF or EPS Gnuplot output and rasterize it to some required resolution (e.g. by using GhostScript, GIMP, ImageMagick, etc.). This is cumbersome, but the alternative of directly creating high-resolution output with Gnuplot involved rescaling all font sizes, line sizes, tick sizes, marker sizes, etc., manually, which is even worse.

So my idea was to introduce a backwards-compatible option for all raster terminals (libgd, cairo and webp) that allows giving the size in units of length (inches, centimeters, etc.) as already possible for the vector terminals and additionally supplying the resolution in DPI, like so

set terminal pngcairo/png/webp/etc. size 12cm,9cm resolution 300

This would of course entail that the respective terminal drivers scale everything (font sizes, line widths, etc.) correctly for the requested resolution, but it turns out this was a feasible change without too many intrusive code changes. I have taken care to make this fully backwards-compatible, so that not specifying a resolution and giving size in pixels for the raster terminals will not change behavior. I have also taken care that the resolution meta data is embedded into the output formats wherever possible (this was not the case for pngcairo and webp before).

While implementing this, I targeted the visual appearance of pdfcairo, so line widths and font sizes are scaled accordingly. Along the way, I realized that - likely for historical reasons - the actual font sizes rendered by the postscript terminal in eps mode and by the pdfcairo terminal are too small and do not match the user requested point size, i.e., when the user requests "Arial,12pt", it is really rendered as 8pt by pdfcairo. The only exception to this is postscript in non-eps mode, where font sizes are rendered at their real size. For my patch, I did not change this behavior, so fonts are rendered as they would in pdfcairo. I have a patch on-hold that introduces a new option called "realfontsizes" that would make all affected terminals render at the true font size the user requested, but I did not want to include it here, as it would make an already large patch even more complicated. If you are, however, interested in the current situation of the font scaling, I have included an AI summary at document postscript_vs_cairo_sizing.md

While implementing the DPI feature and comparing the output of png and pngcairo with rasterized versions of the same output of pdfcairo and postscript (color eps), I came across a range of unrelated bugs, for which I have included fixes in this formatted patch. For convenience, each fix is in its own commit and should not be necessary to get the main feature running, but I would highly suggest to pull at least the libgd clipping fix, since this corrects some issues that I have introduced with my previous patch that added dashtype support for libgd.

To easily test this feature, I have included a ZIP of a minimal testing script together with all of the (slightly adapted) demos and associated data files. The testing script requires ghostscript, the main feature commit and the string_result_only fix to work. It will take the DPI as an argument and produce png output for the following terminals: png, pngcairo, pdfcairo and postscript, where the raster terminals er in eps mode with size 12cm,9cm at the requested DPI and font "Arial", and the vector terminals get rasterized to the requested DPI.

I will now list the commits this patch contains in reverse order with some comments by myself, but every one of those commits also comes with a detailed mark down documents that I had the AI write and that I personally reviewed.

405e4827f Implement DPI-scaling for libgd, cairo and web raster terminals
This is the main feature implementation, it contains everything described above. The associated document is: dpi_aware_libgd_and_cairo_feature.md

1c2ef330b Fix string_result_only flag leaking into function block evaluation
This is a fix to an issue I stumbled upon when I tried to call Gnuplot functions inside set output. It is required for the attached run_dpi_test.sh script to work properly. Its associated document is: fix_string_result_only_leak.md

78283c3ed Fix Adobe glyph name truncation in PostScript terminal
This fixes an issue where Adobe glyph names for unicode characters where truncated by one character due do improper memory allocation. This lead to, for example, /pi becoming /p, which was then rendered as a Latin letter "p" instead of a greek pi. The associated document is: fix_adobe_glyph_name_truncation.md

56d442126 Fix slow QT font-metric initialization and noisy warning
This fixed a Windows issue I encountered when switching the terminal to "qt" and plotting for the first time. Under these circumstances, I always got a "Slow font initialization" warning, which probably plaques many Windows users right now. The associated document is: fix_slow_qt_font_init.md

8e90f6c5f Fix oversized Pango hex box rendering with cairo oversampling
This is a fix to a cairo issue (both pngcairo and pdfcairo) I found in the output of demos using unicode characters that are not included in the supplied font. Previously, they were rendered much to large and covered to whole graph. The associated document is: fix_pango_hexbox_oversampling.md

9848b2ad4 Fix libgd clipping and libgd/cairo border rendering issues
This fixes a libgd png terminal issue that was introduced by my previous patch that clipped too much of the border surrounding a plot. This is most visible at larger line thicknesses. It also fixes a long-standing issue where the border for png and pngcairo hat a square cutout (for thick enough lines) at the upper left corner due to closed paths not being implemented properly in these terminals. The associated document is: fix_libgd_clipping_and_libgd+cairo_border_rendering_issues.md

cb5606523 Fix mingw makefile missing DLL dependencies
This fixed an issue with missing DLL dependencies for wgnuplot.exe and wgnuplot_pipes.exe in the Windows mingw Makefile. The associated document is: fix_mingw_missing_dll_dependencies.md

00dcd312c (HEAD -> raster-term-dpi) Add Apr 2026 changelog entries to terminal source headers
Lastly, this introduces short CHANGELOG style messages at the header of touched source files that already had time (like gd.trm). However, they summarize changes for all the commits above, so if you want to use them while not picking certain commits, they likely need to be adapted. I was not sure whether you wanted those messages at all, so I included them in their own commit.

The commits listed above all include a longer commit message that you could directly use when merging. I tried to keep it short but, as it is know, they might still be a little too detailed for your taste. Let me know if you want them shorter.

I realize that this is a lot of content, and since an AI was involved, you are probably sceptical about the quality. I can assure you, however, that these fixes have all been hand-vetted by me and tested over several weeks until I arrived at this point. This is still no guarantee that they are free from errors, but I hope that the code quality is good enough for you to consider merging these patches or at least most of them.

I have included some demo output at various DPIs for you to gain an impression of what this patch would make possible.

Cheers!

[Ethan Merritt]

Great. That wasn't clear to me from your earlier remark. In that case I will apply it for 6.0.5 also, since this is a long-standing issue on Windows.

[Ethan Merritt]

3) Very complicated changes that may have wandered off target

[PATCH 1/8] Implement DPI-scaling for libgd, cairo and web raster
Is there really a problem here that needs to be fixed?
If so, is this the right approach?

I understand that there is a mismatch between font sizes specified in points and output to a pixel-based rather than vector-based format. In the absence of a specified dpi the font size is not well-defined.

I also understand that it is common that the user wants to specify a size in physical units (inches, cm, mm) for eventual display even though the output format is defined by pixels.

These issues are of course not specific to gnuplot, so to large extent they are properly dealt with by the underlying graphics libraries (cairo/pango fontconfig gd ...). We should not have to add lots of code to gnuplot to perform a functionality that really should be provided by the library.

What gnuplot needs to provide (and document!) is a way for users to specify what they want and then translate this into the appropriate library calls.
As of now gnuplot pixel-based terminals provide

• a "size" option in either pixels or in/cm/mm
• documentation as to what dpi is used to convert in/cm/mm to pixels
• a "fontscale" option to adjust the nominal font size in points by
  scaling up or down to the desired effective size after rendering.

Together those seem sufficient, if only the bare minimum, to specify the desired output image characteristics. I certainly have no objection to making it easier, perhaps by adding a "dpi" terminal option. But the this patch seems to go way overboard. In particular I think it is unreasonable to have gnuplot inject raw binary metadata chunks into an output stream to bypass the processing provided by intermediate libraries (cairo gd webpmux). At first look it seems to add hundreds of lines of code plus additional complication just to add a metadata tag that chances are the upstream viewer or rendering program will ignore or the user will override with a new size.

What exactly is the goal here?

I sympathize with the pain of dealing with journal editors who do not understand much of anything about image formats, but in my experience this is best dealt with by corresponding directly with the production department. They are generally able to deal with vector->pixel conversion into their preferred in-house format, despite what the Instructions to Authors might say about requiring EPS or (ugh!) TIFF files.

If the goal is "replace satisfactory PDF output with equivalent quality pixel output at XXX DPI", it seems to me that a better path forward is to make it easier or provide better guidance to filter the PDF output through an external tool.

Adding a "dpi" option that overrides the assumed 72 dpi when interpreting size in inches is a reasonable idea. Surely that can be done with a much smaller change. Adding the corresponding documentation and examples of use would be important.

[Sethur]

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?

[Ethan Merritt]

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.

[Sethur]

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.

[Ethan Merritt]

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>

[Sethur]

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.

[Sethur]

Hi @sfeam,

as discussed I have split the DPI feature into several commits (each with their own mark down commentary):

1. cairo/webp part
2. libgd part
3. cairo meta-data embedding
4. webp meta-data embedding
5. libgd meta-data embedding

This should make it much easier to review the changes and select the ones you like. The libgd meta-data embedding is actually very straight forward. Cairo and webp are the ones that involve some not-so-nice byte-manipulation.

I have also renamed the resolutionoption to dpito make its intent clearer (but feel free to revert this if you do not like this change).

I kept the scaling approach mostly identical to my initial proposal. That means that specifying a size (in physical units) and dpi will yield nearly identical output as pdfcairo (or other vector terminals for that matter) for the respective plot.

I changed what happens if the user gives size in pixels but then still add the dpi option, e.g.:

set terminal pngcairo size 800,600 dpi 200

For my initial submission, this would have silently discarded the dpi 200 and reverted back to the legacy pixel-rendering path. With the attached patches, this would throw an error instead. Another alternative would have been to try to convert the x- and y-dimensions to physical dimensions using the 200 dots-per-inch given, but this would completely change the visual impression of the output (and the pixel dimensions).

I think the amount of code changes, especially for the cairo part, is now in a more digestible range.

Let me know what you think.

[Sethur]

EDIT: Fixed a comment in 0001-Implement-DPI-scaling-for-cairo-and-webp-raster-term.patch => 0001-Implement-DPI-scaling-for-cairo-and-webp-raster-term_v2.patch

[Sethur]

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.

PS: To address this specifically: Journals these days print at 300 to 600 dpi from what I know (if they even still have printed editions) but that was probably what you wanted to type.

Regarding the mismatch of the nominal size and the displayed size:

• If you create the graph for a printable document, you mostly know the intended physical size of the plot (just from how you have arranged it onto the page yourself) and the resolution (dpi) requirement comes from the journal, but it does not have to match exactly. Journals often require a minimum DPI for graphs (and other figures) to ensure a minimal quality, but they might require 300 DPI minimum and still print at 600 DPI, upscaling the graph in the process. Most journals also accept vector plots that they can then rasterize at any resolution, but - as already mentioned - there are some who don't

• Regarding the displayed size on a monitor with arbitrary pixel density: If you only indent to display your plot on an old 96 DPI monitor, it is of course not useful to produce your plots at a higher DPI, and yes, you might not know in advance what monitors your plot will be viewed at. As a consequence, if you are personally working on a 250 DPI MacBook Retina display, render your plots at that resolution (for maximum crispness) and share them with a someone that uses a 96 DPI monitor, those plots would be much too large when displayed at 100%. Conversely, plots from someone who uses a 96 DPI monitor and also renders at that resolution would be tiny on a 250 DPI retina display.
  However, even though you cannot know what monitor your plot will be viewed on, my patch would:

a) Embed the resolution in the image so that the desired physical size can be directly derived and used by the image viewer to downscale or upscale the image to the intended physical display size.

b) Allow users, for the first time, to ensure that plots look nice on all monitors by rendering them in sufficiently high resolution. While this would be overkill for some older monitors, those older monitors can downscale the larger images (thanks to the embedded intended physical size) efficiently, preserving quality. The other way around, i.e., upscaling low-res plots for proper display size on a high-res monitor would clearly degrade quality and - in general - produce blurry plots.

• Regarding your suggestion of using some option like rendering_quality with a default path of 1.0 = no changes: This would indeed be an alternative to using dpi and some plotting libraries/tools (like ScottPlot) support this exclusively (without the direct option of specifying DPI). This is equivalent of using a global scaling factor that would scale all elements of the plots with an identical factor (i.e., lines, fonts, points, etc.) and is - in principal - just mapping the respective DPI values to some smaller numbers, meaning that, for example, the default output, which was considered to be suitable for something like 72 DPI, would then be mapped to 1.0, 144 DPI would then be 2.0, and so on. This would be a possible way forward, but it has clear disadvantages to specifying physical size and DPI directly:

a) When only a global scaling factor is given, the indented physical size of the plot would not be clear and could not be embedded. It could maybe be derived from some mapping of the global scaling factor to DPI, i.e., if the user gives 1440x720 pixels at a scaling factor of 2.0, which would match 144 DPI internally, 10 inches x 5 inches could be embedded, but this would be much less transparent than stating the indented physical size directly (which is what is done for the vector terminals already).

b) More importantly, the patch currently tries to match the pdfcairo vector terminal output for a certain DPI in every respect possible (line thicknesses, dash patterns, font sizes, etc.), which was not achievable by simply resizing everything with a fixed factor (certain things had to be individually tweaked). One could argue that this makes the patch unnecessary complicated, but for the added complexity you gain the significant advantage of being able to use, e.g., png and pngcairo and have output that matches the vector terminals almost to the pixel (when rasterized).

If you do not feel comfortable with the complexity of the patch as it is know, however, and would prefer to have a simple global upscaling factor that would neither try to imitate the look of the vector terminals nor embed any metadata that aims at specifying the intended display size, I would be willing to provide an optional patch for that as well. However, I have to say that I would much prefer the dpi solution that I already posted.

EDIT: Formatting. Typos.