From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id YH1IOcsnyWXWNgEA62LTzQ:P1 (envelope-from ) for ; Sun, 11 Feb 2024 21:02:20 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id YH1IOcsnyWXWNgEA62LTzQ (envelope-from ) for ; Sun, 11 Feb 2024 21:02:20 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=YTElZgeP; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1707681739; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=tvjJPApc1+ZGzjRJ3aAsXkv4Js4lEX9A/S1Maq9ZrMc=; b=tarDqI+0KXAD45Iawb3oFJb9rYVazuiKS9IEtfKAy0p1yKZtwRNIrahdpQ/Al7Zeal7+W1 g9u/cH4d5gJvI0HpZjQ+Uje55VP/IAM1ye6GmDWsCuc4KeMlfmiFwg/ul00NHxWooyP8qZ LPmQ9B8202+TZHINlX8OS35+dfdfxEwOx+mmfKKwE/CEoL04Xn+LK4q7HrxXe4HsJwTtaI 0r/AlZLl7nXxpTzH3IetYslVdZtiaR5PPhrobSGU0p78KymJiaIvAbsIIvR5iBMDeLvAGD +kyChZBQMq43g9zvf8Ad5yioTEy/JIJf0hRo5AvErO9FR8xYrfQd//uXVstS9A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=YTElZgeP; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1707681739; a=rsa-sha256; cv=none; b=MWZEu6Ncayheh90IcENU/54XzkABsj6qCLR+BKf0byayz20SD/FcqFnnzqAnz408J7a4Yx vRbNSpxPV+cFCL4xYSMm+kWUvVx5SYXI6RNUkHH299OnW02TPuPKOnffDvwweR98+xbFVQ gtIjTpuTAd/FFSleRR0GUl2OnfXY3MF35oopN9TGiLkVVddijSO8p199i7KxZ/uuJOIb07 cSX9K42hH1Z6GmiCLNIcCGdqmuMX0vNOomfcBf4KZrVe4e5C0dZQnFjqwjJsBFTMxxLbiO cYSTb5jMaYRytYYHiAr+igw2XFHlkTT70eozrJqTf0eMx/Jh9U9rvxlk4tIA0Q== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 9AE5F35171 for ; Sun, 11 Feb 2024 21:02:19 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rZG15-0002ck-U3; Sun, 11 Feb 2024 15:01:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rZG0y-0002cT-79 for emacs-orgmode@gnu.org; Sun, 11 Feb 2024 15:01:24 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rZG0v-0000Ku-Tv for emacs-orgmode@gnu.org; Sun, 11 Feb 2024 15:01:23 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 6E07C240028 for ; Sun, 11 Feb 2024 21:01:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1707681678; bh=4rkCwv5qGmJ54PJGqcV91wCmRJLQj5nPGVQn1Qw6EYA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=YTElZgePwwef5gx7p0rJW+X2orRcoh4MDtTc4AQe1N4AMeEjFLCJwsODeFe/yB8Bj +S1IVOis+qi/+8a9kDbE5UhDa3RZBuVbzBtLVS/LkoW1GrmCNhxg/dY+iymrGIjWd8 ceM1nfGnt2Je+m9bKsGYjzAvu3dwn0V6/7NFAz1pZruKmfFz0/7lP0JX+5YK2LRefq T6M38IJes1v/C41PKMuS6SGph0l6E9biwO7zZ1E7T+0TSsrSurcFpwCyhDFj/VletF eGsPP3qB1xCuN0xGDudnNSOJta67rVFxB8va/ierApQL5PUCgh6PPZhl08CnLdn3Vs pxVKhoAIBypuQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TXz4F6hSTz9rxK; Sun, 11 Feb 2024 21:01:17 +0100 (CET) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: Ihor Radchenko Cc: orgmode Subject: Re: [patch] Add two new header args to LaTeX block In-Reply-To: <87il2v9i4r.fsf@localhost> (Ihor Radchenko's message of "Sun, 11 Feb 2024 14:43:00 +0000") References: <87zfw9yt9m.fsf@posteo.net> <87wmrcpepp.fsf@localhost> <875xyw9wic.fsf@posteo.net> <87le7se0qu.fsf@localhost> <87wmrc8b3e.fsf@posteo.net> <87r0hk863m.fsf@posteo.net> <87cyt4do4h.fsf@localhost> <87mss799lw.fsf@posteo.net> <87il2v9i4r.fsf@localhost> Date: Sun, 11 Feb 2024 20:01:15 +0000 Message-ID: <87h6ie7otw.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.65; envelope-from=maciaschain@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -10.40 X-Spam-Score: -10.40 X-Migadu-Queue-Id: 9AE5F35171 X-Migadu-Scanner: mx12.migadu.com X-TUID: 5Hguw04YSBDS 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 nonstop= mode > -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 file= s 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-directo= ry %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 (=3D :imagemagick yes)] Best regards, Juan Manuel -- Juan Manuel Mac=C3=ADas -- Composici=C3=B3n tipogr=C3=A1fica, tratamiento d= e datos, dise=C3=B1o editorial y ortotipograf=C3=ADa