GNU bug report logs -
#21557
25.0.50; HTML renders text invisible
Previous Next
Reported by: rms <at> gnu.org
Date: Fri, 25 Sep 2015 08:29:02 UTC
Severity: normal
Found in version 25.0.50
Done: Katsumi Yamaoka <yamaoka <at> jpl.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21557 in the body.
You can then email your comments to 21557 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21557; Package
emacs.
(Fri, 25 Sep 2015 08:29:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
rms <at> gnu.org:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 25 Sep 2015 08:29:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I received a message whose text was rendered as invisible when I
viewed it in Rmail. I think it is because of 'color:#000'.
I think that if HTML specifies the same color for foreground and
background, rendering should use different colors so that the text
can be seen.
Here is a redacted version which reproduces the bug.
>From a <at> b.org Wed Sep 23 13:26:14 2015
Envelope-to: rms <at> gnu.org
Delivery-date: Wed, 23 Sep 2015 13:26:14 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_50,HTML_MESSAGE,
MIME_HTML_ONLY,RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.2
X-SID: LhS71r0032XSfNk01
Received: (qmail 29571 invoked by uid 99); 23 Sep 2015 17:26:07 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
User-Agent: Workspace Webmail 5.15.9
From: <a <at> b.org>
To: xxx <at> gnu.org
Cc: "Richard Stallman" <rms <at> gnu.org>
Subject: Re: STALLMAN BOOKS
Date: Wed, 23 Sep 2015 10:26:06 -0700
Mime-Version: 1.0
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x
<html><body><span style=3D"font-family:Verdana; color:#000; font-size:10pt;=
"><div>Hi Jeanne</div><div><br></div><div>I know I gave you an address for =
the books to be sent. I am sending you an address at Kent for the books to =
be sent. It makes more sense for the books to be sent there:<br></div><div>=
<br></div></span></body></html>
In GNU Emacs 25.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.23)
of 2015-08-12 on freetop
Repository revision: 79a169684dfad2c0bbb9fdbae539c1f30d9f0ac3
System Description: Trisquel GNU/Linux 7.0, Belenos
Configured using:
`configure 'CFLAGS=-g -O0''
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GCONF GSETTINGS NOTIFY
LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: RMAIL
Minor modes in effect:
diff-auto-refine-mode: t
shell-dirtrack-mode: t
gpm-mouse-mode: t
tooltip-mode: t
global-eldoc-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
abbrev-mode: t
Recent messages:
Mark set
Mark saved where search started
Mark set
Saved text from "From tracey.hughes <at> neoacmchapter.org We"
Mark set
Auto-saving...done
Mark set
Sending...
Wrote /home/rms/outgoing/out-72
Sending...done
Load-path shadows:
None found.
Features:
(shadow emacsbug jka-compr epa-mail quail rmailkwd epa derived epg
rmailout vc vc-dispatcher vc-git diff-mode easy-mmode find-func pp
two-column kmacro iso-transl ispell dabbrev battery shr-color color
url-util url-parse auth-source cl-seq eieio byte-opt bytecomp
byte-compile cl-extra seq cconv eieio-core cl-macs gv gnus-util
password-cache url-vars shr dom subr-x browse-url rmailsum dired-aux
shell pcomplete grep compile comint ansi-color ring misearch
multi-isearch mailalias qp rmailmm message sendmail format-spec rfc822
mml mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils
mailheader mail-parse rfc2231 rmail rfc2047 rfc2045 ietf-drums mm-util
help-fns help-mode cl-loaddefs pcase cl-lib mail-prsvr mail-utils
dired t-mouse view time-date paren cus-start cus-load advice
finder-inf package easymenu epg-config mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese
eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook
help simple abbrev minibuffer cl-preloaded nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)
Memory information:
((conses 8 275753 47689)
(symbols 24 25638 8)
(miscs 20 1580 3204)
(strings 16 40311 16893)
(string-bytes 1 1558732)
(vectors 8 27525)
(vector-slots 4 1446754 41808)
(floats 8 414 549)
(intervals 28 43560 1216)
(buffers 520 54)
(heap 1024 14588 1385))
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21557; Package
emacs.
(Mon, 28 Sep 2015 06:44:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 21557 <at> debbugs.gnu.org (full text, mbox):
On Fri, 25 Sep 2015 04:28:46 -0400, Richard Stallman wrote:
> I received a message whose text was rendered as invisible when I
> viewed it in Rmail. I think it is because of 'color:#000'.
I tried this with the form below and found no problem. Increasing
the value of shr-color-visible-luminance-min raises the contrast.
> I think that if HTML specifies the same color for foreground and
> background, rendering should use different colors so that the text
> can be seen.
shr-color.el should do that. But if you have the fg color of
the variable-pitch face set (to #000), it will have no effect.
Because the new color that shr-color.el chooses is appended, not
prepended to the existing one:
(defun shr-colorize-region (start end fg &optional bg)
[...]
(add-face-text-property start end
(list :foreground (cadr new-colors))
t))
----------------------------------^
I'm not sure whether changing it to nil causes another problem.
My recipe:
emacs -Q -fg white -bg black
(let ((tmp (get-buffer-create "*tmp*")))
(require 'rmailmm)
(with-current-buffer tmp
(erase-buffer)
(insert (quoted-printable-decode-string "\
<html><body><span style=3D\"font-family:Verdana; color:#000; font-size:10pt;=
\"><div>Hi Jeanne</div><div><br></div><div>I know I gave you an address for =
the books to be sent. I am sending you an address at Kent for the books to =
be sent. It makes more sense for the books to be sent there:<br></div><div>=
<br></div></span></body></html>
"))
(insert (prog1
(with-temp-buffer
(rmail-mime-render-html-shr tmp)
(buffer-string))
(erase-buffer)))
(display-buffer tmp)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21557; Package
emacs.
(Mon, 28 Sep 2015 07:32:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 21557 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 28 Sep 2015 15:43:16 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> Cc: 21557 <at> debbugs.gnu.org
>
> On Fri, 25 Sep 2015 04:28:46 -0400, Richard Stallman wrote:
> > I received a message whose text was rendered as invisible when I
> > viewed it in Rmail. I think it is because of 'color:#000'.
>
> I tried this with the form below and found no problem. Increasing
> the value of shr-color-visible-luminance-min raises the contrast.
Does shr-color-visible-luminance-min have any effect on a TTY? I
think Richard is using text-mode frames that support only 8 colors.
So perhaps try this in a TTY frame, and see if you still see no
problems. If you do, perhaps we need some more magic in shr-color.el,
or maybe even in tty-colors.el (unlikely).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21557; Package
emacs.
(Mon, 28 Sep 2015 08:05:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 21557 <at> debbugs.gnu.org (full text, mbox):
On Mon, 28 Sep 2015 10:31:49 +0300, Eli Zaretskii wrote:
> Does shr-color-visible-luminance-min have any effect on a TTY? I
> think Richard is using text-mode frames that support only 8 colors.
Ooops. I verified it doesn't help on a TTY.
So, how about using lynx instead of shr? I.e.,
(setq rmail-mime-render-html-function 'rmail-mime-render-html-lynx)
This requires the external lynx program. As far as I tested, it
doesn't respect the color spec in an html source.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21557; Package
emacs.
(Mon, 28 Sep 2015 08:41:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 21557 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 28 Sep 2015 17:04:31 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> Cc: rms <at> gnu.org, 21557 <at> debbugs.gnu.org
>
> On Mon, 28 Sep 2015 10:31:49 +0300, Eli Zaretskii wrote:
> > Does shr-color-visible-luminance-min have any effect on a TTY? I
> > think Richard is using text-mode frames that support only 8 colors.
>
> Ooops. I verified it doesn't help on a TTY.
> So, how about using lynx instead of shr?
I think an Emacs-only solution would be preferable. Can
shr-color-visible-luminance-min be adapted to a small number of
colors? The simplest would perhaps be just overriding the foreground
color with something that is legible on the background color.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21557; Package
emacs.
(Mon, 28 Sep 2015 10:38:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 21557 <at> debbugs.gnu.org (full text, mbox):
On Mon, 28 Sep 2015 11:40:12 +0300, Eli Zaretskii wrote:
> I think an Emacs-only solution would be preferable. Can
> shr-color-visible-luminance-min be adapted to a small number of
> colors? The simplest would perhaps be just overriding the foreground
> color with something that is legible on the background color.
The most simplest way would be:
--- shr.el~ 2015-08-02 22:23:44.000000000 +0000
+++ shr.el 2015-09-28 10:34:41.025287800 +0000
@@ -1044,3 +1044,3 @@
(defun shr-colorize-region (start end fg &optional bg)
- (when (or fg bg)
+ (when (and (or fg bg) (>= (display-color-cells) 256))
(let ((new-colors (shr-color-check fg bg)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21557; Package
emacs.
(Mon, 28 Sep 2015 13:15:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 21557 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 28 Sep 2015 19:37:45 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> Cc: rms <at> gnu.org, 21557 <at> debbugs.gnu.org
>
> On Mon, 28 Sep 2015 11:40:12 +0300, Eli Zaretskii wrote:
> > I think an Emacs-only solution would be preferable. Can
> > shr-color-visible-luminance-min be adapted to a small number of
> > colors? The simplest would perhaps be just overriding the foreground
> > color with something that is legible on the background color.
>
> The most simplest way would be:
>
> --- shr.el~ 2015-08-02 22:23:44.000000000 +0000
> +++ shr.el 2015-09-28 10:34:41.025287800 +0000
> @@ -1044,3 +1044,3 @@
> (defun shr-colorize-region (start end fg &optional bg)
> - (when (or fg bg)
> + (when (and (or fg bg) (>= (display-color-cells) 256))
> (let ((new-colors (shr-color-check fg bg)))
>
Richard, does this solve your problems?
I wonder whether 256 above should be replaced with a much lower
number, like 88, perhaps?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21557; Package
emacs.
(Mon, 28 Sep 2015 19:10:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 21557 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > (defun shr-colorize-region (start end fg &optional bg)
> > - (when (or fg bg)
> > + (when (and (or fg bg) (>= (display-color-cells) 256))
This fixes it. Thanks.
> I wonder whether 256 above should be replaced with a much lower
> number, like 88, perhaps?
I don't know.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21557; Package
emacs.
(Mon, 28 Sep 2015 23:03:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 21557 <at> debbugs.gnu.org (full text, mbox):
On Mon, 28 Sep 2015 16:14:46 +0300, Eli Zaretskii wrote:
>> + (when (and (or fg bg) (>= (display-color-cells) 256))
> I wonder whether 256 above should be replaced with a much lower
> number, like 88, perhaps?
256 means `Depth 8 Pseudo Color', i.e., 24bit color (R:8bit,
G:8bit, B:8bit) but only 256 cells in the color pallet, AFAIK.
It matches shr-color.el that calculates colors based on 24bit.
But I don't know what is 88-color system. Is it not based on
24bit color? If not, a color shr-color offers will be too dim.
Reply sent
to
Katsumi Yamaoka <yamaoka <at> jpl.org>:
You have taken responsibility.
(Tue, 29 Sep 2015 02:03:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
rms <at> gnu.org:
bug acknowledged by developer.
(Tue, 29 Sep 2015 02:03:03 GMT)
Full text and
rfc822 format available.
Message #34 received at 21557-done <at> debbugs.gnu.org (full text, mbox):
On Mon, 28 Sep 2015 15:09:46 -0400, Richard Stallman wrote:
>>> (defun shr-colorize-region (start end fg &optional bg)
>>> - (when (or fg bg)
>>> + (when (and (or fg bg) (>= (display-color-cells) 256))
> This fixes it. Thanks.
Done.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21557; Package
emacs.
(Tue, 29 Sep 2015 05:11:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 21557 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 29 Sep 2015 08:02:17 +0900
> From: Katsumi Yamaoka <yamaoka <at> jpl.org>
> Cc: rms <at> gnu.org, 21557 <at> debbugs.gnu.org
>
> On Mon, 28 Sep 2015 16:14:46 +0300, Eli Zaretskii wrote:
> >> + (when (and (or fg bg) (>= (display-color-cells) 256))
>
> > I wonder whether 256 above should be replaced with a much lower
> > number, like 88, perhaps?
>
> 256 means `Depth 8 Pseudo Color', i.e., 24bit color (R:8bit,
> G:8bit, B:8bit) but only 256 cells in the color pallet, AFAIK.
> It matches shr-color.el that calculates colors based on 24bit.
> But I don't know what is 88-color system. Is it not based on
> 24bit color? If not, a color shr-color offers will be too dim.
88-color modes are supported by newer versions of xterm.
My reasoning was that when you have 88 colors to use,
shr-color-visible-luminance-min might do its job well enough for us to
be able to honor the colors requested by HTML.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21557; Package
emacs.
(Tue, 29 Sep 2015 06:33:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 21557 <at> debbugs.gnu.org (full text, mbox):
On Tue, 29 Sep 2015 08:10:59 +0300, Eli Zaretskii wrote:
> 88-color modes are supported by newer versions of xterm.
> My reasoning was that when you have 88 colors to use,
> shr-color-visible-luminance-min might do its job well enough for us to
> be able to honor the colors requested by HTML.
Ok. I've changed >=256 to >=88.
Though my xterm on Cygwin doesn't seem to support above 8 colors,
I understood how Emacs treats a 24-bit color spec on it. So, I
can imagine it will be useful on 88-color tty if
shr-color-visible-luminance-min
(and also shr-color-visible-distance-min?)
are customized properly.
Thanks.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 27 Oct 2015 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 241 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.