#2499 [5.5] Short vectors missing in cairolatex output

[Eldrad Ulthran]

When splotting with vectors in set view map mode, very short arrows are missing in cairolatex output, but displayed correctly in qt or pdfcairo, if the terminal size is comparably small:

$DATA << EOD
890.3400000000000318        0.1718205780095482331
893.6799999999999500        7.868922899201253263
912.3300000000000409        0.1568202957364852449
EOD

set xr [850:930]
set yr [0:10]

set view map

set term pdfcairo size 5cm, 3.5cm
set out "vectors_not_missing.pdf"
splot $DATA u 1:(0):(0):(0):2:(0) w vectors nohead lw 5 not

set term cairolatex size 5cm, 3.5cm
set out "vectors_missing.tex"
replot
unset out

[Ethan Merritt]

What you are seeing here is caused, I think, by a limited number of decimal places being carried along in cairo to prepare the cairolatex output. At some point the endpoints of the vector are the same to 3 decimal places (or maybe it's 4?) and the "zero length" vector is not drawn. Qt output does not suffer from this because coordinates are passed as binary floating point numbers. Output to PDF is not binary but apparently it keeps enough decimal places to avoid the problem in this particular case.

There was an analogous problem with svg output that was mitigated in gnuplot 5.4.1 by using one more decimal place in the output. (This was Bug #2369 but most of the discussion there was about drawing circles, not about resolution per se). At that time no change was made to the cairo code because it didn't appear to be an issue in practice for that test case. But your example shows that eventually the resolution limit is hit. It can be mitigated by increasing the internal oversampling factor, e.g.

diff --git a/src/wxterminal/gp_cairo.h b/src/wxterminal/gp_cairo.h
index 3cdedeb14..cef1e3a1f 100644
--- a/src/wxterminal/gp_cairo.h
+++ b/src/wxterminal/gp_cairo.h
@@ -81,7 +81,7 @@ extern "C" {
 # include <cairo.h>

 /* oversampling scale */
-#define GP_CAIRO_SCALE 20
+#define GP_CAIRO_SCALE 200

 typedef struct rgba_color {
     double r;

That handles your test case. But increasing by a factor of 10 only gains you one decimal place in formatted output, so the problem would presumably recur if you reduced the plot size even further. Keeping that extra decimal place increases the size of the output *.pdf file by about 10% in this case. I am not sure how representative that is, but that could obviously be investigated.

Is handling very short vectors in small plots worth an overall 10% increase in output file size (assuming that ratio turns out to be typical)? Maybe. But it's only a mitigation, not a fix. Using a different terminal might be a better solution in general.

[Eldrad Ulthran]

I discovered this in an actual application case: I am creating figures for a beamer presentation: The (intermediate) pdf size in cm is quite small, but the projected presentation will be large again (the short vectors will be large too), so this is a realistic use case. Similarly, TeX-ed posters (baposter) are sometimes first rendered on a small scale and then enlarged onto A0.

[Eldrad Ulthran]

Unfortunately, this patch is breaking the output, the dimensions in the resulting .tex file are 10 times larger than they should be:

\put(0,0){\includegraphics[width={1401.00bp},height={981.00bp}]{vectors_missing}}%

(This corresponds to (49.4 × 34.6) cm). Same goes for all other put commands.

[Ethan Merritt]

Yes. The original patch corrected only the pdf output, not the TeX code that wraps it. I have just now committed corresponding code for the TeX wrapper code.

diff --git a/term/pslatex.trm b/term/pslatex.trm
index 11a06b2d5..ff934e6d8 100644
--- a/term/pslatex.trm
+++ b/term/pslatex.trm
@@ -427,7 +427,9 @@ EPSLATEX_common_init()
     PSLATEX_pagesize_y = term->ymax * ysize;

     /* cairo terminals use a different convention for xmax/ymax */
-    if (!strcmp(term->name,"cairolatex")) {
+    if (ISCAIROTERMINAL) {
+    PSLATEX_pagesize_x *= (double)(2*PS_SC)/(double)GP_CAIRO_SCALE;
+    PSLATEX_pagesize_y *= (double)(2*PS_SC)/(double)GP_CAIRO_SCALE;
     PSLATEX_pagesize_x += 2*PS_SC * xsize;
     PSLATEX_pagesize_y += 2*PS_SC * ysize;
     }
@@ -725,6 +727,11 @@ TERM_PUBLIC void
 EPSLATEX_put_text(unsigned int x, unsigned int y, const char *str)
 {
     if (gpoutfile) {
+    if (ISCAIROTERMINAL) {
+        x *= 2. * (double)PS_SC /  (double)GP_CAIRO_SCALE;
+        y *= 2. * (double)PS_SC /  (double)GP_CAIRO_SCALE;
+    }
+
     if (!tex_color_synced) {
         fputs(tex_current_color, gpoutfile);
         fputs("%%\n", gpoutfile);

[Hans-Bernhard Broeker]

The patch to pslatex.trm fails to account for builds that may not have Cairo terminals active. Those now fail because the compiler cannot find GP_CAIRO_SCALE.