From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: No NEWS entry for doc-view-mupdf-use-svg (Emacs 30.0.91 feedback) Date: Sat, 21 Sep 2024 19:35:33 +0200 Message-ID: <87msk0oqoq.fsf@gnu.org> References: <87cyky43fb.fsf@ice9.digital> <86setu5f85.fsf@gnu.org> <87zfo22jy4.fsf@ice9.digital> <86bk0h5sx9.fsf@gnu.org> <87ldzlgxvh.fsf@ice9.digital> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29369"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.12.6; emacs 31.0.50 Cc: Eli Zaretskii , emacs-devel@gnu.org To: Morgan Willcock Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 21 19:36:37 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ss428-0007UF-Fs for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Sep 2024 19:36:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ss41D-0002DE-Vf; Sat, 21 Sep 2024 13:35:39 -0400 Original-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 1ss41C-0002CK-IQ for emacs-devel@gnu.org; Sat, 21 Sep 2024 13:35:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ss41B-00072e-UY; Sat, 21 Sep 2024 13:35:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=YIwloAjAru9hPkk0s+ArfivBfQCsAfMPkOQwgl38ABI=; b=ZOuD5ipwdZNJcTsf0wti HsGQR/BtOZps0BPzizdn5yBt9OLfNAW3T0g1VSzORnQe5a0YBoHKjC+N4tVNeODezmm37khSZRfwH thv4luNTdBHIy5Mei9/qzIaGfM7teU1tp8nJS9yxOw5RBQpmU8iPJHQZMPiRLFfaWkjm0/kYsoVRh KPzBsRQ8dk54H2+O9IeaEWwF69hYUYrYx7/y9SHXzUaVAKjzGPiADNfubAKmaUjhJ/mvEvfZ5zwnS ls0dzDNU35l29krkSYGJwq+kOdLuicpQLJl1GbVFNEksw/3qjJ4mRhdoftAtYZf2tVlPS8gcFPWMs v51SEnuBvoVZ8w==; X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudelhedgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhgffffkgggtgfesthhqredttder jeenucfhrhhomhepvfgrshhsihhlohcujfhorhhnuceothhsughhsehgnhhurdhorhhgqe enucggtffrrghtthgvrhhnpeevffduleekgefftdetfeefheeviefgjeevudegkeehvdeu udejfedugfeuleffhfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehthhhorhhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdek ieejfeekjeekgedqieefhedvleekqdhtshguhheppehgnhhurdhorhhgsehfrghsthhmrg hilhdrfhhmpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtphht thhopegvmhgrtghsqdguvghvvghlsehgnhhurdhorhhgpdhrtghpthhtohepvghlihiise hgnhhurdhorhhgpdhrtghpthhtohepmhhorhhgrghnsehitggvledrughighhithgrlh X-ME-Proxy: Feedback-ID: ib2b94485:Fastmail In-Reply-To: <87ldzlgxvh.fsf@ice9.digital> (Morgan Willcock's message of "Sat, 21 Sep 2024 10:27:30 +0100") X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:323902 Archived-At: Morgan Willcock writes: >>> I think it is rendering the text and the background of the document >>> in the same colour. >> >> In that case, you may wish to customize the new face >> doc-view-svg-face. > > It seems to be the currently active theme which determines whether the > the document is readable or not. The value of the foreground and background doc-view-svg-face properties are passed as :foreground / :background values to create-image when inserting the SVG into the buffer. Their docs are here (info "(elisp) SVG Images"). --8<---------------cut here---------------start------------->8--- SVG (Scalable Vector Graphics) is an XML format for specifying images. SVG images support the following additional image descriptor properties: =E2=80=98:foreground FOREGROUND=E2=80=99 FOREGROUND, if non-=E2=80=98nil=E2=80=99, should be a string specifyin= g a color, which is used as the image's foreground color. If the value is =E2=80=98nil=E2=80=99, it defaults to the current face's foreground co= lor. =E2=80=98:background BACKGROUND=E2=80=99 BACKGROUND, if non-=E2=80=98nil=E2=80=99, should be a string specifyin= g a color, which is used as the image's background color if the image supports transparency. If the value is =E2=80=98nil=E2=80=99, it defaults to t= he current face's background color. --8<---------------cut here---------------end--------------->8--- Since doc-view-svg-face inherits from the default theme, in theory the SVG should be adjusted acording to your theme. > If the SVG rendering is enabled (when available) by default, does this > mean that it is the user's responsibility to set usable default > colours? Or should the theme be setting usable default colours? The latter. If the theme sets the default face sensibly (which it surely does), then your PDFs should look the same. Well, and that's true for "normal" PDF documents (black on white, e.g., academic papers) but somehow fails for "fancy" documents. I don't know how the :foreground/:background SVG image properties work but it looks to me as if :background works well every time but :foreground doesn't as soon as the text is not black. I suspect the heuristic is something like: if it's transparent, it's the background, and if it's either black or white, it's the foreground. >> What do other applications, like a browser, show for the produced SVG >> file? Is it possible that your version of mpdf produces bad SVG >> images? > > I couldn't find any installed utility by that name, Its mupdf or mudraw. > but using image-save in the DocView buffer suggests that the actual > conversion to SVG doesn't have any problems. It seems to be purely an > issue with how the SVG image is displayed in the buffer. You can find the generated SVG files easily using M-x doc-view-dired-cache RET which opens a dired buffer in the temporary directory where doc-view stores the files. Bye, Tassilo