Back in 2001 I wrote a patch for xfig 3.2.3d to give Xfig the capability to draw elliptical arcs. I emailed it to Brian V. Smith and I think we might have exchanged a couple of emails. I've used my patched version since then but the elliptical arcs didn't appear in the release version.
Recently I was looking at the Xfig sources and realised there's elements of my patch in there, and in docs/TODO elliptical arcs are listed as a future item for version 4. Elliptical arcs need a file format change to store the extra info needed to define them relative to standard arcs. It looks like Brian integrated that aspect (a single additional number on the line defining an arc is all that's needed). Since version 3.2.5 in object.h there's a line:
float angle; / for elliptical arcs, new for V4.0 /
It's a fairly simple file format change since it's just one additional number on the end of the line - conventional circular arc definitions are completely unaffected.
I've been working to update the patch against release 3.2.9. There's some things that didn't exist in 3.2.3d such as the axe/log division of objects that need a little more work, also the measurements of area and length were not in the old version. I notice that trying to chop an ellipse already has a message that you can't do that since the outcome would require an elliptical arc.
I'm resolving a few remaining issues - I might just add messages to say that elliptical arcs are not handled by measure/area/chop if it looks like extensive work to address those areas which were outside my original patch.
Is the updated version of this patch of interest once I've finished and tested it with 3.2.9? I had a patch for fig2dev too and will look at updating that as well - probably the svg output device is the big new one, previously I'd focused just on postscript and pdf.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi David,
back in 2001! Yes, a patch to draw and output elliptical arcs would be welcome. However, I would be very reluctant to change anything in the output format. Recently, a line was added to indicate utf-8 encoding. That line was sneaked into the format definition as a comment line, hence it would not invalidate older fig-file readers.
Arcs are defined in the 3.2 format by the center point, a direction, and three points (!) on the arc. Hence, the arc is over-defined. It would be advantageous if the additional information contained in these three points could be used to convey the necessary definition for an elliptical arc.
Apart from postscript output (which is translated to pdf), I would consider as important output drivers tikz, pict2e, and svg. (The code in fig2dev is horrible, sorry.) For svg I have the plan to use a valid svg as a future fig-file format, hence xml, extensible and displayable by usual file browsers. I would not promise whether that plan can be realised within the next ten or so years.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the file format change could be why this stalled previously. I'll take a look and see if the information can be squeezed in without adding the additional digit to the line.
Currently the elliptic arc 'falls back' to being plotted as a circular arc if the file is read by software that doesn't understand elliptic arcs in the FIG format. That depends on the software reading the file without worrying about the extra digit stored.
I guess by squeezing in the data to the same string format as a circular arc and changing the meaning of some of the points the elliptic arc will not fall back gracefully to a circular arc. It will load as some strange/random geometry.
But probably in most cases people can use SVG or another interchange format if they use elliptic arcs and want to transfer the geometry to another package. I'll explore a little more what's possible and then post back with the patches once I'm happy with them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The file format provides the center point (as float), three points on the arc and a direction. For a circle, the center point and one point on the circumference is sufficient. The general equation of a rotated ellipse involves the lengths of the semi-axes and the angle, apart from the center coordinates. Hence, three points (giving three equations) should be sufficient to calculate the three unknowns. See a specific solution at math.stackexchange. A nice discussion on different representations is given also at math.stackexchange.
The current rendering of circular arcs in fig2dev uses the first point to determine the radius and the angle to the last point to find the end of the arc. In fact, two drivers take the mean of the distances to the first and last point to determine the radius. That would have to be changed. Nevertheless, it depends on the parser whether it enforces the validity of the three points or happily proceeds with the information it has.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Things are going well with getting the elliptical arcs integrated. Several fig2dev conversions for export are now working (ps/eps/pdf, svg, Latex pict2e format). Tikz format is not viable as it does not have its own elliptic arc representation so without converting to some type of spline or using additional external packages it won't work.
The main sticking point is the file format and making sure that this doesn't break anything. Here are some notes on things that don't work, followed lower down by some more positive ideas. I've been aiming that elliptic arcs should 'fall back' gracefully if opened in a version of XFig without elliptic arcs (or imported into other software). E.g. it should open as circular arcs instead of elliptical, and at about the right place on the canvas.
You are right that there is more than the minimum information stored, giving the idea that extra information can be included within the existing arc format. Then additional factors can be derived when the files is opened. However, it's not as simple as it seems!
I think it's five unknowns rather than three - angle, semi-axis lengths a & b, start and end angle. Also, as noted in the page you link, solving to find these things from a minimum set of information breaks down if any two of three points defining the arc are symmetric about the centreline.
The SVG arc specification includes two parameters: large-arc-flag and sweep-flag. These cover working out the 'edge cases' in which it's impossible to derive which quadrant the arc should lie in or whether it represents the long or short distance between the end points. But including these would just be more additional factors not in the existing file format.
Many ways it appears additional information could be stored get picked up as errors. E.g. defining new arc styles 'elliptic pie' and 'open elliptic' fails as they are picked up as out of range.
The canvas extents can be huge since object sizes can take any 32 bit integer. I'm assuming that elliptic arcs should work at anywhere on the canvas and have any size (i.e. no storing two 16 bit integers within a single 32 bit integer within the file format). Doing any thing like this breaks the graceful fall back anyway since the 32 bit representation would be at a location in a very different part of the canvas.
More positively, things that work:
Adding an additional term 'angle' at the end of the current arc definition line seems to work fine. Existing versions of xfig don't notice it is there. Elliptic arcs decay back to circular ones in similar places. But whether there's other software that would see this as invalid I don't know.
The centre point of arcs is currently stored with unnecessary precision. There are 1200 fig units per inch, yet the centre point of arcs is stored with three decimal places. This provides an opportunity: (1) Use the integer part to hold the arc centre point. (2) Use the decimal places to store the elliptic arc rotation (or a token that effectively tells us this is a circular arc).
This use of the decimal places to store the angle seems quite positive. Using the integer component only makes almost no difference to the arc (maximum shift by 1/1200"). Graceful fall-back is successful as the 'angle' stored with the decimal places has virtually no effect in a version of XFig unaware of elliptical arcs.
What would be preferable? The more straightforward addition of the angle to the end of the arc definition line? Or 'hiding' the information with the arc centre point location decimal places? Deriving the info from a sub-set of stored information seems too prone to errors in cases such as symmetric arc definition points.
Is there a case the centre point really does need the high precision decimal place information? Would using the options -userscale or -zoom make any difference to this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Never mind tikz format. I will gladly care for that. In fact, the whole tikz driver should be re-written.
I think it's five unknowns rather than three - angle, semi-axis lengths a & b, start and end angle.
Yes, there was unclear nomenclature. From the three given points, the start and end points not only lie on the ellipsis, they also define the start and end angle. Therefore, they convey additional information, the start and the end angle, which can be immediately calculated.
The method referred to in the first link indeed will fail if two points are co-linear with the centre point. (I believe, I checked with the trivial (-2,0), (0,1), (2,0).) Nevertheless, for two points being co-linear with the centre, one has immediately one of the axes, and comparing the half-length of this axis to the distance from the centre to the third point, whether this is the major or minor axis. From that follows the angle, and the spontaneous, naive math would be to transfer and rotate the ellipsis into the origin and solve the (x/a)^2 + (y/b)^2 = 1 for either a or b. In fact, the cases where the lines connecting the start and end points with the centre are either co-linear or contain an angle of 90° are probably very common. My math is not strong enough, butI would suspect that these special cases render the deteminant mentioned in the link above to zero.
The svg-specification unambigously defines an elliptical arc, as (I still believe) is possible within the the xfig file format . Start and end point can be immediatley taken from the xfig format, the ellipsis angle and axis lengths and the definition of the quadrant (by setting the two svg flags) would have to be calculated. I think, one can assume that the function
does exist. I think, such function should only fail if center, start, mid and end are on one line, or all four points not distinct.
Many ways it appears additional information could be stored get picked up as errors. E.g. defining new arc styles 'elliptic pie' and 'open elliptic' fails as they are picked up as out of range.
Such errors are a property of the parser and on purpose programmed in. Thanks to a lot of input-fuzzers who stress-tested fig2dev with invalid input. The input-parser in fig2dev could be mended.
The canvas extents can be huge since object sizes can take any 32 bit integer.
I am not sure about that. Thankfully, the format only says int, it does not promise 32 bits, does it? I would not have any problem to restrict the format in areas where it is ambiguous.
Is there a case the centre point really does need the high precision decimal place information?
The centre point is defined as float, not integer. It makes little difference, and rounding, or shifting to the next integer location would most probably be ok.
If the function define_ellipsis() mentioned above would exist, how would you continue? For the next months I am unfortunately of not much help here, since my paid occupation keeps me from spending much time here. Therefore, even more thanks for your efforts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have resolved the storage format now - we can have everything stored within the original file format and good fall-back to reasonable behaviour if opening the files on a version of XFig without the elliptic arc capability.
point[1] of a circular arc isn't actually used for much so we can repurpose it. There's two pieces of information that need to be stored: (i) the ratio of semi-axis lengths, and (ii) the angle of rotation of the ellipse. These can be stored in point[1].x and point[1].y.
Using point[0] or [2] together with the ratio of semi-axis lengths the actual semi-axis sizes can be found (so we only need to store the ratio, not both numbers). Both the ratio of axes and the angle are quite small numbers. So multiplying them up by 100000 gives an integer that holds sufficient accuracy of information for any realistic case.
The fact that point[1] no longer defines a radius matching point[0] or point[2] shows this as an elliptic arc not a circular one. If by chance point[1] of the elliptic arc did happen to match the radius defined by point[0] or [2] we can add 2 * Pi to the angle stored within point[1]. That changes the 'radius' defined by point[1] but has no effect on the rotation of the ellipse by the angle. So we can be certain which type of arc is defined, and store all the required information.
I will tidy up the patch for xfig and fig2dev over the next few days and post it here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've attached the patches which add elliptic arcs to Xfig and Fig2dev. These are against the current git versions.
Also attached is a figure drawn to explain how I've implemented the elliptic arcs within the existing tools such as rotation, mirroring and flipping items of the drawing. Only one attachment was allowed so the patches and figure are tar.gz combined.
As shown in the figure, the elliptic arc (blue) is defined by a centre and three points (0, 1, 2). These points lie on a circle surrounding the ellipse - this circle is never drawn, but enables the existing Xfig code for rotation and flipping etc. to work on an elliptic arc with very minimal change from acting on a circular arc. The full ellipse (chain line) is there just for illustration of the overall elliptic shape and is not drawn.
Points 0 and 2 of the ellipse store radius and start/finish angles. Point 1 defines the semi-axis sizes. The angle (t) is defined by point 1 when the arc is drawn. Later, the arc may be rotated by an angle (p). This rotation angle is not stored directly but can be calculated from the new (rotated) position of point 1 together with the stored angle t. This means that the angle t stored for an ellipse never changes unless the arc is scaled, while any rotation is captured through the movement of point 1.
The file format needed to store this entity is the same as for circular arcs. But point 1 is replaced by the ellipse semi-axis ratio, and the angle (t). I posted previously about how this works and how it can be used to always distinguish elliptic from circular arcs.
In several areas of the patches there's quite a few whitespace changes where existing circular arc code becomes part of a conditional statement in the format "if (circular) else (elliptic)", which causes existing code to be indented and show as a change in the patch file.
It will be great to get some feedback on how the elliptic arc works for you and whether these patches apply cleanly (they should do!). I've not done anything with copyright notices at the top of files, just focused on the main code needed.
Great! I applied the xfig and the fig2dev patch, both apply cleanly (with some warnings regarding whitespace, since I used git apply ../xfig-0001-Patched...patch) and fig2dev and xfig build. The interface is intuitive, I created some elliptic arcs, rotated, scaled and edited them, filled them as open and pie-wedge arcs, all smoothly. Xfig and fig2dev without patches accept the files, albeit fig2dev creates large bounding boxes. For the patched fig2dev, I only tried the export to eps: Works well, although one misunderstanding with y coordinate pointing downwards in eps seemed to have happened, see the attached screenshot.
I will soon apply these commit on a new git branch.
Regarding the copyright lines: From the patch files, the author will be taken from the From: line, the commiter probably from the commiter line (e-mails differ a bit). Your authorship anyhow will appear in the git commit logs. In addition, I propose to add lines attributing elliptic arc code to you (but David I. Fletcher, or David Fletcher? Your commiter e-mail, or From: e.mail?) to the d_arc.c, u_bound.c, u_draw.c and u_geom.c and u_search.c files. I would add that authorship information below the top 20 copyright lines, not in the "Parts Copyright .." lines but below, with lines similarly to your text in u_geom.c . In fig2dev, the same would be done in the files bound.c, genps.c, gensvg.c and gentikz.c. These lines will appear in the the git tree and could be changed before a release.
This upside down arc eps is strange. I created a similar looking fig file here (see in the attached tar.gz file) and exported to eps - it is working ok. Please can you attach the fig file and eps file this fault happens with and I'll try to understand what is causing this.
I forgot to mention that there is a bug in the unpatched Xfig which is fixed in the elliptic arc patch. It occurs if a circular arc is chopped by a line. It should form two new arcs, but the same pointer is used to form both arcs (e_chop.c line 565 in the patched file), causing a crash. Moving the code "F_arc * this_arc = copy_arc(a);" down to line 672 means a new pointer is created for each new arc, removing the problem. A file crash.fig is included in the attached tar.gz which can be used to demonstrate the crash in the unpatched Xfig. I found this while making sure the chop command didn't do anything crazy for an elliptic arc.
A couple of different computers with unpatched Xfig do the same thing using this sequence: (1) Open crash.fig, (2) select chop object, (3) click the line as the axe, (4) click the circular arc as the log object. Xfig locks up and becomes impossible to interact with.
For the copyright and logs it should be David Fletcher, my middle initial can be removed. The correct email is david@megapico.co.uk, the other email is something git created based on the hostname, it doesn't really exist. Many thanks for your help with this.
Sorry, the screenshots did not show all. There is a third arc, which is empty and not drawn upside-down. Attached a tar-file with the .fig and .eps files.
Thanks for the files. I can reproduce it, and after trying lots of drawings I've found it is caused by using the vertical flip function. After using this the arc you use it on comes out the wrong way up in the export (it affects SVG as well as EPS). If you use the vertical flip twice the arcs work properly again.
My code in the vertical flip has an error! I suspect that the direction flag is being changed when it should not be, or fig2dev is using the direction flag wrongly for the elliptic arc. I will look at this and find out how to fix it with a patch to the code - probably into next week.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've now found the cause of the export problem and fixed it. There was an angle being handled incorrectly in the patched part of fig2dev. It was affecting arcs which have been both rotated and flipped vertically. A patch is included in the attached tar.gz
This is a patch for xfig. It clears up a drawing glitch I found during testing which affected pie format elliptic arcs if they are the first item drawn after program start. A poorly initialised data point is now corrected.
Nice, I tried the patched xfig on the ell_arcs.fig attached above, added one more filled, flipped and rotated elliptic pie-arc and converted it with the patched fig2dev. Commits [0b40f0] and [0e6461] report the new state.
Back in 2001 I wrote a patch for xfig 3.2.3d to give Xfig the capability to draw elliptical arcs. I emailed it to Brian V. Smith and I think we might have exchanged a couple of emails. I've used my patched version since then but the elliptical arcs didn't appear in the release version.
Recently I was looking at the Xfig sources and realised there's elements of my patch in there, and in docs/TODO elliptical arcs are listed as a future item for version 4. Elliptical arcs need a file format change to store the extra info needed to define them relative to standard arcs. It looks like Brian integrated that aspect (a single additional number on the line defining an arc is all that's needed). Since version 3.2.5 in object.h there's a line:
float angle; / for elliptical arcs, new for V4.0 /
It's a fairly simple file format change since it's just one additional number on the end of the line - conventional circular arc definitions are completely unaffected.
I've been working to update the patch against release 3.2.9. There's some things that didn't exist in 3.2.3d such as the axe/log division of objects that need a little more work, also the measurements of area and length were not in the old version. I notice that trying to chop an ellipse already has a message that you can't do that since the outcome would require an elliptical arc.
I'm resolving a few remaining issues - I might just add messages to say that elliptical arcs are not handled by measure/area/chop if it looks like extensive work to address those areas which were outside my original patch.
Is the updated version of this patch of interest once I've finished and tested it with 3.2.9? I had a patch for fig2dev too and will look at updating that as well - probably the svg output device is the big new one, previously I'd focused just on postscript and pdf.
Hi David,
back in 2001! Yes, a patch to draw and output elliptical arcs would be welcome. However, I would be very reluctant to change anything in the output format. Recently, a line was added to indicate utf-8 encoding. That line was sneaked into the format definition as a comment line, hence it would not invalidate older fig-file readers.
Arcs are defined in the 3.2 format by the center point, a direction, and three points (!) on the arc. Hence, the arc is over-defined. It would be advantageous if the additional information contained in these three points could be used to convey the necessary definition for an elliptical arc.
Apart from postscript output (which is translated to pdf), I would consider as important output drivers tikz, pict2e, and svg. (The code in fig2dev is horrible, sorry.) For svg I have the plan to use a valid svg as a future fig-file format, hence xml, extensible and displayable by usual file browsers. I would not promise whether that plan can be realised within the next ten or so years.
I think the file format change could be why this stalled previously. I'll take a look and see if the information can be squeezed in without adding the additional digit to the line.
Currently the elliptic arc 'falls back' to being plotted as a circular arc if the file is read by software that doesn't understand elliptic arcs in the FIG format. That depends on the software reading the file without worrying about the extra digit stored.
I guess by squeezing in the data to the same string format as a circular arc and changing the meaning of some of the points the elliptic arc will not fall back gracefully to a circular arc. It will load as some strange/random geometry.
But probably in most cases people can use SVG or another interchange format if they use elliptic arcs and want to transfer the geometry to another package. I'll explore a little more what's possible and then post back with the patches once I'm happy with them.
The file format provides the center point (as float), three points on the arc and a direction. For a circle, the center point and one point on the circumference is sufficient. The general equation of a rotated ellipse involves the lengths of the semi-axes and the angle, apart from the center coordinates. Hence, three points (giving three equations) should be sufficient to calculate the three unknowns. See a specific solution at math.stackexchange. A nice discussion on different representations is given also at math.stackexchange.
The current rendering of circular arcs in fig2dev uses the first point to determine the radius and the angle to the last point to find the end of the arc. In fact, two drivers take the mean of the distances to the first and last point to determine the radius. That would have to be changed. Nevertheless, it depends on the parser whether it enforces the validity of the three points or happily proceeds with the information it has.
Screenshot attached illustrating the current status.
Things are going well with getting the elliptical arcs integrated. Several fig2dev conversions for export are now working (ps/eps/pdf, svg, Latex pict2e format). Tikz format is not viable as it does not have its own elliptic arc representation so without converting to some type of spline or using additional external packages it won't work.
The main sticking point is the file format and making sure that this doesn't break anything. Here are some notes on things that don't work, followed lower down by some more positive ideas. I've been aiming that elliptic arcs should 'fall back' gracefully if opened in a version of XFig without elliptic arcs (or imported into other software). E.g. it should open as circular arcs instead of elliptical, and at about the right place on the canvas.
You are right that there is more than the minimum information stored, giving the idea that extra information can be included within the existing arc format. Then additional factors can be derived when the files is opened. However, it's not as simple as it seems!
I think it's five unknowns rather than three - angle, semi-axis lengths a & b, start and end angle. Also, as noted in the page you link, solving to find these things from a minimum set of information breaks down if any two of three points defining the arc are symmetric about the centreline.
The SVG arc specification includes two parameters: large-arc-flag and sweep-flag. These cover working out the 'edge cases' in which it's impossible to derive which quadrant the arc should lie in or whether it represents the long or short distance between the end points. But including these would just be more additional factors not in the existing file format.
Many ways it appears additional information could be stored get picked up as errors. E.g. defining new arc styles 'elliptic pie' and 'open elliptic' fails as they are picked up as out of range.
The canvas extents can be huge since object sizes can take any 32 bit integer. I'm assuming that elliptic arcs should work at anywhere on the canvas and have any size (i.e. no storing two 16 bit integers within a single 32 bit integer within the file format). Doing any thing like this breaks the graceful fall back anyway since the 32 bit representation would be at a location in a very different part of the canvas.
More positively, things that work:
Adding an additional term 'angle' at the end of the current arc definition line seems to work fine. Existing versions of xfig don't notice it is there. Elliptic arcs decay back to circular ones in similar places. But whether there's other software that would see this as invalid I don't know.
The centre point of arcs is currently stored with unnecessary precision. There are 1200 fig units per inch, yet the centre point of arcs is stored with three decimal places. This provides an opportunity: (1) Use the integer part to hold the arc centre point. (2) Use the decimal places to store the elliptic arc rotation (or a token that effectively tells us this is a circular arc).
This use of the decimal places to store the angle seems quite positive. Using the integer component only makes almost no difference to the arc (maximum shift by 1/1200"). Graceful fall-back is successful as the 'angle' stored with the decimal places has virtually no effect in a version of XFig unaware of elliptical arcs.
What would be preferable? The more straightforward addition of the angle to the end of the arc definition line? Or 'hiding' the information with the arc centre point location decimal places? Deriving the info from a sub-set of stored information seems too prone to errors in cases such as symmetric arc definition points.
Is there a case the centre point really does need the high precision decimal place information? Would using the options -userscale or -zoom make any difference to this?
Never mind tikz format. I will gladly care for that. In fact, the whole tikz driver should be re-written.
Yes, there was unclear nomenclature. From the three given points, the start and end points not only lie on the ellipsis, they also define the start and end angle. Therefore, they convey additional information, the start and the end angle, which can be immediately calculated.
The method referred to in the first link indeed will fail if two points are co-linear with the centre point. (I believe, I checked with the trivial (-2,0), (0,1), (2,0).) Nevertheless, for two points being co-linear with the centre, one has immediately one of the axes, and comparing the half-length of this axis to the distance from the centre to the third point, whether this is the major or minor axis. From that follows the angle, and the spontaneous, naive math would be to transfer and rotate the ellipsis into the origin and solve the (x/a)^2 + (y/b)^2 = 1 for either a or b. In fact, the cases where the lines connecting the start and end points with the centre are either co-linear or contain an angle of 90° are probably very common. My math is not strong enough, butI would suspect that these special cases render the deteminant mentioned in the link above to zero.
The svg-specification unambigously defines an elliptical arc, as (I still believe) is possible within the the xfig file format . Start and end point can be immediatley taken from the xfig format, the ellipsis angle and axis lengths and the definition of the quadrant (by setting the two svg flags) would have to be calculated. I think, one can assume that the function
does exist. I think, such function should only fail if center, start, mid and end are on one line, or all four points not distinct.
Such errors are a property of the parser and on purpose programmed in. Thanks to a lot of input-fuzzers who stress-tested fig2dev with invalid input. The input-parser in fig2dev could be mended.
I am not sure about that. Thankfully, the format only says int, it does not promise 32 bits, does it? I would not have any problem to restrict the format in areas where it is ambiguous.
The centre point is defined as float, not integer. It makes little difference, and rounding, or shifting to the next integer location would most probably be ok.
If the function
define_ellipsis()mentioned above would exist, how would you continue? For the next months I am unfortunately of not much help here, since my paid occupation keeps me from spending much time here. Therefore, even more thanks for your efforts.I have resolved the storage format now - we can have everything stored within the original file format and good fall-back to reasonable behaviour if opening the files on a version of XFig without the elliptic arc capability.
point[1] of a circular arc isn't actually used for much so we can repurpose it. There's two pieces of information that need to be stored: (i) the ratio of semi-axis lengths, and (ii) the angle of rotation of the ellipse. These can be stored in point[1].x and point[1].y.
Using point[0] or [2] together with the ratio of semi-axis lengths the actual semi-axis sizes can be found (so we only need to store the ratio, not both numbers). Both the ratio of axes and the angle are quite small numbers. So multiplying them up by 100000 gives an integer that holds sufficient accuracy of information for any realistic case.
The fact that point[1] no longer defines a radius matching point[0] or point[2] shows this as an elliptic arc not a circular one. If by chance point[1] of the elliptic arc did happen to match the radius defined by point[0] or [2] we can add 2 * Pi to the angle stored within point[1]. That changes the 'radius' defined by point[1] but has no effect on the rotation of the ellipse by the angle. So we can be certain which type of arc is defined, and store all the required information.
I will tidy up the patch for xfig and fig2dev over the next few days and post it here.
I've attached the patches which add elliptic arcs to Xfig and Fig2dev. These are against the current git versions.
Also attached is a figure drawn to explain how I've implemented the elliptic arcs within the existing tools such as rotation, mirroring and flipping items of the drawing. Only one attachment was allowed so the patches and figure are tar.gz combined.
As shown in the figure, the elliptic arc (blue) is defined by a centre and three points (0, 1, 2). These points lie on a circle surrounding the ellipse - this circle is never drawn, but enables the existing Xfig code for rotation and flipping etc. to work on an elliptic arc with very minimal change from acting on a circular arc. The full ellipse (chain line) is there just for illustration of the overall elliptic shape and is not drawn.
Points 0 and 2 of the ellipse store radius and start/finish angles. Point 1 defines the semi-axis sizes. The angle (t) is defined by point 1 when the arc is drawn. Later, the arc may be rotated by an angle (p). This rotation angle is not stored directly but can be calculated from the new (rotated) position of point 1 together with the stored angle t. This means that the angle t stored for an ellipse never changes unless the arc is scaled, while any rotation is captured through the movement of point 1.
The file format needed to store this entity is the same as for circular arcs. But point 1 is replaced by the ellipse semi-axis ratio, and the angle (t). I posted previously about how this works and how it can be used to always distinguish elliptic from circular arcs.
In several areas of the patches there's quite a few whitespace changes where existing circular arc code becomes part of a conditional statement in the format "if (circular) else (elliptic)", which causes existing code to be indented and show as a change in the patch file.
It will be great to get some feedback on how the elliptic arc works for you and whether these patches apply cleanly (they should do!). I've not done anything with copyright notices at the top of files, just focused on the main code needed.
Best regards, David.
Great! I applied the xfig and the fig2dev patch, both apply cleanly (with some warnings regarding whitespace, since I used git apply ../xfig-0001-Patched...patch) and fig2dev and xfig build. The interface is intuitive, I created some elliptic arcs, rotated, scaled and edited them, filled them as open and pie-wedge arcs, all smoothly. Xfig and fig2dev without patches accept the files, albeit fig2dev creates large bounding boxes. For the patched fig2dev, I only tried the export to eps: Works well, although one misunderstanding with y coordinate pointing downwards in eps seemed to have happened, see the attached screenshot.
I will soon apply these commit on a new git branch.
Regarding the copyright lines: From the patch files, the author will be taken from the From: line, the commiter probably from the commiter line (e-mails differ a bit). Your authorship anyhow will appear in the git commit logs. In addition, I propose to add lines attributing elliptic arc code to you (but David I. Fletcher, or David Fletcher? Your commiter e-mail, or From: e.mail?) to the d_arc.c, u_bound.c, u_draw.c and u_geom.c and u_search.c files. I would add that authorship information below the top 20 copyright lines, not in the "Parts Copyright .." lines but below, with lines similarly to your text in u_geom.c . In fig2dev, the same would be done in the files bound.c, genps.c, gensvg.c and gentikz.c. These lines will appear in the the git tree and could be changed before a release.
Great that the patches applied cleanly.
This upside down arc eps is strange. I created a similar looking fig file here (see in the attached tar.gz file) and exported to eps - it is working ok. Please can you attach the fig file and eps file this fault happens with and I'll try to understand what is causing this.
I forgot to mention that there is a bug in the unpatched Xfig which is fixed in the elliptic arc patch. It occurs if a circular arc is chopped by a line. It should form two new arcs, but the same pointer is used to form both arcs (e_chop.c line 565 in the patched file), causing a crash. Moving the code "F_arc * this_arc = copy_arc(a);" down to line 672 means a new pointer is created for each new arc, removing the problem. A file crash.fig is included in the attached tar.gz which can be used to demonstrate the crash in the unpatched Xfig. I found this while making sure the chop command didn't do anything crazy for an elliptic arc.
A couple of different computers with unpatched Xfig do the same thing using this sequence: (1) Open crash.fig, (2) select chop object, (3) click the line as the axe, (4) click the circular arc as the log object. Xfig locks up and becomes impossible to interact with.
For the copyright and logs it should be David Fletcher, my middle initial can be removed. The correct email is david@megapico.co.uk, the other email is something git created based on the hostname, it doesn't really exist. Many thanks for your help with this.
Sorry, the screenshots did not show all. There is a third arc, which is empty and not drawn upside-down. Attached a tar-file with the .fig and .eps files.
Thanks for the files. I can reproduce it, and after trying lots of drawings I've found it is caused by using the vertical flip function. After using this the arc you use it on comes out the wrong way up in the export (it affects SVG as well as EPS). If you use the vertical flip twice the arcs work properly again.
My code in the vertical flip has an error! I suspect that the direction flag is being changed when it should not be, or fig2dev is using the direction flag wrongly for the elliptic arc. I will look at this and find out how to fix it with a patch to the code - probably into next week.
I've now found the cause of the export problem and fixed it. There was an angle being handled incorrectly in the patched part of fig2dev. It was affecting arcs which have been both rotated and flipped vertically. A patch is included in the attached tar.gz
0001-Fix-for-ellitpic-arcs-that-have-been-flipped-and-rot.patch
This is a patch for fig2dev and clears up the export rotation problem.
0001-Fix-glitch-for-elliptic-pie-arcs.-Remove-debugging-p.patch
This is a patch for xfig. It clears up a drawing glitch I found during testing which affected pie format elliptic arcs if they are the first item drawn after program start. A poorly initialised data point is now corrected.
Best regards, David
Nice, I tried the patched xfig on the ell_arcs.fig attached above, added one more filled, flipped and rotated elliptic pie-arc and converted it with the patched fig2dev. Commits [0b40f0] and [0e6461] report the new state.
Related
Commit: [0e6461]
Commit: [0b40f0]