From: sasjqw@kanga.unx.sas.com (Jon White)
Subject: Xfig 2.1.4 Bug Fixes Summary
Originator: sasjqw@kanga.unx.sas.com
Date: Tue, 29 Sep 1992 17:05:00 GMT
Organization: SAS Institute Inc.
Keywords: xfig


In article <cj.717400292@melusine>, cj@isy.liu.se (Christian Jonsson) writes:
|> I think it would be a good idea to post a summary to the net. Probably
|> more people than the two of us want this information.

Here's the text of all recent xfig.2.1.4 questions and
bug fixes posted to comp.windows.x.apps.  

Hope this helps.

--Jon


From: alfred@arthur.et.tudelft.nl (Alfred van der Hoeven)
Subject: Re: bug in xfig 2.1.4
Date: Fri, 11 Sep 92 14:55:09 EDT

In article <1992Sep11.152946.8960@informatik.uni-bremen.de>, cop18@lehre24.informatik.Uni-Bremen.DE (Kompilerpraktikum Gruppe18) writes:
|> At first, I want to thank you for your fast support. After patching u_undo.c and
|> object.c, our HP9000-compiler got through.
|>
|> I started xfig and it worked fine until I wanted to load an example !
|> After opening the Filemenu and clicking randomly on the FileSelector, the
|> program core-dumped.
|>
|> I tried this several times, but everytime the same happend. I hope that there are
|> some patches for this bug.
|>
|> Hopefully you can help me this time again.
|>
|>
|>                                     Dirk
|>

Maybe I can, although I am not really an X expert.

The files w_export.c (at line 238) and w_file.c (at line 204)
contain the text:

        popdown_actions = XtParseTranslationTable("<Btn1Up>:\n");


The argument "<Btn1Up>:\n" appears to be incorrect, according to the
manual page of 'XtParseTranslationTable'.

When I commented out these lines and the next lines that use
the variable 'popdown_actions', the core dumps stayed away.
This will probably work for you, too.

Brian, maybe you can comment on the purpose of these lines ?

--

From: envbvs@epb9.lbl.gov (Brian V. Smith)
Subject: Re: bug in xfig 2.1.4
Date: Fri, 11 Sep 92 17:59:18 EDT

In article <1992Sep11.185509.20661@donau.et.tudelft.nl>,
                alfred@arthur.et.tudelft.nl (Alfred van der Hoeven) writes:
|> In article <1992Sep11.152946.8960@informatik.uni-bremen.de>,
                cop18@lehre24.informatik.Uni-Bremen.DE (Kompilerpraktikum Gruppe18) writes:
|> |> At first, I want to thank you for your fast support. After patching u_undo.c and
|> |> object.c, our HP9000-compiler got through.
|> |>
|> |> I started xfig and it worked fine until I wanted to load an example !
|> |> After opening the Filemenu and clicking randomly on the FileSelector, the
|> |> program core-dumped.

|>
|> Maybe I can, although I am not really an X expert.
|>
|> The files w_export.c (at line 238) and w_file.c (at line 204)
|> contain the text:
|>
|>      popdown_actions = XtParseTranslationTable("<Btn1Up>:\n");
|>
|>
|> The argument "<Btn1Up>:\n" appears to be incorrect, according to the
|> manual page of 'XtParseTranslationTable'.
|>
|> When I commented out these lines and the next lines that use
|> the variable 'popdown_actions', the core dumps stayed away.
|> This will probably work for you, too.
|>
|> Brian, maybe you can comment on the purpose of these lines ?
                                |                 fax: +31 (0)15 623271
You know, I don't know why those are there.  It appears to undo any translation
that button 1 might have, but according to the form widget (where it is
installed) there are no default translations anyway.

So, the upshot is that you may remove the two lines from w_export.c and w_file.c
that parse the translation and override the translations.

Thanks for the answer to Dirk's problem, Alfred.  I'll remove those lines
for the next release of xfig.

--

From: envbvs@epb9.lbl.gov (Brian V. Smith)
Subject: Re: bug in xfig 2.1.4
Date: Fri, 11 Sep 92 18:09:19 EDT

