headers
Uwe Brauer | 16 May 2002 23:58
X-Face
Picon

Re: [preview-latex-devel] rel-0-7-2b; prob in native Xemacs win9x using binareis

David Kastrup writes:
 > Uwe Brauer <oub <at> eucmos.sim.ucm.es> writes:
 > 
 > > David Kastrup writes:
 > >  > Uwe Brauer <oub <at> eucmos.sim.ucm.es> writes:
 > >  > 
 > >  > > David Kastrup writes:
 > > 
 > >  > Well... if you had been able to use M-x preview-report-bug <RET> on
 > >  > the machine in question, the message would have told us that, as well

David Kastrup writes:
 > Uwe Brauer <oub <at> eucmos.sim.ucm.es> writes:
 > 
 > > David Kastrup writes:
 > >  > Uwe Brauer <oub <at> eucmos.sim.ucm.es> writes:
 > >  > 
 > >  > > David Kastrup writes:
 > > 
 > >  > Well... if you had been able to use M-x preview-report-bug
 > >  > <RET> on the machine in question, the message would have told
 > >  > us that, as well as telling us what images are supported by
 > >  > Emacs -- no wait, this part of the reporting code will
 > >  > probably not work with XEmacs.  Nick?
 > > Yep, it is sort of painful though, the machine of question has no
 > > internet connection, so I have to save the bug-report message and
 > > paste it in another file in the other machine.

Err I realized that I already _sent_ you a bug report, in any case I  attach
one again.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Nix | 17 May 2002 01:25
Picon
Picon

Re: [preview-latex-devel] rel-0-7-2b; prob in native Xemacs win9x using binareis

[andy, this is a preview-latex problem with subprocesses seemingly
 outputting nonsense, or something; it's not yet clear: normally
 I'd not bother you with it, but I noticed what XEmacs version
 he was using, and what patches seemed to be in there...]

On Thu, 16 May 2002, Uwe Brauer spake:
> Emacs  : XEmacs 21.4 (patch 7) "Economic Science (Windows [1])" [Lucid] (i586-pc-win32) of Tue May 07 2002
on TSUNAMI

You should upgrade this at once; it has my lethally buggy patch

2002-04-17  Nix  <nix <at> esperi.demon.co.uk>

      * process.h (PROCESS_LIVE_P): Use the process status as
      evidence of health, not the state of the input stream.

