tkl

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

Dear Jean Charles, amazing, you managed to solve the issue! Plus, you gave a valuable hint on a non-portability. This rewind_stream() business is a made-myself, convoluted and messy wrapper / interface to opening and reading possibly compressed files. I planned to replace this, for the next release, with a slightly less messy interface. Which, however, also employs similar combinations of rewind() and lseek(). Thank you for offering to perform further test. Really, the blame is on me to write suitable...

I tried your suggestion. I made a copy of "trial.fig" into "trial-modif.fig" and changed 0 weissmies-schema-cns.jpg to 0 weissmies-schema-cns.jpg with two spaces between 0 and the filename, in "trial-modif.fig". Unfortunately, Xfig 3.2.9_2 gives exactly the same error: File trial-modif.fig: Incomplete Picture Object object at line 11. Incorrect object code at line 13. So adding a blank does not seem to make any difference. As mentioned in my previous message, I have also already tested Xfig 3.2.9a_0...

For the time being, I do not have an easy fix. Another shot into the dark is to take the trial.fig file, open it with a text editor, and editing it a bit until xfig reads it (?! I wish, this were a joke.) For instance, adding at least one blank between "0" and "weissmies...". I will see this in a while. But now, I see that the lines reading the picture file name were changed after xfig 3.2.9 (due to a non-portability to OS X). I see, that you had installed xfig 3.2.9, not xfig 3.2.9a. Is it a possibility...

Dear Thomas, Thank you very much for your rapid answer. This is really a tough problem! Worse, I cannot reproduce the issue. This is very annoying. Does this indicate that the problem comes from the machine and its operating system (the problem appeared after upgrading to macOS Tahoe 26.5.2 and reinstalling Xfig). The error messages from xfig indicate that the parser is somehow misled. One possibility would be that on MacOS the line ending character is written as carriage return (\r, ascii 0xd),...

Xfig 3.2.9_2 on macOS Tahoe: Picture objects cannot be read back

For the time being, I do not have an easy fix. Another shot into the dark is to take the trial.fig file, open it with a text editor, and editing it a bit until xfig reads it (?! I wish, this were a joke.) For instance, adding at least one blank between "0" and "weissmies...". But now, I see that the lines reading the picture file name were changed after xfig 3.2.9 (due to a non-portability to OS X). I see, that you had installed xfig 3.2.9, not xfig 3.2.9a. Is it a possibility to install xfig 3.2.9a...

This is really a tough problem! Worse, I cannot reproduce the issue. The error messages from xfig indicate that the parser is somehow misled. One possibility would be that on MacOS the line ending character is written as carriage return (\r, ascii 0xd), not line feed (\n, ascii 0xa). As far as I know, only history Macs use carriage return. One could look at the octal dump to make sure, od -j 109 -t c written_by_xfig.fig. Are you able to build xfig from sources? This would entail installing the development...