bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overla


From: Alan Third
Subject: bug#52599: 29.0.50; Unproportional Unicode character scale in SVG overlay
Date: Mon, 20 Dec 2021 16:31:14 +0000

On Sat, Dec 18, 2021 at 02:51:30PM +0200, Eli Zaretskii wrote:
> > From: "Matsievskiy S.V." <seregaxvm.main@gmail.com>
> > Cc: 52599@debbugs.gnu.org
> > Date: Sat, 18 Dec 2021 15:13:15 +0300
> > 
> > Attaching ELisp code
> 
> Thanks.
> 
> In my testing, the size of the font in the image doesn't change at all
> when I increase or decrease the text scale in the buffer.
> 
> I think whether the font changes is up to librsvg and the font backend
> it uses, and Emacs does not necessarily have a way of controlling
> that.  But I'm not an expert on SVG and the library, so perhaps
> someone else could chime in.

I *think* what's going on here is that the image size is defined in
terms of "ex", but when using librsvg < 2.52 we have no idea what the
ex height should be, so we use a fall-back mechanism to calculate the
image size.

Additionally most of the text is vector paths, not text, so it doesn't
scale with the font size change, but some of it *is* text, so it
*does* scale.

So what we end up with is that the text scales directly according to
the font size and the paths scale according to whatever nonsense
librsvg returns for the image size.

You could work around this by hard-coding the font size in the SVG or
pass in some CSS to over-ride Emacs's default. I'd suggest hard-coding
it in the image if possible as the default CSS contains colour
information too.

(Or we could try and work out the real ex height, but we would
probably have to copy how librsvg calculates ex height, which I have a
suspicion will be some constant fraction of an em instead of the
font's real ex height.)

-- 
Alan Third





reply via email to

[Prev in Thread] Current Thread [Next in Thread]