In article <26247@dog.ee.lbl.gov>, I wrote:

        [...]

|> So, the upshot is that you may remove the two lines from w_export.c and w_file.c
|> that parse the translation and override the translations.

The same problem exists in w_print.c.  Do the same thing there also.

--

From: alfred@arthur.et.tudelft.nl (Alfred van der Hoeven)
Subject: Another bug in xfig 2.1.4
Date: Sun, 13 Sep 92 07:37:09 EDT

I found another problem with xfig, when running the program on
an HP9000/720, for which I have a fix but no solution.
When I want to change a previously entered text, using the 'Edit' menu option,
it tends to exchange lowercase characters for uppercase characters.

For instance, if I enter the string 'abcdefghij' in the
text modification window, I instead see (and get) the string 'AbcDEfghIj'.

Apparently, it has something to do with the file 'CompKeyDB', because
if I invoke the program with 'xfig -k ""', the text modification window
works OK.

The problem does not appear when I run xfig on a SUN sparcstation,
so it may be an HP problem instead of an xfig problem.

In both cases, I use a SUN 3/60 running X11R4 for the display.

--

From: envbvs@epb9.lbl.gov (Brian V. Smith)
Subject: Re: importing/pasting text wit xfig
Date: Mon, 14 Sep 92 12:47:35 EDT

In article <9+0yw3h@rpi.edu>, wiseb@rigel.cs.rpi.edu (Bowden Wise) writes:
|> Has anyone been able to "paste" text from another window into xfig?
|> There is a little blurb in the man page that talks about using the
|> translations mechanism and to define a key for the canvas.  Has anyone
|> successfully been able to do that?  I tried to do so, but it has no
|> effect; but, I may not be defining the translations properly.
|>
|> If anyone has done this before or has an idea, please let me know.

The default for xfig is to use F18 as the paste key (because on Sun keyboards
that is the Paste key).

If you wish, you can map another key to do the pasting.  In the Fig.ad file
*that comes with xfig* you will see an example of using F20 as the paste key.

--

From: alfred@arthur.et.tudelft.nl (Alfred van der Hoeven)
Subject: Re: Trying to compile xfig2.1.4
Date: Thu, 3 Sep 92 05:09:48 EDT

In article <1992Sep2.110406.27715@bohra.cpg.oz.au>, als@bohra.cpg.oz.au (Anthony Shipman) writes:
|> envbvs@epb9.lbl.gov (Brian V. Smith) writes:
|>
|> >In article <1992Aug31.161745.1912@informatik.uni-bremen.de>, cop18@lehre25.informatik.Uni-Bremen.DE (Kompilerpraktikum Gruppe18) writes:
|> >|> Today I tried to compile xfig 2.1.4 on our HP9000/720. It worked all fine
|> >|> until u_undo.c. After this part part I got a Bus Error and signal 10.
|> >|>
|> >|> Is there somebody who could help out ??
|>
|>
|> >Please send me a stack trace and I'll see what I can find.  First, compile
|> >u_undo.c with the -g option so the full symbol information is available
|> >for the stack trace.
|>
|>
|> Doesn't he mean the compiler crashed, not the program?  If so, try lower
|> levels of optimisation.

The C compiler on the HP9000/700s stumbles over some of the initializations
that take place in u-undo.c (and object.c), which are probably incorrect.
Applying the following patch will probably solve your problem.

----------------------------- cut here ----------------------------
*** u_undo.c    Mon Apr 20 20:57:01 1992
--- u_undo.c    Tue Jul 28 17:39:50 1992
***************
*** 38,45 ****
   * all the "next" fields of objects pointed to by object_tails to NULL.
   */

! F_compound    saved_objects = {0, 0, 0, 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL};
! F_compound    object_tails = {0, 0, 0, 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL};

  /*************** LOCAL *****************/

--- 38,45 ----
   * all the "next" fields of objects pointed to by object_tails to NULL.
   */

! F_compound    saved_objects = {0, { 0, 0 }, { 0, 0 }, NULL, NULL, NULL, NULL, NULL, NULL, NULL};
! F_compound    object_tails = {0, { 0, 0 }, { 0, 0 }, NULL, NULL, NULL, NULL, NULL, NULL, NULL};

  /*************** LOCAL *****************/

