🚀 go-pugleaf

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).

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.

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.

Micah Beck
Cornell CS Dept.