@Sebastiano oh OK, subscript looks a bit higher than normal but it's probably the times setting. as it's an upright integral you might like \int\limits_{...} or even \int\limits_{\mathclap{...}} (from mathtools package) the last one hides the width completely so it would over-print anything close, but probably OK there
@PauloCereda -- seems you don't know what short shorts are ... the ones on egreg are longer than bermudas. the ones on will are bermuda length. next shorter would be jamaicas. and two or three stages above that would begin to be short shorts.
@Sebastiano if you want it in the subscript position (actually I wouldn't if you only have a low expression on an upright integral) use \int_{\mathllap{...} but I think the subscript will look very close to the F
@Sebastiano yes can see it was that from the output:-)
infact I have a problem with my figures \begin{figure}[h] \centering \includegraphics[width=.6\linewidth]{coordcil.pdf} \vspace{-.5cm} \caption{Coordinate cilindriche.} \label{fig:subim6} \end{figure}
If I close the conversation is because the battery is discharged and I apologize for it before. Leave me a message of what I'll have to do - meanwhile, I greet you and everyone
@ChristianHupfer my code is uglier, and needs to be straightened up. I received suggestions about it, but I couldn't make it work in the new release, so I kind of traded off
\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[italian]{babel}
\usepackage[fleqn]{amsmath}
\usepackage{mathtools}
\usepackage{newtxtext,newtxmath}
\DeclareMathOperator{\asse}{asse}
\newcommand{\diff}{\mathop{}\!d}
\begin{document}
Sia $\Gamma$ una curva regolare congiungente due punti $A$~e~$B$,
supponiamo che il verso vada da $A$~a~$B$ ed indichiamo con
$r_A=d(A,\asse z)$ e con $r_B=d(B,\asse z)$. Allora:
\begin{equation}
\int_{\Gamma(A,B)} \bar{F}\cdot\diff r=
\RequirePackage{svn-prov}
\ProvidesFileSVN{$Id: tikzlibrarycfrexternal.code.tex 6276 2017-04-25 02:05:44Z $}
\RequirePackage{currfile,etoolbox,xparse}
\usetikzlibrary{external}
\ExplSyntaxOn
\tl_new:N \g_enext_figurename_tl
\cs_new_protected_nopar:Nn \enext_settofilename:
{% tries to set the base figure name automatically, but will fail with \file_input rather than \input, for example
\enext_tikzsetfigurename:x { \currfilebase- }
}
\cs_new_protected_nopar:Nn \enext_tikzsetfigurename:n
{
\tikzsetfigurename { #1 }
^^ is evolved from an answer to a question somewhere. Basically, it tries to name externalised images more sensibly. By default, the insertion of a new tikzpicture at the beginning of a document triggers compilation of all pictures in the document, even if their code isn't changed. It is also quite hard to figure out which externalised image is which. The library uses file names to name the images, falling back to something else if a picture is specified inline. It all works fine ...
... provided nothing is ever input with \file_input rather than \input. At least, it works fine so far. But I have code which uses \file_input and then everything goes wrong unless there's another \input before the next picture. I need to get the equivalent of \currfilebase and feed it to the naming mechanism. I'm not entirely certain exactly why I get the errors I do, but even if it compiled, it wouldn't do what it's meant to because \currfilebase doesn't track \file_input.
^^ It needs standalone, too.
@DavidCarlisle I'm not sure. Is it?
@DavidCarlisle I don't want the path. I just want the base name. I wondered if there was a safe way of extracting it from `\g_file_current_name_tl`. However, that gives me very strange results which are not even related to the correct file name, so is clearly hopeless. Could I safely extract the base name from `\l__file_internal_name_tl`? That does get the right file, at least. Although you said I shouldn't use it .... `
@JosephWright That is, it is useful to name externalised TikZ pictures after the files containing the code for them, without having to explicitly set the externalised file name each time. This is easy with \input and currfile. But it gets all screwed up with \file_input.
