emacs-devel
[Top][All Lists]
Advanced

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

Re: new image-type: composite, or not


From: Stefan Monnier
Subject: Re: new image-type: composite, or not
Date: Wed, 30 Jan 2013 19:21:35 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> http://public.fh-trier.de/~politza/emacs/pdf-isearch.png
> Because of anti-aliasing, the background is not merely a single color,
> such that my (single-color) mask is not perfect.  `convert' seems to do
> some fuzzy comparing of colors by default.

Ah, so your composite has the PDF on top and the highlighting below?
That means you need to know the background color of the PDF document.
I though you'd be put the highlighting above, but then it tends to
obscure the text it highlights, unless you use something like
α-blending.

>>> Alas, all this made me realize, that maybe a simpler approach would
>>> suffice.  Something like a single function
>>> (mark-image foreground background &rest edges-list)
>> I'm not sure exactly how that would work, can you give some details?
> This kind of function was what I was looking for.  I have a list of
> rectangles ((x0 y0 x1 y1)...) and want to ,,fontify'' the image at these
> places.  

Right, but I'm not sure what foreground and background mean (if you
assume the document is back-on-white, I can guess what you might want
to say, but if the document is a colorful image it's much less clear).

Also, it would require an `image' argument, other it wouldn't know which
image to mark.  And it would need to store the mark-data somehow
somewhere (probably within the `image' descriptor), so that redisplay
knows to put the mark next time it refreshes the display.

> I don't know.  I just thought, that maybe this kind of low-level
> tinkering with images, masks and slices is not really needed and maybe
> it does not really fit nicely in the current image-framework.  If that
> is true, then some more high-level function could simplify an
> implementation or make it cleaner.

That would be nice indeed, but I'm not sure if mark-image would let us
avoid such low-level tinkering.

>> Not sure what other candidates there can be, neither for mark-image nor
>> for a composite image.
> Well, customizing tree-widgets images...

You're thinking of using composite images in the tree-widget icons?


        Stefan



reply via email to

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