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

[Gilbert, Jean Charles]

(The text below was generated by ChatGPT after several hours of discussion aimed—unsuccessfully—at resolving the problem described further down. I am very keen to solve this issue, as I am preparing a book [draft available at https://inria.hal.science/hal-03347060v2] containing hundreds of illustrations generated with xfig, and it would be extremely inconvenient to have to switch to a different image generation tool. Thank you for your help.)

Hello,

I am experiencing a reproducible problem with Xfig 3.2.9_2 on macOS Tahoe 26.5.2 (Apple Silicon, arm64), running under XQuartz.

I installed Xfig through MacPorts. The currently active versions are:

xfig @3.2.9_2
fig2dev @3.2.9_0

The problem is with Picture objects. Xfig can insert a picture and save the .fig file, but after quitting and restarting Xfig, it cannot read back the same file that it has just created.

For example, I create a new figure, use the Picture button, and insert a PDF image. Xfig saves the following minimal file:

#FIG 3.2  Produced by xfig version 3.2.9
#encoding: UTF-8
Landscape
Center
Metric
A4
100.00
Single
-2
1200 2
2 5 0 1 0 -1 50 -1 -1 0.000 0 0 -1 0 0 5
    0 weissmies-schema-cns.pdf
     450 450 13817 450 13817 19357 450 19357 450 450

When I subsequently run:

xfig trial-pdf.fig &

Xfig reports:

File trial-pdf.fig:
Incomplete Picture Object object at line 11.
Incorrect object code at line 13.

The same problem occurs with JPEG pictures.

For example, the Picture object is written as:

2 5 0 1 0 -1 50 -1 -1 0.000 0 0 -1 0 0 5
    0 weissmies-schema-cns.jpg
     450 450 4500 450 4500 5220 450 5220 450 450

and Xfig gives exactly the same "Incomplete Picture Object" / "Incorrect object code" error when reading it back.

I have performed several additional tests:

• The JPEG files are valid. jpeginfo -c reports OK.
• djpeg from MacPorts reads the JPEG successfully.
• fig2dev -L ps trial.fig > trial.ps reads the .fig file successfully and produces the expected PostScript/PDF output.
• I tested both fig2dev 3.2.9 and fig2dev 3.2.9a; both can read the file.
• I also tested Xfig 3.2.9a_0. It has a different problem: it reports JPEG errors such as:

Corrupt JPEG data: premature end of data segment Invalid JPEG file structure: two SOI markers

with several different, valid JPEG files.

• I therefore reverted to Xfig 3.2.9_2, which at least allows me to insert pictures, but it cannot subsequently read the .fig file containing them.
• All relevant binaries and libraries are arm64.
• The problem appeared after upgrading to macOS Tahoe 26.5.2 and reinstalling Xfig.

The particularly puzzling point is that Xfig 3.2.9_2 itself creates the .fig file, but cannot read that same file back, whereas fig2dev can read it correctly.

Could this be a macOS/Tahoe-specific problem in the Picture-object parser, or a compilation/build issue in the MacPorts version of Xfig 3.2.9?

I would be very grateful for any advice or for a patch/fix if this is a known issue.

Best regards, jchg

[tkl]

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 libraries of X and Xaw (the athena widgets), jpeglib and libgs.

I have looked up the relevant lines and noted that xfig reads the path to an image with

/* read the picture file name */
s1 += strspn(s1, " \t");        /* skip whitespace */
if (!(end = strchr(s1, '\n')) || end == s1) {
            file_msg(Err_incomp, "Picture Object", save_line);
            free_return(l);
}

while fig2dev basically uses sscanf(*line, "%d %n", &l->pic->flipped, &pos);

Another option would be to set LC_ALL=C before calling xfig, LC_ALL=C xfig ..., but this is now really a shot into the dark.

Sorry, only so much for now.

Yours,
Thomas

[Gilbert, Jean Charles]

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

For the lines

2 5 0 1 0 -1 50 -1 -1 0.000 0 0 -1 0 0 5
0 weissmies-schema-cns.jpg
450 450 4500 450 4500 5220 450 5220 450 450

in the file trial.fig, the command "od -j 109 -t c trial.fig" gives

0000155 2 5 0 1 0 - 1 5 0
0000175 - 1 - 1 0 . 0 0 0 0 0
0000215 - 1 0 0 5 \n \t 0 w e i s
0000235 s m i e s - s c h e m a - c n s
0000255 . j p g \n \t 4 5 0 4 5 0 4
0000275 5 0 0 4 5 0 4 5 0 0 5 2 2
0000315 0 4 5 0 5 2 2 0 4 5 0 4
0000335 5 0 \n
0000340

I understand that the end of line is "\n", not "\r", so that the problem does not come from this coding.

Are you able to build xfig from sources? This would entail installing the
development libraries of X and Xaw (the athena widgets), jpeglib and libgs.

I am not a computer scientist... but with the help of the local guru, I guess it could be possible. I woud prefer another solution, however...

I have looked up the relevant lines and noted that xfig reads the path to an
image with
/ read the picture file name / s1 += strspn ( s1 , " \t " ); / skip
whitespace / if ( ! ( end = strchr ( s1 , '\n' )) || end == s1 ) { file_msg (
Err_incomp , "Picture Object" , save_line ); free_return ( l ); }

while fig2dev basically uses sscanf(*line, "%d %n", &l->pic->flipped, &pos);

Another option would be to set LC_ALL=C before calling xfig, LC_ALL=C xfig ... ,
but this is now really a shot into the dark.

I tried

setenv LC_ALL C
xfig trial.fig &

(ChatGPT tells me that I could have entered "env LC_ALL=C xfig trial.fig &"; sorry to work with ChatGPT but I am not knowledgeable enough about these subjects to do without this help) and the error still occurs

File trial.fig:
Incomplete Picture Object object at line 11.
Incorrect object code at line 13.

Sorry, only so much for now.

ChatGPT suggests me to follow your suggestion to build xfig from sources (knowing that MacPorts has already installed almost all the useful dépendences). I wait for your reaction before trying this option.

Thanks a lot for your help.

Regards, Jean Charles

[Gilbert, Jean Charles]

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 to install xfig 3.2.9a from
macports?

Yes it was already installed by MacPorts but not active:

% port installed xfig
The following ports are currently installed:
xfig @3.2.9_2 (active)
xfig @3.2.9a_0

I went back to xfig 3.2.9, because there is another problem with xfig 3.2.9a, which I think was already mentioned on SourceForge.

Well, from my naive understanding, I believe that the problems with both versions of xfig are more or less linked to the system Tahoe 26.5.2, since there was no problem before installing this new system and reinstalling Xfig. Now, xfig 3.2.9 and xfig 3.2.9a have different problems, so that the situation is not that clear.

Regards, jch

[Gilbert, Jean Charles]

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 from MacPorts. It behaves differently, but it also has a problem with Picture objects: with valid JPEG files it reports

Corrupt JPEG data: premature end of data segment
Invalid JPEG file structure: two SOI markers

I find your observation that the Picture filename-reading code was changed after 3.2.9, specifically because of an OS X portability issue, very interesting.

I will wait for your advice before trying to build Xfig from source.

Regards, jch

[Gilbert, Jean Charles]

(After spending several hours working under ChatGPT's guidance — I wouldn't have known how to proceed on my own — we [= ChatGPT and I] finally located the line of code causing the issue on macOS Tahoe 26.5.2; so, in the letter below written by ChatGPT, "I" refers to "ChatGPT". I removed the previous email from this one because I noticed that these emails were being posted in full on SourceForge and that the ticket was becoming really complicated. Thank you very much for looking after Xfig, which is very precious to me.)

Hello Thomas,

Good news: I think we have now isolated the problem to one line in rewind_stream().

Following your suggestion, I built the official Xfig 3.2.9a sources (those on sourceforge.net) myself on my Mac (macOS Tahoe 26.5.2, arm64), using the libraries installed by MacPorts.

The self-built 3.2.9a binary reproduced exactly the same JPEG problem as the MacPorts version:

Corrupt JPEG data: premature end of data segment
Invalid JPEG file structure: two SOI markers
Errors occurred when reading JPEG file ...

This therefore does not appear to be a MacPorts build problem.

I then followed the path used for reading JPEG files.

read_jpg() starts with:

if (!rewind_stream(pic_stream))
    return FileInvalid;

and, for a regular file, rewind_stream() contains:

rewind(xf_stream->fp);
lseek(fileno(xf_stream->fp), 0, SEEK_SET);
return xf_stream->fp;

As an experiment, I removed only the lseek() line, leaving:

rewind(xf_stream->fp);
return xf_stream->fp;

I rebuilt Xfig 3.2.9a and the problem disappeared.

The following tests now all work with this modified Xfig:

1. trial.fig, containing weissmies-schema-cns.jpg, now loads and displays the JPEG correctly.

2. I tested another, unrelated JPEG file (image.jpg), which had previously produced JPEG errors in Xfig. It now also loads correctly.

3. I tested trial-pdf.fig, containing weissmies-schema-cns.pdf. The PDF is also loaded and displayed correctly.

Thus, on my macOS Tahoe system, removing only

lseek(fileno(xf_stream->fp), 0, SEEK_SET);

from rewind_stream() appears to fix the Picture-reading problem.

I also compared f_readjpg.c between 3.2.9 and 3.2.9a. There is no functional change there; the only difference I found is the spelling correction "occured" -> "occurred".

It therefore seems that the combination

rewind(xf_stream->fp);
lseek(fileno(xf_stream->fp), 0, SEEK_SET);

causes a problem with the stdio stream on my macOS system, whereas rewind() alone works correctly.

Of course, I do not know whether simply removing the lseek() is the appropriate portable fix, since the existing code comments indicate that it was added deliberately to handle both stdio and raw file-descriptor positioning. It may behave differently on Linux or other systems.

But the result is reproducible here: original 3.2.9a fails, and 3.2.9a with only that one line removed successfully reads both JPEG and PDF Picture objects.

I will be happy to perform any additional tests you think would be useful.

Best regards.

[tkl]

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 from macports?

Yours,
Thomas

[tkl]

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 tests. These are provided with the sources and are run during the build-process of the application, i.e., they are run when the binary on macports is built. Therefore, errors as you encountered should already show up when the maintainer of the xfig-binary on macports tries to build it.

I planned to publish new releases of xfig and fig2dev very soon. This releases have some functional differences under the hood, but no changes in the user interface. I gave up to give specific dates (instead of "very soon"), but such release should quickly find its way to macports and then be available for you for simple installation, instead of building form sources. The current ticket is a valuable contribution to the functioning, specifically portability of both xfig and fig2dev.

I will close this ticket after I looked into the tests for fig2dev and xfig for reading jpg files. Also, I had edited the discussion on sourceforge to remove some duplicate answers. It seems that the editing also disordered the thread a bit.

Thank you again for sticking to the problem. It seems, you have now a workable solution, and I hope the next release provides a more fluent experience.

Yours,
Thomas