Here is an example of finding a text extent in latex:

\documentclass{minimal}
\usepackage{calc}
\begin{document}
 \newlength{\tml}
 \settowidth{\tml}{$10^{-2}$}
 \the\tml \\
 $10^{-2}$
\end{document}

Save this as x.tex, then compile and view this with:

$ latex x.tex && dvips x.dvi && evince x.ps

"\tml" is a variable that you can use elsewhere in the latex program.

@Pantxo: I think your question is the correct one.  This isn't an issue about working or not working, it is an engineering tradeoff about whether the reward (shorter print execution times) are worth the pain of coding some special cases.  I don't know the code well enough to make that decision.

I would note that rendering the Z-ticks for 2-D scenes really feels like a waste of effort.  There are 3 axes (X, Y, Z) and for a 2-D scene the Z-axis is irrelevant which means 1/3rd of the processing time is unnecessary.  As an example,

plot (1:10)
tic; print ('-dpdflatex', 'tst1'); toc
zticks (linspace (-1, 1, 25));
tic; print ('-dpdflatex', 'tst2'); toc
Elapsed time is 4.21351 seconds.
Elapsed time is 8.65439 seconds.

It feels like that could be clipped by checking is2D boolean.

I had forgotten that enabling debug mode for latex not only printed more verbose error messages (as stated in the doc) but also printed cached strings. I definitely don't see 41 calls to latex (and others) but 27:

octave:1> doc "latex"
octave:2> setenv OCTAVE_LATEX_DEBUG_FLAG 1
octave:3>
octave:3> x=rand(1000,1);
octave:4> plot(x);
octave:5> cd /tmp
octave:6> print("x","-dpdflatex");
* Caching ?:10.000000:0:0:0:0
* Caching 0:10.000000:0:0:0:0
* Caching 200:10.000000:0:0:0:0
* Caching 400:10.000000:0:0:0:0
* Caching 600:10.000000:0:0:0:0
* Caching 800:10.000000:0:0:0:0
* Caching 1000:10.000000:0:0:0:0
* Caching 0.2:10.000000:0:0:0:0
* Caching 0.4:10.000000:0:0:0:0
* Caching 0.6:10.000000:0:0:0:0
* Caching 0.8:10.000000:0:0:0:0
* Caching 1:10.000000:0:0:0:0
* Caching -1:10.000000:0:0:0:0
* Caching -0.5:10.000000:0:0:0:0
* Caching 0.5:10.000000:0:0:0:0
* Caching 0:10.000000:1:38:38:38
* Caching 200:10.000000:1:38:38:38
* Caching 400:10.000000:1:38:38:38
* Caching 600:10.000000:1:38:38:38
* Caching 800:10.000000:1:38:38:38
* Caching 1000:10.000000:1:38:38:38
* Caching 0:10.000000:2:38:38:38
* Caching 0.2:10.000000:2:38:38:38
* Caching 0.4:10.000000:2:38:38:38
* Caching 0.6:10.000000:2:38:38:38
* Caching 0.8:10.000000:2:38:38:38
* Caching 1:10.000000:2:38:38:38
octave:7> get (gca, "ztick")
ans =

  -1.0000  -0.5000        0   0.5000   1.0000

octave:8> print("x","-dpdflatex");
octave:9>

The caching key is string:fontsize:horizontalalignment:R:G:B

The latex renderer first tests the latex toolchain by rendering a ? (the character that will be used later when/if some string can't be parsed), then it renders all 11 actually visible ticks [0 200 400 600 800 1000 0.2 0.4 0.6 0.8 1] in black (0:0:0 at the end of the key), but also invisible z tick labels [-1 -0.5 0.5], and finally it re-renders visible tick labels in dark gray (38:38:38).


The last stage is explained by this comment in print .m:

    ## With the -painters (gl2ps) renderer, line transparency is only
    ## handled for svg and pdf outputs using svgconvert.
    ## Otherwise, switch grid lines color to light gray so that the image
    ## output approximately matches on-screen experience.

The latex "calc" package is required to be part of a LaTeX distribution. It will tell you the extent of strings: width, height and depth (below baseline). I haven't tried to do this myself but I suspect that this is what you want to do. Then you don't need to call latex to render to a bitmap and measure that. I will have a go at writing a simple test case.

The process for printing figures to *latex* devices is to first rewrite all text objects (including labels and ticks) using the latex interpreter so that we know the correct extent of words (layout by latex with the correct font, size, ... freetype is not an option here) and can place them appropriately (e.g. the ticks and labels at the right distance from the axes lines).

Now on the original figure, I count only 11 distinct text strings (ticks), since all xyz labels are empty. So that leaves an open question: how is it that latex is called 41 times?

This is due to Octave having to render each tick label with the latex renderer the first time. The second time, it uses the cached images and is thus much faster.  I don't think we can do anything, except maybe throw a warning the first time the user tries to use a latex devices, e.g.: "warning: rendering all text labels with latex. This may take some time."

I can (kind of) reproduce OP results on Fedora 40.
With 9.2.1 I get 8.75sec/0.27sec and with Fedora provided
octave 8.4 5.94sec/0.35sec

This is on 5-years old laptop (i9-9880h).

Fedora's octave is compiles against Qt5, in case it might be important.

Dmitri.
--

I use a local build of octave-9.2.0 with qt-6. The _octave_config_info_ is attached.

Printing a random plot to the pdflatex device is slow:

$ cat src/test/print_latex_test.m
% print_latex_test.m

profile on

version

tic;
x=rand(1000,1);
plot(x);
print("x","-dpdflatex");
close;
toc;

tic;
x2=rand(1000,1);
plot(x2);
print("x2","-dpdflatex");
close;
toc;

profile off
profshow(5)

$ octave -q --no-gui src/test/print_latex_test.m
ans = 9.2.0-robj
Elapsed time is 17.7439 seconds.
Elapsed time is 0.412699 seconds.
   #      Function Attr     Time (s)   Time (%)        Calls
------------------------------------------------------------
  39           set    R       12.269      67.61          122
  21           get             5.078      27.98          538
  36 __go_uimenu__             0.231       1.27           48
 182 __go_delete__             0.214       1.18            2
 173       drawnow             0.164       0.90            6
Elapsed time is 17.5638 seconds.
Elapsed time is 0.415475 seconds.

The first plot takes 18s. The second plot in the session takes less than 1s.

For comparison, I installed the Fedora octave-8.4.0-6.fc40 package:

$ octave --no-gui -q src/test/print_latex_test.m
ans = 8.4.0
Elapsed time is 11.979 seconds.
Elapsed time is 0.412181 seconds.
   #      Function Attr     Time (s)   Time (%)        Calls
------------------------------------------------------------
  39           set    R        6.359      51.36          122
 173       drawnow             5.238      42.31            6
  36 __go_uimenu__             0.284       2.29           48
 182 __go_delete__             0.274       2.22            2
 133       findobj             0.043       0.35           14