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

Previous Next

Full log

Message #37 received at 19752-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19752-done <at> debbugs.gnu.org, larsi <at> gnus.org, rms <at> gnu.org
Subject: Re: bug#19752: 25.0.50; fonts in HTML
Date: Wed, 12 Aug 2020 09:32:15 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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.

No further updates within 40 weeks here.  The accepted solution is to
use:

    (setq shr-use-colors nil)

I'm therefore closing this bug report.  If this conclusion is incorrect,
please reply to this email (use "Reply to all" in your email client) and
we can reopen the bug report.

Best regards,
Stefan Kangas

Previous Next

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