From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Nicolas P. Rougier (inria)" Newsgroups: gmane.emacs.devel Subject: Re: ELPA: New package: svg-lib Date: Mon, 27 Sep 2021 20:03:12 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39176"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.6; emacs 27.2 Cc: emacs-devel@gnu.org To: Alan Third Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 27 20:09:40 2021 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 1mUv4N-000A1L-Ui for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Sep 2021 20:09:39 +0200 Original-Received: from localhost ([::1]:51930 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mUv4M-0005td-O3 for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Sep 2021 14:09:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40428) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mUv3n-0005DA-9U for emacs-devel@gnu.org; Mon, 27 Sep 2021 14:09:03 -0400 Original-Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:21424) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mUv3k-0007oD-Mv for emacs-devel@gnu.org; Mon, 27 Sep 2021 14:09:02 -0400 IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AHb3GR60ZrSWwqBDdikkhTgqjBZFyeYIsimQD?= =?us-ascii?q?101hICG9Evbo7LHToB1p726CtN9xYgBVpTnuAtjyfZq3z+8WkOws1NuZLXjbUE?= =?us-ascii?q?XBFuBfBbKL+VPd88eXzJ8/6U4YSchD4b7LfC1HZReR2mSF+rQbsam6GfuT6ds2?= =?us-ascii?q?pk0FJWoBGsUQiHYee3/raDwKeOAsP+t4KHPz3Ls4m9PtQwVkUizPbUN1KdQq7r?= =?us-ascii?q?bw5dvbSC9DLRgi7AWIkFqTmcbHOind+RFbeyhEwLc8/QH+/DDR1+GEjND+8RPZ?= =?us-ascii?q?0XLehq4m0+fJ+59kO83JoM0UJjLwqh/AXvUfZ5Sy+BYroaWK5EwxmNfB5yoxJs?= =?us-ascii?q?gb0QKRQkiF5T3z2k3byT4rr0TvwUWfhhLY0ILEbQN/LdVBwbhBeh+c0Vcpoc1n?= =?us-ascii?q?uZg7kF6xht5wEhKFoT/07dTSEzFm/3DE6UYKoKottDhkaKM7Qpdsl6B3xjIYYd?= =?us-ascii?q?I9NRO/17tiKtBHKPv3ws17GGnqIgGagkBfhOOWGk4LNjO9f2A+lqWuonIm30xE?= =?us-ascii?q?8w=3D=3D?= X-IronPort-AV: E=Sophos;i="5.84,326,1620684000"; d="scan'208";a="394169397" Original-Received: from 91-160-114-139.subs.proxad.net (HELO M-E7-NPR) ([91.160.114.139]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2021 20:08:57 +0200 In-reply-to: Received-SPF: pass client-ip=192.134.164.104; envelope-from=nicolas.rougier@inria.fr; helo=mail3-relais-sop.national.inria.fr X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:275603 Archived-At: Thanks for the information and the code. I did not know about the difference between Emacs 27 and 28. I did not have a change to test 28. My problem can be tested with the code below. The goal is to output an "A" using SVG and compare it to a regular "A". Ideally, they would need to be the same with very minor differences (due to different aliasing). But for some users and for unknown reason, the svg text size is plainly wrong. Can you confirm this code works as expected with emacs 28 ? #+BEGIN_SRC emacs-lisp ;; To adapt font weight: ;; '((thin . 100) (ultralight . 200) (light . 300) ;; (regular . 400) (medium . 500) (semibold . 600) ;; (bold . 700) (extrabold . 800) (black . 900)))) (let* ((w (window-font-width)) (h (window-font-height)) (font (query-font (font-at (point-min)))) (font-family (face-attribute 'default :family)) (font-size (elt font 2)) (descent (elt font 4)) (svg (svg-create w h))) ;; (svg-rectangle svg 0 0 w h :stroke "black" :fill "none") (svg-text svg "A" :x 0 :y descent :font-family font-family :font-weight 300 :font-size font-size :fill (face-attribute 'default :foreground)) (insert-image (svg-image svg :ascent 'center))) #+END_SRC Nicolas Alan Third writes: > On Mon, Sep 27, 2021 at 03:49:16PM +0200, Nicolas P. Rougier > (inria) wrote: >> >> Note that there is still a pending bug with text size for some >> users (see >> https://github.com/rougier/svg-tag-mode/pull/14. This is a >> different project >> but the problem is the same). Any help appreciated. > > Hi Nicolas, > > I had my own go at matching SVG images and Emacs's text > rendering at > one time and my code is here: > > https://gist.github.com/alanthird/7b86dc66df1ed3b9006bcd3fddd7350f > > I was really just messing about, though, so it's probably not > much > use. > > Reading through that bug report I'm not 100% sure what is going > on, > but I do suspect there may be some confusion as the behaviour of > SVG > rendering has changed between Emacs 27 and Emacs 28. > > For the most part Emacs 28 _should_ do the right thing. i.e. 1em > matches the exact font size used at the insertion point and the > default font family should also match the font at the insertion > point. > Emacs 28 also adds the ability to set image sizes with '(1 > . em), to > make it easier to make images scale with the font (we're using > that to > display checkboxes in customize, and so on). > > It also should set the DPI accurately so that 1cm == 1 real > world cm, > except possibly on Macs where Apple's recommended DPI behaviour > is... > > Strange. > > Unfortunately I guess you still have to support Emacs 27 (and > below?) > so perhaps none of that really helps you. > > When generating images I'd suggest always setting the image > scale to > 1, as that avoids any strange resizing behaviour that may be > caused by > the image creation code attempting to rescale images to match > the font > size. > > Finally we have a bug open about screen DPIs (bug#49937) > although it > probably has nothing to do with the problems you're seeing.