*** object.c    Mon Apr 20 20:56:14 1992
--- object.c    Thu Sep  3 11:01:08 1992
***************
*** 21,27 ****

  /************************  Objects  **********************/

! F_compound    objects = {0, 0, 0, 0, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL};

  /************  global object pointers ************/

--- 21,27 ----

  /************************  Objects  **********************/

! F_compound    objects = {0, { 0, 0 }, { 0, 0 }, NULL, NULL, NULL, NULL, NULL, NULL, NULL};

  /************  global object pointers ************/

----------------------------- cut here ----------------------------

--

From: rkl@csc.liv.ac.uk (Richard Lloyd)
Subject: xfig 2.1.4 compiles OK for me on our HP 9000/720s !
Date: Thu, 3 Sep 92 08:47:33 EDT

In article <1992Aug31.161745.1912@informatik.uni-bremen.de>, cop18@lehre25.informatik.Uni-Bremen.DE (Kompilerpraktikum Gruppe18) writes:
> Today I tried to compile xfig 2.1.4 on our HP9000/720. It worked all fine
> until u_undo.c. After this part part I got a Bus Error and signal 10.
>
> Is there somebody who could help out ??

I had to *find* xfig 2.1.4 first ! It's now moved to /contrib/R5fixes/xfig-patches/xfig.2.14.tar.Z on export.lcs.mit.edu

Apart from a slight lp change in u_print.c (to get rid of -oPS, which is not
needed), nothing else needed to be changed.

Our setup ?

HP 9000/720 running HP-UX 8.07 and linking with HP's X11R4 libraries.
CDEBUGFLAGS in our imake setup is set to +O3, which is the highest optimisation
level and u_undo.c went through it OK.

For those who want to try it for themselves, you will find the package on our
anonymous FTP site, ftp.csc.liv.ac.uk, as /hpux/X11/xfig-2.14.tar.Z.

--

From: envbvs@epb9.lbl.gov (Brian V. Smith)
Subject: Re: Need help with xfig
Date: Sun, 6 Sep 92 18:47:00 EDT

        >I just started using "xfig" and was trying to write some Greek symbols in my diagram.
        >I notice there is a "Symbols (Greek)" item in the Text selection menu, but I just
        >couldn't figure out how to generate the symbols, once the menu item is selected.
        >Can anyone help me out there?  Thanks in advance.

I accidently introduced a bug in the font selection code with regard to non-
ISO fonts (e.g. Symbol).  Just change the code in the file u_font.c that adds
iso-8859 to the font name from this:

            strcat(template,"*-*-*-*-*-*-iso8859-*");

to this:
            strcat(template,"*-*-*-*-*-*-*-*");

There are TWO such instances.
This will be fixed in 2.1.5 (not out yet).

--

From: envbvs@epb9.lbl.gov (Brian V. Smith)
Subject: Re: Need help with xfig
Date: Sun, 6 Sep 92 19:49:49 EDT

In article <26141@dog.ee.lbl.gov> I wrote:
        [...]
        >...  Just change the code in the file u_font.c that adds
        >iso-8859 to the font name from this:

I meant the file "w_drawprim.c", not u_font.c

--

From: als@bohra.cpg.oz.au (Anthony Shipman)
Subject: Re: Another bug in xfig 2.1.4
Date: Tue, 15 Sep 92 09:16:23 EDT

alfred@arthur.et.tudelft.nl (Alfred van der Hoeven) writes:

>I found another problem with xfig, when running the program on
>an HP9000/720, for which I have a fix but no solution.
>When I want to change a previously entered text, using the 'Edit' menu option,
>it tends to exchange lowercase characters for uppercase characters.

>For instance, if I enter the string 'abcdefghij' in the
>text modification window, I instead see (and get) the string 'AbcDEfghIj'.

>Apparently, it has something to do with the file 'CompKeyDB', because
>if I invoke the program with 'xfig -k ""', the text modification window
>works OK.

