isaac@goanna.oz.au (Isaac Balbin) (02/09/90)
I am contemplating giving a programming project to a group
of 3rd year undergraduate students that would involve bringing
xfig to a better state. I mean, at least bringing it to a state where
it has all the features of fig-fs, and handles text (scaling, size etc)
better than fig-fs. Perhaps they might also bring some features from
idraw to this new version of xfig. My motivation is clearly selfish,
with an X-terminal to land on my desk in the nearish future (Visual
Technology, are you listening, how is production of your 19" Turbo
going). Is anyone undertaking such a project or is it in the pipeline?
I guess they might use the Athena widget set. I don't know. I haven't even
looked at the code ...
By the way, has anyone thought of an idraw to fig conversion program
or even idraw to eepic or something? How hard would this be?
Suggestions and comments welcome. isaac@goanna.cs.rmit.OZ.AU
PS. All this because I use transfig and eepic for my TeX diagrams and find it
most convenient since you can actually preview the diagrams as well with
say xdvi or xtex!beck@hermod.cs.cornell.edu (Micah Beck) (02/09/90)
In article <2846@goanna.oz.au> isaac@goanna.oz.au (Isaac Balbin) writes: > I am contemplating giving a programming project to a group > of 3rd year undergraduate students that would involve bringing > xfig to a better state. I mean, at least bringing it to a state where > it has all the features of fig-fs, and handles text (scaling, size etc) > better than fig-fs. Perhaps they might also bring some features from > idraw to this new version of xfig. Bravo! Fig-FS itself is no longer under development. I have not been able to contact the original author of Fig for some time. The only XFig development which I know of has been at Bellcore, and does not seem to be very active. > Is anyone undertaking such a project or is it in the pipeline? Not that I know of. A graduate student at Cornell has developed a small X graphics editor called XFlash which is Fig compatible, but it is still quite experimental. My heartiest encouragement to your project! /micah
envbvs@epb2.lbl.gov (Brian V. Smith) (02/16/90)
In article <2846@goanna.oz.au>, isaac@goanna.oz.au (Isaac Balbin) writes: > I am contemplating giving a programming project to a group > of 3rd year undergraduate students that would involve bringing > xfig to a better state. I mean, at least bringing it to a state where > it has all the features of fig-fs, and handles text (scaling, size etc) > better than fig-fs. Perhaps they might also bring some features from > idraw to this new version of xfig. My motivation is clearly selfish, > with an X-terminal to land on my desk in the nearish future (Visual > Technology, are you listening, how is production of your 19" Turbo > going). Is anyone undertaking such a project or is it in the pipeline? > I guess they might use the Athena widget set. I don't know. I haven't even > looked at the code ... > By the way, has anyone thought of an idraw to fig conversion program > or even idraw to eepic or something? How hard would this be? > Suggestions and comments welcome. isaac@goanna.cs.rmit.OZ.AU > > PS. All this because I use transfig and eepic for my TeX diagrams and find it > most convenient since you can actually preview the diagrams as well with > say xdvi or xtex! 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: o Area fill for circles, boxes, etc. with 20 different gray shades for Postscript output o 35 different fonts - the 35 fonts normally included with the Laserwriters can be used in figures at any point size. If there is a corresponding font in X, then the text is shown in that font on the screen. o text can be virtually any point size o left, center and right justification of text o rounded-corner boxes with any radius of the corners o different line thicknesses o lower button panel for quick access to "save", "chdir", etc. functions. o button to change the line thickness of an existing object o button to change the line type of an existing object o portrait or landscape print mode I have NOT supported the sunview code in xfig (for those who didn't know, xfig can be compiled for X11 or sunview) and have stripped that code out in some modules. If there is any interest in this hacked xfig, I can post it to comp.sources.x I would like to at least update the man entry, though, to show the new features. *** I will call it nxfig to distinguish it from the original xfig. _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory I don't speak for LBL, these non-opinions are all mine.
envbvs@epb2.lbl.gov (Brian V. Smith) (02/16/90)
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). _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory I don't speak for LBL, these non-opinions are all mine.
beck@hermod.cs.cornell.edu (Micah Beck) (02/16/90)
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.
envbvs@epb2.lbl.gov (Brian V. Smith) (02/17/90)
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.