text/html rendering erroneously uses frame-width

text/html rendering erroneously uses frame-width

[Karl Kleinpaste]

I use a kinda complicated gnus-buffer-configuration (see bottom) which
gives me both horizontal and vertical window splits.  The rendering of
text/html segments appears to be determining line width on the basis
of (frame-width), which is large, rather than (window-width), which is
much smaller.  The result is a really horridly ugly line-wrapped
display of text/html.

I don't really know if this is a Gnus or W3 issue, but I thought I'd
mention it, since the relevant authors are both accessible here.

A quick look through the w3 sources only finds frame-width uses in
css.el, devices.el, and url.el.  Hm, odd.  Any ideas on fixing this?

Screenshots of mis-behavior can be found in
http://www.cs.cmu.edu/~karl/pgnus/html-too-wide.

--karl

(defun gnus-karl-x-config ()
  "*Definitions of window usage: X."
  (interactive)
  (gnus-add-configuration
   '(summary
     (horizontal 1.0
		 (vertical 1.0
			   (group 0.25) (summary 1.0 point)))))
  (gnus-add-configuration
   '(article
     (horizontal 1.0
		 (vertical 0.4 (group 0.25) (summary 1.0 point))
		 (vertical 1.0 (tree  0.25) (article 1.0)))))
  (gnus-add-configuration
   '(message
     (horizontal 1.0
		 (vertical 0.4 (group 0.25) (message 1.0 point))
		 (vertical 1.0 (tree  0.25) (article 1.0)))))
  (gnus-add-configuration
   '(reply
     (horizontal 1.0
		 (vertical 0.4 (group 0.25) (message 1.0 point))
		 (vertical 1.0 (tree  0.25) (article 1.0)))))
  (gnus-add-configuration
   '(post
     (horizontal 1.0
		 (vertical 0.4 (group 0.25) (post 1.0 point))
		 (vertical 1.0 (tree  0.25) (article 1.0)))))
  (gnus-add-configuration
   '(edit-score
     (horizontal 1.0
		 (vertical 0.4 (group 0.25) (summary 1.0))
		 (vertical 1.0 (tree  0.25) (edit-score 1.0 point)))))
  (gnus-add-configuration
   '(mail-forward
     (horizontal 1.0
		 (vertical 0.4 (group 0.25) (summary 1.0))
		 (vertical 1.0 (tree  0.25) (mail 1.0 point))))))

Re: text/html rendering erroneously uses frame-width

[Lars Magne Ingebrigtsen]

Karl Kleinpaste <karl@jprc.com> writes:

> I don't really know if this is a Gnus or W3 issue, but I thought I'd
> mention it, since the relevant authors are both accessible here.

I think it's probably a w3 bug, since Gnus just calls `w3-region'.
Er.  But it doesn't call that from the buffer that it's actually
displayed in.  It does a `with-temp-buffer' and reders the thing there
before copying over.  Could that be a source of the problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: text/html rendering erroneously uses frame-width

[William M. Perry]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Karl Kleinpaste <karl@jprc.com> writes:
> 
> > I don't really know if this is a Gnus or W3 issue, but I thought I'd
> > mention it, since the relevant authors are both accessible here.
> 
> I think it's probably a w3 bug, since Gnus just calls `w3-region'.
> Er.  But it doesn't call that from the buffer that it's actually
> displayed in.  It does a `with-temp-buffer' and reders the thing there
> before copying over.  Could that be a source of the problem?

  gnus could let-bind w3-strict-width to the appropriate width before
calling w3-region.

-Bill P.

Re: text/html rendering erroneously uses frame-width

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

>   gnus could let-bind w3-strict-width to the appropriate width before
> calling w3-region.

Yup.  Fix in Pterodactyl Gnus v0.43.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: text/html rendering erroneously uses frame-width

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> But it doesn't call that from the buffer that it's actually
> displayed in.  It does a `with-temp-buffer' and reders the thing there
> before copying over.  Could that be a source of the problem?

Perhaps.  The important fact is that whatever function is in charge of
geometry of rendering has to know the size of the actual *Article*
buffer where the result is destined to land.  This might be
complicated by the fact that *Article* may not even exist yet when
rendering is begun.  I'm afraid I'm at a bit of a loss just now to
find in w3/*.el exactly how the (currently wrong) choice is being made.