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
