GNU bug report logs - #19752
25.0.50; fonts in HTML

Previous Next

Package: emacs;

Reported by: rms <at> gnu.org

Date: Tue, 3 Feb 2015 01:11:02 UTC

Severity: normal

Found in version 25.0.50

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: larsi <at> gnus.org, rms <at> gnu.org, 19752 <at> debbugs.gnu.org
Subject: bug#19752: 25.0.50; fonts in HTML
Date: Sat, 02 Nov 2019 09:45:08 +0200
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sat, 02 Nov 2019 00:40:12 +0100
> Cc: Richard Stallman <rms <at> gnu.org>, 19752 <at> debbugs.gnu.org
> 
> > What does (display-color-cells) return for you?
> 
> FWIW, I tried this on the Linux console and got 8.  I guess ideally
> Richard would try if evaluating the following and see if it solves the
> problem for him:
> 
>     (setq shr-use-colors nil)

This is an option, so "M-x set-variable RET works for it.  No need to
use setq.

More importantly, I think indeed this is on balance the best solution
for these cases.  Emacs automatically maps any color to the closest
available one, but HTML email messages can use color specifications
that will cause both foreground and background convert to the same
colors, which will make the text illegible.

Or maybe shr.el can be taught to use the distant-foreground feature to
handle such cases?

> > -(defcustom shr-use-colors t
> > +(defcustom shr-use-colors (> (display-color-cells) 256)

This is too drastic, IMO.  Most HTML formatted emails use very few
colors and look OK on display even with 8 colors.




This bug report was last modified 4 years and 283 days ago.

Previous Next


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