>The problem does not appear when I run xfig on a SUN sparcstation,
>so it may be an HP problem instead of an xfig problem.

>In both cases, I use a SUN 3/60 running X11R4 for the display.

I had the same problem with a HP9000/800 and an NCD terminal.  I though it
was a bug in Xt.  Rearranging the order of the entries in the
CompKeyDB got around the problem.  Here is the relevant top part of my
CompKeyDB file.

#
#       For some mysterious reason each upper case override key must be
#       preceded by the lower case version.  If the lower case one comes second
#       then only the first is ever performed.
#
:~Ctrl<Key>1: insert-string(1)
:~Ctrl<Key>2: insert-string(2)
:~Ctrl<Key>3: insert-string(3)
:~Ctrl<Key>4: insert-string(4)
:~Ctrl<Key>a: insert-string(a)
:~Ctrl<Key>c: insert-string(c)
:~Ctrl<Key>e: insert-string(e)
:~Ctrl<Key>d: insert-string(d)
:~Ctrl<Key>i: insert-string(i)
:~Ctrl<Key>l: insert-string(l)
:~Ctrl<Key>n: insert-string(n)
:~Ctrl<Key>o: insert-string(o)
:~Ctrl<Key>p: insert-string(p)
:~Ctrl<Key>r: insert-string(r)
:~Ctrl<Key>s: insert-string(s)
:~Ctrl<Key>u: insert-string(u)
:~Ctrl<Key>x: insert-string(x)
:~Ctrl~Meta<Key>y: insert-string(y)
:~Ctrl<Key>A: insert-string(A)
:~Ctrl<Key>C: insert-string(C)
:~Ctrl<Key>E: insert-string(E)
:~Ctrl<Key>D: insert-string(D)
:~Ctrl<Key>I: insert-string(I)
:~Ctrl<Key>L: insert-string(L)
:~Ctrl<Key>N: insert-string(N)
:~Ctrl<Key>O: insert-string(O)
:~Ctrl<Key>P: insert-string(P)
:~Ctrl<Key>R: insert-string(R)
:~Ctrl<Key>S: insert-string(S)
:~Ctrl<Key>U: insert-string(U)
:~Ctrl<Key>X: insert-string(X)
:~Ctrl<Key>Y: insert-string(Y)
--

--

From: rkl@csc.liv.ac.uk (Richard Lloyd)
Subject: Re: Another bug in xfig 2.1.4
Date: Wed, 16 Sep 92 06:38:23 EDT

In article <1992Sep13.113709.11068@donau.et.tudelft.nl>, alfred@arthur.et.tudelft.nl (Alfred van der Hoeven) writes:
> I found another problem with xfig, when running the program on
> an HP9000/720, for which I have a fix but no solution.

When I got xfig 2.1.4 across recently, it behaved VERY BADLY with HP's X11R4
libraries (easy to core dump, the strange mixed case input etc. etc.). I solved
it by linking with MIT's X11R4 libraries and everything is OK now (except the font menu, which doesn't seem to highlight the font name properly when you move
the mouse pointer over the font names).

For those who want to do the same with HP machines, get the following from
our anonymous FTP site ftp.csc.liv.ac.uk (138.253.42.172):

/hpux/X11/imake-4.00.tar.Z         (Imake for X11R4, if you don't have it)
/hpux/X11/Xaw-4.00.tar.Z           (Xaw/Xmu X11R4 include files)
/hpux/X11/MITlib-4.00.tar.Z        (Pre-compiled MIT X11R4 libraries)
/hpux/X11/xfig-2.14.tar.Z          (xfig 2.14 set up to link with the MIT                                            libraries)

--

From: envbvs@epb9.lbl.gov (Brian V. Smith)
Subject: Re: Another bug in xfig 2.1.4
Date: Wed, 16 Sep 92 20:55:00 EDT

In article <Buo2w1.4K3@csc.liv.ac.uk>, rkl@csc.liv.ac.uk (Richard Lloyd) writes:
|> In article <1992Sep13.113709.11068@donau.et.tudelft.nl>, alfred@arthur.et.tudelft.nl (Alfred van der Hoeven) writes:
|> > I found another problem with xfig, when running the program on
|> > an HP9000/720, for which I have a fix but no solution.
|>
|> When I got xfig 2.1.4 across recently, it behaved VERY BADLY with HP's X11R4
|> libraries (easy to core dump, the strange mixed case input etc. etc.). I solved
|> it by linking with MIT's X11R4 libraries and everything is OK now (except the font menu, which doesn't seem to highlight the font name properly when you move
|> the mouse pointer over the font names).

The "pointer over the font names" bug occurs on any color (multi-plane) display
because of the way I used pixmaps in the labels for the menu items.  Once you
use a pixmap, there is no "foreground" and "background" to invert (since the
pixmap is be multi-plane) so you only (sometimes) see a slight "flash" as you
move the pointer over the entries.

It should work find on monochrome machines (I haven't looked lately).
I hope to fix the problem someday.

--

From: kaiser@mammal.vbo.dec.com (Peter Kaiser)
Subject: Re: Xfig and squares
Date: Thu, 17 Sep 92 02:58:47 EDT


--
In article <26313@dog.ee.lbl.gov>, envbvs@epb9.lbl.gov (Brian V. Smith) writes:

>You don't say which version of xfig you are using, but since version 2.1,
>you can draw 'regular polygons' of any number of sides.  These may be rotated
>by any angle.

Right, and thereafter the quadrilateral is just a figure defined by four
points which you can edit with the edit function.  Alternatively you can
draw your diamonds directly and accurately in the latest version of xfig
by using snap-to-grid-point drawing of an arbitrary polygon.  Which is
what I've just done in a drawing.

___Pete

--

From: envbvs@epb9.lbl.gov (Brian V. Smith)
Subject: Re: Xfig and squares
Date: Thu, 17 Sep 92 12:27:09 EDT

In article <1992Sep17.065847.9625@vbohub.vbo.dec.com>,
     kaiser@mammal.vbo.dec.com (Peter Kaiser) writes:
|>
|> --
|> In article <26313@dog.ee.lbl.gov>, envbvs@epb9.lbl.gov (Brian V. Smith) writes:
|>
|> >You don't say which version of xfig you are using, but since version 2.1,
|> >you can draw 'regular polygons' of any number of sides.  These may be rotated
|> >by any angle.
|>
|> Right, and thereafter the quadrilateral is just a figure defined by four
|> points which you can edit with the edit function.  Alternatively you can
|> draw your diamonds directly and accurately in the latest version of xfig
|> by using snap-to-grid-point drawing of an arbitrary polygon.  Which is
|> what I've just done in a drawing.

The snap-to-grid-point mode has been in every version of xfig.  Since version
2.1, there have been multiple sizes of this 'alignment' grid (which is different
from the grid which may be drawn on the canvas).

However, it is easier to draw a regular (equal sides) polygon by using the button
by that name, rather than eyeballing the n-sides using the arbitrary polygon
mode.

Then, as Peter says, xfig just creates an arbitrary polygon from your regular
polygon so you are free to move the indices in any way you wish.  Xfig just
takes care of the initial regularity of drawing the sides for you.

--

From: fsfrick@lerc.nasa.gov (David Fricker)
Subject: Re: EPS object in xfig?
Date: Thu, 17 Sep 92 15:36:40 EDT

In article <1992Sep16.040424.22977@raven.alaska.edu>, musgrave@denali.ims.alaska.edu (Dave Musgrave) writes:
> Does anyone know how to import an encapsulated postscript file into
> xfig using the EPS object mode?  I have ans EPS file generated by
> PV-wave but when trying to read it into xfig, xfig complains that
> there is no bitmap file.  How does the bitmap fiel relate to the EPS
> file?

The bitmap file lets xfig display a crude representation of the EPS
object.  This shows you roughly where everything is on the screen.

Please note that the bitmap is just the preview section of the EPS file
and is not necessary for importing EPS files into xfig.  If the EPS
file does not have a preview, all you get on the screen is a box
outlining the EPS object.  When you print the drawing, however, the
EPS object is included without trouble.

--