which causes process output from processes sent just before they die to
get thrown away :(

Andy has reverted the patch but not released anything with the reverted
patch in it that I can see: Andy, you might want to apply
<http://list-archive.xemacs.org/xemacs-patches/200205/msg00043.html> and
release a 21.4.7 [2], or 21.4.8, or something. That patch is working
fine in 21.4.8 (at least nobody is complaining about process problems
anymore).

I'm fairly sort of vaguely sure that that original buggy patch is
probably perhaps maybe causing problems here.

(A dead giveaway would be if the TeX output buffer in XEmacs is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alessandro Russo | 17 May 2002 12:04
Picon

rel-0-7-2b; background colors don't work correctly


Remember to cover the basics.  Including a minimal LaTeX example
file exhibiting the problem might help.

Change the background color with, say,

M-x set-background-color RET
grey40 RET

then regenerate preview. The background color
of the previewed objects is not exactly equal
to the background of emacs. This happens also
with blue.

Ciao

Ale

Emacs  : GNU Emacs 21.2.2 (sparc-sun-solaris2.7, X toolkit)
 of 2002-04-15 on dragon
Package: rel-0-7-2b

current state:
==============

Output from running `gs -h':
AFPL Ghostscript 7.04 (2002-01-31)
Copyright (C) 2001 artofcode LLC, Benicia, CA.  All rights reserved.
Usage: gs [switches] [file1.ps file2.ps ...]
Most frequently used switches: (you can use # in place of =)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Andy Piper | 17 May 2002 17:07

Re: [preview-latex-devel] rel-0-7-2b; prob in native Xemacs win9x using binareis

Actually the current downloadable version should not have this problem. 
However, since I did not up the rev number its conceivable that you have 
the Windows [1] "Director's Cut" version. I suggest uninstalling and 
reinstalling from the net.

andy

At 12:25 AM 5/17/2002 +0100, Nix wrote:
>[andy, this is a preview-latex problem with subprocesses seemingly
>  outputting nonsense, or something; it's not yet clear: normally
>  I'd not bother you with it, but I noticed what XEmacs version
>  he was using, and what patches seemed to be in there...]
>
>On Thu, 16 May 2002, Uwe Brauer spake:
> > Emacs  : XEmacs 21.4 (patch 7) "Economic Science (Windows [1])" [Lucid] 
> (i586-pc-win32) of Tue May 07 2002 on TSUNAMI
>
>You should upgrade this at once; it has my lethally buggy patch
>
>2002-04-17  Nix  <nix <at> esperi.demon.co.uk>
>
>       * process.h (PROCESS_LIVE_P): Use the process status as
>       evidence of health, not the state of the input stream.
>
>which causes process output from processes sent just before they die to
>get thrown away :(
>
>Andy has reverted the patch but not released anything with the reverted
>patch in it that I can see: Andy, you might want to apply
><http://list-archive.xemacs.org/xemacs-patches/200205/msg00043.html> and
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Kastrup | 21 May 2002 01:02
Picon
Favicon

Re: [preview-latex-devel] rel-0-7-2b; background colors don't work correctly

Alessandro Russo <russo <at> dragon.ian.pv.cnr.it> writes:

> Remember to cover the basics.  Including a minimal LaTeX example
> file exhibiting the problem might help.
> 
> Change the background color with, say,
> 
> M-x set-background-color RET
> grey40 RET
> 
> then regenerate preview. The background color
> of the previewed objects is not exactly equal
> to the background of emacs. This happens also
> with blue.

This is a known issue.  A number of factors come into play here, and
you'll find that the CVS version of Emacs will exhibit a different
behavior while still not being satisfactory or consistent.

The problem is that Emacs has its idea of foreground and background
colors (which has 16 bits per base color), and it has its idea of what
gamma correction factor to apply to those colors when mapping them to
the screen.  It also applies this gamma correction in some manner
when mapping the colors of PNG or other graphic files to the screen.
The function preview-gs-get-colors is supposed to pick off Emacs'
idea of background and foreground colors and turn them into
Postscript tokens regenerating just this color in the PNG file.  The
current Emacs code is a bit of a moving target, and making sure that
the colors match after Emacs' own process of
(Continue reading)

Permalink | Reply | 4 comments |
headers
Uwe Brauer | 23 May 2002 21:14
X-Face
Picon

Bug in native W9x xemacs-21.4.8 remains using binareis

David Kastrup writes:

 > > 2. Ghostscript is It is not called gs, but gswin32c.ex, so since the
 > >    concept of a link does not exist, I just copied this executable to
 > >    gs.
 > 
 > Not necessary.  Just use
 > M-x customize-variable RET preview-gs-command RET

Yep I thought of this, but then since I was not sure whether the 
W9 syntax c:\ would be understand (also it should) I used this way

 > 
 > This should only happen when you are using an outdated version of
 > preview-latex, or when you have configured the variable
 > preview-fast-conversion to `nil' (for which I would know no reason).
 > This method of generating previews is quite slower, and in general
 > produces less accurate bounding boxes in a number of cases.
Yep I use it only for prosper since there the result looks a little
better but yeah I had it turned on globally I should not.

 
 > Quite so.  I would have thought that the preview-latex documentation
 > discourages this explicitly enough.  Seems I have been mistaken.  We
 > will probably pull this option entirely from the code: it seems quite
 > unlikely that it will ever become more efficient and convenient than
 > the current mechanisms of preview-latex.  If it does, it will probably
 > be easier to rewrite the appropriate code from scratch rather than
 > having to drag and maintain it through successive iterations of
 > preview-latex.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Alessandro Russo | 24 May 2002 10:16
Picon

Re: [preview-latex-devel] rel-0-7-2b; background colors don't work correctly

> Alessandro Russo <russo <at> dragon.ian.pv.cnr.it> writes:
> 
> > Remember to cover the basics.  Including a minimal LaTeX example
> > file exhibiting the problem might help.
> > 
> > Change the background color with, say,
> > 
> > M-x set-background-color RET
> > grey40 RET
> > 
> > then regenerate preview. The background color
> > of the previewed objects is not exactly equal
> > to the background of emacs. This happens also
> > with blue.
> 
> This is a known issue.  A number of factors come into play here, and
> you'll find that the CVS version of Emacs will exhibit a different
> behavior while still not being satisfactory or consistent.
> 

Sorry if my question is silly, but can't emacs display images
with transparent background?

A. Russo

--

-- 
Alessandro Russo
----------------
Istituto di Analisi Numerica - CNR
via Ferrata, 1
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Kastrup | 24 May 2002 10:39
Picon
Favicon

Re: [preview-latex-devel] rel-0-7-2b; background colors don't work correctly

Alessandro Russo <russo <at> dragon.ian.pv.cnr.it> writes:

> > Alessandro Russo <russo <at> dragon.ian.pv.cnr.it> writes:
> > 
> > > Remember to cover the basics.  Including a minimal LaTeX example
> > > file exhibiting the problem might help.
> > > 
> > > Change the background color with, say,
> > > 
> > > M-x set-background-color RET
> > > grey40 RET
> > > 
> > > then regenerate preview. The background color
> > > of the previewed objects is not exactly equal
> > > to the background of emacs. This happens also
> > > with blue.
> > 
> > This is a known issue.  A number of factors come into play here, and
> > you'll find that the CVS version of Emacs will exhibit a different
> > behavior while still not being satisfactory or consistent.
> > 
> 
> Sorry if my question is silly, but can't emacs display images
> with transparent background?

Your question is not silly, but transparency is already employed for
a different task.  This is mentioned in the documentation, but
seemingly not clearly enough.  Please propose how to better present
this.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nix | 26 May 2002 13:55
Picon
Picon

Re: [preview-latex-devel] Bug in native W9x xemacs-21.4.8 remains using binareis

On Thu, 23 May 2002, Uwe Brauer mused:
> David Kastrup writes:
> 
>  > > 2. Ghostscript is It is not called gs, but gswin32c.ex, so since the
>  > >    concept of a link does not exist, I just copied this executable to
>  > >    gs.
>  > 
>  > Not necessary.  Just use
>  > M-x customize-variable RET preview-gs-command RET
> 
> Yep I thought of this, but then since I was not sure whether the 
> W9 syntax c:\ would be understand (also it should) I used this way

It depends on your XEmacs build: if it's a native build, it is
understood. (cygwin builds are intentionally trying to remove that sort
of DOSism, so it's not understood there.)

>  > Quite so.  I would have thought that the preview-latex documentation
>  > discourages this explicitly enough.  Seems I have been mistaken.  We
>  > will probably pull this option entirely from the code: it seems quite
>  > unlikely that it will ever become more efficient and convenient than
>  > the current mechanisms of preview-latex.  If it does, it will probably
>  > be easier to rewrite the appropriate code from scratch rather than
>  > having to drag and maintain it through successive iterations of
>  > preview-latex.

If I remember, it was originally there to make sure that even if the
fast-conversion stuff turned out to be broken, we still had something
to go back to.
(Continue reading)

Permalink | Reply | 10 comments |
headers
David Kastrup | 26 May 2002 14:23
Picon
Favicon

Re: [preview-latex-devel] Bug in native W9x xemacs-21.4.8 remains using binareis

Nix <nix <at> esperi.demon.co.uk> writes:

> >  > Quite so.  I would have thought that the preview-latex documentation
> >  > discourages this explicitly enough.  Seems I have been mistaken.  We
> >  > will probably pull this option entirely from the code: it seems quite
> >  > unlikely that it will ever become more efficient and convenient than
> >  > the current mechanisms of preview-latex.  If it does, it will probably
> >  > be easier to rewrite the appropriate code from scratch rather than
> >  > having to drag and maintain it through successive iterations of
> >  > preview-latex.
> 
> If I remember, it was originally there to make sure that even if the
> fast-conversion stuff turned out to be broken, we still had something
> to go back to.

You are again confusing things.  The "postscript" image type was
"originally there" because it was the only image type that was
originally there.  It has nothing to do with slow conversion (which
lets dvips crank out EPS then converted into PNG and is still
well-supported in two different variants, depending on the setting of
preview-prefer-TeX-bb), apart from being much more deserving of the
"slow" moniker, and it is quite broken, to boot.

> Since we know fast-conversion works, and the slow stuff is gently
> rotting, yanking it is probably right :)

The slow stuff is doing alright, it is the "GNU Emacs will render EPS
by itself, at least it thinks it can, but watching its pathetic
attempts of manhandling GhostScript is pitiful" stuff that is bit
rotting.  It appears it is due to a renaissance however: the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane