Incorporating .epsi files into TeX docs : failure

2003-08-11 Thread fergus
Can _you_ incorporate .epsi files into TeX docs and then make a viewable
.dvi? I can't ... please read on if you might be able to help ... thank you.

W98/SE. Current and complete installation. I start X like this:

1. Start -> Run -> start Xwin -multiwindow
2. Start -> Run -> run rxvt -display :0.0 -e bash

X applications work superbly. In particular latex and xdvi work just fine
(apart from irritating but otherwise ?inconsequential? error msg from xdvi
after quitting the viewer, being

fcntl F_SETOWN (xdvi): Invalid argument

I suppress this (if I want to) with

xdvi filename.dvi 2>/dev/null

However, I'm having trouble incorporating diagrams into a TeX document. In
draft mode there is no problem as in

\documentclass{article}
\usepackage[draft]{graphicx}
\begin{document}
.. 
\begin{figure}[ht]
\centering
\includegraphics{diagram.epsi}
\caption{This is a test diagram}
\end{figure}
..
\end{document}

which presents a nice maths-y page to screen with a 'holding rectangle'
containing text "diagram.epsi" in exactly the right place.

BUT if I omit the [draft] instruction ( ie just the sequence [draft] leaving
\usepackage{graphicx} ), then the command "latex testdoc.tex" is apparently
processed trouble-free but gives rise to a testdoc.dvi that is actually
_smaller_  than that resulting when in [draft] mode, and the command "xdvi
testdoc.dvi" EITHER flashes a .dvi briefly to screen which then vanishes  OR
shows the .dvi up to but not including the diagram and then stalls with the
Windows eggtimer on screen. Pressing Quit gives the error msg

gs: Unknown device: x11

I realise this may be a user-generated TeX problem, but I have tried
everything to get this to work, and the fact that in [draft] mode it does
work, suggests that at least something, if not everything, is set correctly
... the error msg just described also suggests that maybe I'm setting
something up wrong that is X-related? Even in lines 1. and 2. maybe ...

By the way, the .epsi file is created from an original .dvi using

dvips diagram.dvi # to make diagram.ps
ps2epsi diagram.ps # to make diagram.epsi


Thank you for any help you can offer, if you routinely manage this
successfully.

Fergus



Re: Incorporating .epsi files into TeX docs : failure

2003-08-11 Thread fergus
Thank you very much indeed. I put /usr/X11R6/bin/ before /usr/bin/ in the
PATH so that the gs.exe I wanted was picked up before the other gs.exe I
didn't want. Now it all works perfectly. I'll leave PATH defined like this
(i.e. with the transposition).

There may be other consequences, not all good, since I don't always start
XWin ... we'll see.

Thanks again.

Fergus



Re: rfe: seamless windows integration (fwd)

2003-08-11 Thread Igor Pechtchanski
On Wed, 6 Aug 2003, Jim Drash wrote:

> Sorry, I posted this to the wrong list (a finger-fuddle),
>
> -- Forwarded message --
> Date: Wed, 6 Aug 2003 11:04:43 -0400
> From: Jim Drash <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: rfe: seamless windows integration
>
> Maybe I am a little slow but if someone wants a shortcut to the "X" apps
> can't they just create a short cut to the "C:\cygwin\use\X11R6\bin"
> directory?
>
> Again, I am into the KISS (Keep It Simple, cause I am Stupid) method for
> most things.
>
> Am I missing something?
>
> Jim Drash

Some programs require parameters (or, at least, DISPLAY to be set).
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton



Re: Xwin remote calls to Solaris machines/ font server bug

2003-08-11 Thread Harold L Hunt II
Dr.D.J.Picton wrote:
I have two observations to make concerning the use of 'XWin -query' to
Solaris machines.
1.  Firstly, the FAQ states that Solaris can't cope with 24-bit colour
depths.  This may have been true for older releases, but all recent versions
of Solaris (and recent Sun hardware) support this depth!
2.  The FAQ refers to the 'hang' when you attempt to contact a remote Solaris
host using XWin -query e.g.
Xwin -query sunhost

The cure is to specify a Solaris font server on the command line, e.g.

XWin -query sunhost -fp tcp/sunhost:7100

However, this shouldn't be necessary for recent Solaris releases.  The XSetup
script on the Sun machine automatically adds the font server to the font
path, before the dtlogin window appears.
Okay, so people running newer versions of Solaris won't look at the FAQ. 
 No problem there.

The real reason for the problem is a bug in XWin, which 'hangs' if I
try to mix local fonts with a Solaris font server.
The following procedures work OK:

1.  Start up an XWin server with normal local fonts, then replace them with
a Solaris font server:
xset fp= tcp/sunhost:7100
2.  Start up an Xwin server with -fp tcp/sunhost:7100 on the command line.

3.  Add a second Solaris font server when the fontpath already contains one.

The following procedures cause a 'hang':

1.  Start up an XWin server with normal local fonts, then append a Solaris
font server:
xset fp+ tcp/sunhost:7100

2.  Start up an XWin server with -fp tcp/sunhost:7100 on the command line,
then try to append a local font to the path:
xset fp+ /usr/X11R6/lib/X11/fonts/misc
I am inclined to believe you.  However, I do not have a Solaris machine 
that I can test this with.  It would be most helpful if either yourself 
or someone with a similar setup could build a debug version of XWin.exe 
and step through this until they find the hang.

Thanks,

Harold



RE: DDD dies on me

2003-08-11 Thread Andrew Braverman
It is definitely XWin that is crashing.  I seem to have had some mental
block when I wrote the last message because I could swear I had said it died
in 24 bit, but the text doesn't lie...  I will try putting a bunch of ErrorF
statements in and send the resulting log file ASAP.  Thanks.

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Earle F. Philhower,
> III
> Sent: Monday, August 11, 2003 2:27 PM
> To: [EMAIL PROTECTED]
> Subject: Re: DDD dies on me
>
>
> Howdy Andrew...
>
> -- Original Message -
> Subject: DDD dies on me
> From: "Andrew Braverman" <[EMAIL PROTECTED]>
> A while ago (beginning of June, I think), I posted a note to
> this group that
> ..
> to figure out that the program occurred in winScaleXBitmapToWindows in
> winmultiwindowicons.c.  I ran three consecutive tests and two
> of those three
> caused a segfault in the free at the end of the procedure (actually in
> mktime??? called by free).  The iconData mallocs at the
> beginning of the
> procedure seem to align correctly with the frees at the end.  The last
> caused a segfault in fb24_32BltUp which is called from the
> miGetImage at the
> beginning of the procedure.  Seeing that, I decided to try
> the program in 16
> bit color and everything was fine.  For the first time, I was
> able to see
> that this program does display its own icon on the title bar.
>  Does anyone
> (Earle?) have any suggestions about where I should start
> digging?  In any
> case, I will try to do a little more digging over the next week or so.
> -
>
> A silly question, it is XWin.exe that's SEGVíng and not
> DDD.exe, correct?
> And what was the screen depth (8/15/16/24/32) you were running that
> caused the bomb?
>
> Also, could you add some ErrorF()s to dump all local variables to the
> /tmp/XWin.log file, as well as the pixmap->drawable structure
> elements,
> too?  [ErrorF() works just like printf() so just
> ErrorF("varX=%d\n",varX);
> is all that's needed...]  Posting the info it spits out
> before a SEGV would
> go a long way towards debugging this...
>
> The most likely culprit is that one of the conversions is
> overwriting the
> Windows icon data that it's allocated, causing bad stuff to
> happen later
> on.  You can see how I switch between the possible formats on
> effXBPP and effBPP(the Windoze BPP we're converting to), possibly not
> all cases have been tested, *especially* 8-bit modes.
> --
> -Earle F. Philhower, III
>  [EMAIL PROTECTED]
>  http://www.ziplabel.com
>
>




Re: DDD dies on me

2003-08-11 Thread Earle F. Philhower, III
Howdy Andrew...

-- Original Message -
Subject: DDD dies on me
From: "Andrew Braverman" <[EMAIL PROTECTED]>
A while ago (beginning of June, I think), I posted a note to this group that
..
to figure out that the program occurred in winScaleXBitmapToWindows in
winmultiwindowicons.c.  I ran three consecutive tests and two of those three
caused a segfault in the free at the end of the procedure (actually in
mktime??? called by free).  The iconData mallocs at the beginning of the
procedure seem to align correctly with the frees at the end.  The last
caused a segfault in fb24_32BltUp which is called from the miGetImage at the
beginning of the procedure.  Seeing that, I decided to try the program in 16
bit color and everything was fine.  For the first time, I was able to see
that this program does display its own icon on the title bar.  Does anyone
(Earle?) have any suggestions about where I should start digging?  In any
case, I will try to do a little more digging over the next week or so.
-

A silly question, it is XWin.exe that's SEGVíng and not DDD.exe, correct?
And what was the screen depth (8/15/16/24/32) you were running that
caused the bomb?

Also, could you add some ErrorF()s to dump all local variables to the
/tmp/XWin.log file, as well as the pixmap->drawable structure elements,
too?  [ErrorF() works just like printf() so just ErrorF("varX=%d\n",varX);
is all that's needed...]  Posting the info it spits out before a SEGV would
go a long way towards debugging this...

The most likely culprit is that one of the conversions is overwriting the
Windows icon data that it's allocated, causing bad stuff to happen later
on.  You can see how I switch between the possible formats on
effXBPP and effBPP(the Windoze BPP we're converting to), possibly not
all cases have been tested, *especially* 8-bit modes.
-- 
-Earle F. Philhower, III
 [EMAIL PROTECTED]
 http://www.ziplabel.com



emacs menubar not working

2003-08-11 Thread Supreme Commander
Hi
I normally use RedHat to dev. FORTRAN programs, but dowloaded cygwin; full 
package to develop the programs there instead. I use Emacs as editor.

My problem is
1) I cannot use the menu in Emacs. I have tried to add a 'tty export' key in 
registry (why I dont really know, but it was recommended in some mail I 
read), but it does not help.
2) There is no color-coding for .f files. I.e when I write 'implicit none', 
this usually turn green.

Can cygwin provide similar programming environment as Redhat does?

_
MSN Messenger http://www.msn.no/messenger - Den korteste veien mellom deg og 
dine venner



Re: Incorporating .epsi files into TeX docs : failure

2003-08-11 Thread Alexander Gottwald
On Sun, 10 Aug 2003 [EMAIL PROTECTED] wrote:

> gs: Unknown device: x11

The ghostscript package was not compiled with X11 support. You can either
compile it yourself or ask the maintainer of ghostscript if he could provide
binaries with x11 support too.

bye
ago
-- 
 [EMAIL PROTECTED] 
 http://www.gotti.org   ICQ: 126018723


Re: maximum number of open sessions from your host reached

2003-08-11 Thread Alexander Gottwald
On Mon, 11 Aug 2003 [EMAIL PROTECTED] wrote:

> Hi,
> I have a problem with Cygwin XFree. I tried to connect our local
> linux-server with -query $host option, but XWin.log tells me that server
> refused the connection with error message "XDCMP fatal error: Session
> declined Maximum number of open sessions from your host reached" 

I doubt this has anything to do with the xserver.

Ask your login server admin if there is a special entry for your host
in the config file. Maybe your host is in a special subnet or your host
is blocked for some other reason.

bye
ago
-- 
 [EMAIL PROTECTED] 
 http://www.gotti.org   ICQ: 126018723