Hi Jean Charles, could you please try out a portable solution for the problem with reading picture objects: Replace the lines (approx.) 545 and 546 in f_picobj.c, rewind(xf_stream->fp); lseek(fileno(xf_stream->fp), 0, SEEK_SET); by fflush(xf_stream->fp); fseek(fileno(xf_stream->fp), 0, SEEK_SET); For macOS, you had deleted the lseek()-line. However, the second option with fflush() followed by fseek() might be portable between linux'es, macOS and BSDs. The man page of fseek(3p) says that if the most...
off-grid issue
Comprehensive analysis at codeborg.org. I am afraid, the current xfig sources are not yet patched.
Awesome! The proposed patch fixes the problem, and does not seem to create other bugs. I am still writing a test for the issue.
Under my rolling-release archlinux, there are a few files under .local/state. gnuplot gives a nice example. To recapitulate, the files written by xfig are (i) .xfigrc, which contains the recently opened files. In the freedesktop sepcification, this is given as an example for being stored under $XDG_STATE_HOME. (ii) .xfigrcstyle, which contains user settings, a good example for $XDG_CONFIG_HOME. (iii) .xfig, which is a cut buffer for copying and pasting figures between restarts or different instances...
In fact, .xfigrc only stores the last recent files, settings are retrieved from X resources or manually from loading a style family, stored in .xfigrcstyle. Presumably, few users know about setting and reloading styles. Nevertheless, I would put these files into ./config/xfig, not under the quite unused .local/state.
Yes, it is correct that xfig should adhere to more modern standards for persistent file storage. In my opinion, that would be $XDG_CONFIG_HOME, though, not $XDG_STATE_HOME. On my (stable) debian system, .local/state, the default if $XDG_STATE_HOME is not set or empty, does not even exist. $XDG_STATE_HOME was introduced between version 0.7 [1] and 0.8 [2] of the xdg base directory specification, hence between 2010 and 2021. Since xfig may save two configuration files, .xfigrc and .xfigrcstyle, but...
Dear Thomas, (Sorry for the delayed reply; I was on leave for the past few days.) Thank you for considering our previous message, as well as for your detailed response. I agree with you that it is amazing that ChatGPT managed to pinpoint the problem in the C code (I understand that you are confirming the diagnosis). Maybe we have been licky this time. May I report two issues (at least on my machine and system; this wasn't the case "before") that could be considered when the new release of Xfig is...