#593 increase precision in pdf paper size
Hello,
I noticed that there are some rounding errors in the paper size for the pdfcairo terminal, and probably for other PS-related terminals as well. The generated PDF paper size is strictly an integer number of points (1/72 inch). For instance, if I want an exact A3 output, when I put this in the script:
set term pdfcairo size 42cm,29.7cm
The expected paper size would be 420x297 mm.
Instead, a PDF with the size of 1190x841 points (419.81x296.69 mm) is created.
I had a look at the Cairo library documentation, and the height/width parameters are defined as doubles (floats) in their functions. Inkscape uses the Cairo library as well, and it produces PDF documents with exact sizes and points with decimals. So I hope this is not because of the external library and it could be solved.
It would also be a nice feature to express paper size in millimeters, as it's the most usual unit for paper size in the metric system.
Thank you and best regards.
Hi, a quick update about the feature request.
Disclaimer: I have some programming skills, but I have zero experience in team-based coding or tools like GitHub/SourceForge. I locally installed VB Studio and managed to compile a local version of gnuplot with mingw. After messing around with the code (with the help of Copilot and Chatgpt), I came to the conclusion that the solution is quite simple:
The variables device_xmax/device_ymax of the plot_struct in "src/wxterminal/gp_cairo.h" (line 115) are currently declared as int.
These values are later passed to the cairo_pdf_surface_create () and cairo_pdf_surface_create_for_stream () functions.
I changed the declaration to double, compiled again and everything apparently works fine. With my compiled version, now a pdf paper size is exactly the declared size (either inches or cm) in the "set term" command, without any rounding. Pngcairo also works fine. Anyway, I don't know if this type change can have any other side effects.
I hope it helps, and that someone makes the change for the next release.
Best regards.
Last edit: Riccardo Lombardi 2025-09-19
Thank you for your suggestion, but Is there an actual problem here?
I understand that A3 paper dimensions cannot be expressed as an integral number of points.
I am wondering what are the circumstances where the residual fractional point (approx 0.15 mm) matters in practice. For what it's worth, the pdf file produced by gnuplot is identified as "Landscape A3" when I open it in a pdf viewer (okular in this case).
I agree that your proposed change is harmless with respect to pdf output. I am uncertain how it might affect the larger set of cairo-based terminal output modes where the true units are pixels. For example trying to draw a boundary line at a fractional pixel position could result in a misplaced or omitted border (there is a history of such problems). I would be happier with a change that affected only the pdf output.
Hello Ethan, thank you for your feedback.
I agree that this is not an actual problem, it's more like being perfectionist/obsessive about the real pdf size. I also agree that 0,15mm difference is unnoticeable in the real world.
However, some more exotic software or clients could suffer from this small difference. Some examples I found in my investigation:
https://forum.affinity.serif.com/index.php?/topic/232218-affinity-designer-v2-size-adding-005mm-when-exporting-to-pdf/
https://community.adobe.com/t5/indesign-discussions/cannot-set-page-size-with-211-1-mm-exports-pdf-as-211-0-mm/m-p/9014231
This is not my case, I was just giving some more reasons to implement the change.
Regarding the change proposal and your concerns, maybe we could create two new variables for the pdf paper size, leaving the current ones as integer, something like:
and feed the cairo_pdf_surface functions with the latter ones. (maybe this could work for epscairo too).
PS
In pdf specifications, the paper size is actually given in pixel/dots (1/72 inch) with the /Mediabox key. I found this online tool that lets you check the actual size of a generated pdf and the Mediabox numbers. https://pdfcrowd.com/inspect-pdf/
The cairo API takes the input in dots as well. With the help of the tool, I noticed that some pdf drivers generate pdf size as an integer number (like the built-in pdf export function in MS Office), while others create sizes with decimal values. I guess that most pdf readers leave a little tolerance for the paper size detection.
Last edit: Riccardo Lombardi 2025-09-20