LaTeX Reader: \expandafter support

[mb21]

The LaTeX source mentioned in #3971 looks already much better, impressive! There seems to be only one more thing to make it compile. The two testcases should look something like:

```
pandoc -f latex -t native
\makeatletter
  \graphicspath\expandafter{\expandafter{\filename@area}}%
\makeatother
^D
```

```
pandoc -f latex -t native
\makeatletter
  \newcommand\urlfootnote@[1]{\footnote{\url@{#1}}}
  \DeclareRobustCommand{\urlfootnote}{\hyper@normalise\urlfootnote@}
\makeatother
^D
```

Info about \makeatletter...

Finally, images in the AST have their path relative to the included file (included via \input{file.tex}) instead of the root file. That's why they are not part of the generated epub (Should I raise a separate issue for that?).

[jgm]

Finally, images in the AST have their path relative to the included file (included via \input{file.tex}) instead of the root file. That's why they are not part of the generated epub (Should I raise a separate issue for that?).

Since we have the source file in the Token, I think that in theory we could temporarily add the directory of the source file containing an \includegraphics command to the resource path.

[jgm]

We already parse as if \makeatletter is set. That's not the issue with these cases. In the first case, the issue is with \graphicspath which expects braces rather than \expandafter.
In the second case, the issue, I think, is that the macro expansion of \urlfootnote@ seems to be trying to find an argument.

[jgm]

OK, we don't yet support \expandafter, which expands the token after the next one. Adding that would be a bit tricky because we tokenize before macros are known.

[jgm]

Forgot to fix the path on include graphics inside included files.

[jgm]

Never mind, we can't do what I thought we could with the images.

[mb21]

Great, thanks!

Since we have the source file in the Token, I think that in theory we could temporarily add the directory of the source file containing an \includegraphics command to the resource path.

Never mind, we can't do what I thought we could with the images.

Why not? Could we do something else instead?

[jgm]

+++ Mauro Bieg [Oct 20 17 08:14 ]:

Great, thanks! Since we have the source file in the Token, I think that in theory we could temporarily add the directory of the source file containing an \includegraphics command to the resource path. Never mind, we can't do what I thought we could with the images. Why not? Could we do something else instead?

Because the actual loading of images occurs not in the LaTeX reader, which still has information about the tokens, but in the PDF module, which only has the Pandoc AST.

[jgm]

Note: I was able to convert ctfp.tex to HTML after fixing the bad \code{a\'} (which resolves to \textt{a\'}).

Of course the image paths did not work. They worked with --self-contained and setting --resource-path=.:content/0.0:content/1.1:content/1.10:content/1.2:content/1.3:content/1.4:content/1.5:content/1.6:content/1.7:content/1.8:content/1.9:content/2.1:content/2.2:content/2.3:content/2.4:content/2.5:content/2.6:content/3.1:content/3.10:content/3.11:content/3.12:content/3.13:content/3.14:content/3.15:content/3.2:content/3.3:content/3.4:content/3.5:content/3.6:content/3.7:content/3.8:content/3.9.

@mb21, was your suggestion actually to modify the image path itself in the AST, so that it points to e.g. content/1.2/images/blah.jpg instead of images/blah.jpg, depending on the location of the included file? This can be done. Is it always what we want? I'm not sure how LaTeX resolves these paths and might need to do some experiments.

[mb21]

was your suggestion actually to modify the image path itself in the AST, so that it points to e.g. content/1.2/images/blah.jpg

yes, that's what I had in mind. I tried generating HTML and ePub and in both the images were broken/not included and it seems like the above would resolve it.

This should then also work with --extract-media, right?

[jgm]

OK, looked more closely. He's actually doing something rather fancy here:

\usepackage{subfiles}
\makeatletter
\let\org@subfile\subfile
\renewcommand*{\subfile}[1]{%
  \filename@parse{#1}% LaTeX's file name parser
  \expandafter
  \graphicspath\expandafter{\expandafter{\filename@area}}%
  \org@subfile{"#1"}%
}
\makeatother

This redefines \subfile to set \graphicspath using the subdirectory of the included file. So, this isn't at all standard latex behavior! Pandoc isn't picking up on this because it doesn't implement filename@parse.

I think the best I can do is to suggest that you use --resource-path (as above) when generating the epub.

[mb21]

ah, I see... thanks!