Re: [patch] Add two new header args to LaTeX block

["Juan Manuel Macías" <maciaschain@posteo.net>]

Ihor Radchenko writes:

> Got it.
> Although, it is confusing to have different formats of :process
> value depending on :file extension.

Indeed. For that reason I changed the original name I gave from
":pdf-process" to simply ":process". IMHO this function has a tremendous
problem: two methods coexist to convert a PDF compiled with LaTeX to an
image: the method with :imagemagick and the method without :imagemagick,
although this can also use imagemagick, which in itself is a first mess.
I don't know if this state of affairs is clear to the user...

The method without :imagemagick, furthermore, is the only one that
depends on a different process (leaving aside the case of conversion to
html, where another process is used).

The method with :imagemagick is, like the rest, more "transparent" (it is
the one I use, and I think many users prefer it):

TeX file --> compilation --> PDF --> conversion --> image file

The method without :imagemagick, which depends on the value of
org-preview-latex-default-process could be schematized like this:

TeX file --> {compilation + PDF + conversion + params.} --> image file

That is, the compilation and conversion processes along with the
parameters are included in the same pack.

> It would make things easier for users if
>     :results file :file foo.png :process '("lualatex -interaction nonstopmode
>     -output-directory %o %f")
>
> worked as expected, automatically overriding :latex-compiler value in
> let-bound `org-preview-latex-process-alist'.

I think that can cause certain drawbacks. Suppose a user has dvipng
as the value of org-preview-latex-default-process. If he/she puts

":process '(luatex etc ...)"

he/she will not be able to create the image because dvipng has the
value of ":image-converter" as the dvipng program, which, to put it
briefly and without going into details, would not work well with LuaTeX.
It is the problem of the same pack that I mentioned before. That's why I
think the lesser evil would be to allow the user to control the
necessary parameters at will, if the output file is an image file and
":imagemagick" is not present. Anyway, see what I say below.

>> Anyway, I don't understand why that feature option (convert to an image
>> without :imagemagick method) is limited to .png, when other graphic files are
>> possible. I can define something like this:
>>
>> (setq org-preview-latex-default-process
>>       '(my-process
>>      :programs ("lualatex" "convert")
>>      :description "pdf > jpg"
>>      :image-input-type "pdf"
>>      :image-output-type "jpg"
>>      :latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
>>      :image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
>>
>> But if I put :file foo.jpg nothing happens. Maybe that part should be
>> corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." out-file)?
>
> I agree that it should be corrected.
> Moreover, it would be nice to unify handling .png and imagemagick
> branches of the code.

I agree. In any case, I still think that the coexistence of two methods
to convert to images, when one of the methods has a scheme so different
from the rest, becomes difficult: for the user as well as for
maintaining the code.

The first solution that occurs to me (I'm afraid it's too radical) is to
leave only the :imagemagick method, and maintain the possibility of
using the other one through a variable. Something like
org-babel-latex-default-image-conversion-method or something similar.
But I suppose this could cause unwanted inconveniences. We should see
what more users think.

Another possibility is to clarify the names a little more (for the user):

:image-conv [possible values: default, imagemagick (= :imagemagick yes)]

Best regards,

Juan Manuel

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía