GNU bug report logs - #40845
SVG rendering issues

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: cpitclaudel <at> gmail.com, 40845 <at> debbugs.gnu.org
Subject: bug#40845: SVG rendering issues
Date: Mon, 27 Apr 2020 18:47:11 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sun, 26 Apr 2020 19:00:36 +0000
> Cc: cpitclaudel <at> gmail.com, 40845 <at> debbugs.gnu.org
> 
> > Then I guess we are talking about two different use cases.
> 
> A more general one, and a more limited and specific one. As it
> happens, the fix for the more general one is simpler.

"More general" in what sense?  Using Lisp does mean you could write
more general programs, but it doesn't necessarily mean you will be
able to solve more general problems.  The display code maintains a lot
of state that describes each position on the screen (see 'struct it'
in dispextern.h), and your proposal seems to expose only the font and
the face attributes to the Lisp function.  What about the other
information? are you suggesting to expose that as well?  For example,
some use cases may wish to know the pixel coordinates of the image
being rendered, or whether it's on a continued or an R2L line, or the
ascent or descent of the screen line, or the pixel distance from the
window edge, etc. etc.  The display code has all of that at its
fingertips.

> > > and enhancing image specs to handle such context-dependent
> > > glyphs is wrong, because it moves code into the image backend that
> > > applies to all image backends.
> >
> > "Image backend" in this context is the image libraries, like librsvg
> > and libpng, is that right?
> 
> Yes.

That's what I thought.  Then I don't think I understand your comment
about "moving code into the image backend", since I never proposed to
move anything into those libraries.  We need to force those of the
libraries that are capable to produce the images we want.  Like force
a certain background of an SVG image.  That is all done outside of the
backends.

> > A Lisp program that prepares such display can prepare the spec
> > accordingly, if needed.
> 
> That's what I'm proposing: call a Lisp program to prepare a spec
> whenever we display the glyph. Not more often, which is wasteful.

I meant a Lisp program that prepared the spec before redisplay was
entered.  There's no need to re-evaluate it each time the
corresponding part of the screen is updated or Emacs needs to
calculate its layout for other purposes, such as moving the cursor N
lines down on the screen.  Please consider how many times this code
will be executed, sometimes in contexts that are completely unrelated
to showing the images.

> Except you're currently wrong: a Lisp program cannot prepare "the
> spec" accordingly, because there might be several required specs in
> effect at the same time, for example.

We should identify the aspects of the images we'd like to control, and
enhance the image display to obey those aspects when needed.  This is
not complicated enough to call for a Lisp implementation, and doesn't
justify the downsides of calling Lisp from the display code.

> My impression is you're treating extensibility itself as something to
> be avoided, not as something on the benefit side of a cost-benefit
> analysis (cost: 5 lines of actual code. benefit: solves both the more
> specific use case sought here and the more general use case I need).

I indeed prefer to avoid extending the display engine in Lisp, as
explained elsewhere.  I hope I convinced you, or that at least you see
my point.  Other extensions of the display code are much more welcome,
although the resulting complexity should be carefully considered and
weighed against the advantages.  The display code is extremely complex
and handles an almost infinite number of use cases, so much so that it
sometimes takes years to find bugs in some subtle use case.  We should
try not to over-complicate the code without a good reason.  And a
theoretical "generalization" is not a good reason in my book.

> As to how they arise: mathematicians, for example, have a
> long-standing tradition of making up symbols. Those new symbols aren't
> (and shouldn't be) in Unicode, and there are many other symbols that,
> for example, cannot be in Unicode for legal or ethical reasons. Users
> should be able to display such symbols in an Emacs buffer and have
> them be as close to character glyphs (or different from them) as they
> are willing to make them.

Could you please show examples of such symbols, and tell how they are
displayed by other editors or word processors?

> I remain convinced that I'm not smart enough to figure out in advance
> the precise set of use cases I want a feature for. You shouldn't limit
> generality to handle only those cases you're convinced are useful.

I don't want to limit generality, I want to limit the price we pay for
a use case that has yet to materialize.  I think this keeps the Emacs
display code from becoming completely unmanageable.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.