🚀 go-pugleaf

In article <37373@cornell.UUCP>, beck@hermod.cs.cornell.edu (Micah Beck)
writes:
> In article <4867@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V.
Smith) writes:
> >In article <4866@helios.ee.lbl.gov>, envbvs@epb2.lbl.gov I wrote:
> >> 
> >> Wellll,  I didn't want to say anything until I brought the documentation
> >> up to date, but I have been hacking at xfig and have added the following 
> >> features:
> >> 
> >[ list of features deleted]
> >
> >I forgot to add that I have NOT supported the "pic" output with these new
> >features.  Postscript is the only form of output that will work (f2ps).
> 
> It goes without saying that you must have changed the "Fig code" intermediate
> form substantially to make all these improvements, and by the sound of it the
> changes are non-compatible.  Thus, the TransFig package of back end Fig
> code translators will not work with this hacked version of xfig (nxfig).
>
I admit that I know nothing about TransFig, but let me clarify my statement
about output support and file format.

I have changed nothing in the file format from the xfig 1.4 protocol EXCEPT
in one object (rounded-corner boxes), where I interpret the meaning of the
"pen" component to be the radius of the corners.

The pen component isn't used in xfig, and since there is a line thickness,
color and line-style component, I didn't see how a "pen" component would
be used.

The other components, i.e. area_fill, line_thickness, font and font_size
were already in the 1.4 definition. 
 
As for output support, the manual entry for xfig claimed that there were
two programs, f2tex and f2latex to support TeX and LaTeX respectively.
Those programs were never in the source distribution for xfig.

> This is sure to cause confusion, since TransFig advertises itself as the
> definitive back end for Fig.  So please, announce the non-compatibility
> of your XFig-derived editor clearly in the documentation, and consider naming
> your editor something which does not have "fig" as a substring.  Better yet,
> consider making your intermediate code compatible with TransFig.  Even if
> TransFig cannot support your extensions, it might support a subset.  I
am more
> than willing to make reasonable modifications to TransFig to allow such
> compatibility.
> 

Ken Yap, who did the port of xfig to X11 said that I should still call it xfig.
Again, as I didn't change very much of the protocol at all, if xfig 1.4.3
supported TransFig then this version will also.
I just don't know anything about TransFig to say.

> A common application graphics description like Fig code is a very valuable
> tool.  It's unfortunate to see the best implementations define their own
> (non-compatible) intermediate forms.  There is still a great need, especially
> in the LaTeX community, for an improved COMPATIBLE version of XFig.
> 

See above.  It is 99.9999% compatible with xfig 1.4 patchlevel 6.

> Micah Beck
> Cornell CS Dept.

_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.