#204 Picture object loses filename (<empty>) for some valid PNG files

[Fabiano Baroni]

For some png files, after including them using the Picture button, the file name field is not correctly set even if the image is shown on the screen as expected. If I edit that picture (using the Edit button), the file name field is blank. If I save the fig file, <empty> appears instead of the correct file name.</empty>

I attach an example of a png file that shows this issue, and one that works without any problem. These were created using matlab. The problem occurs with multiple matlab versions (R2021b and R2025b) and figure export functions (exportgraphics and hgexport).

Rewriting the failing png files using ImageMagick or MATLAB imwrite—without changing the pixel data—eliminates the problem.

I'm using xfig 3.2.9 in ubuntu 24.04. Many thanks

[tkl]

I can not reproduce your experience. In any case, showing <empty> should not depend on the content of an image, but on the actions taken in xfig (clicking buttons and navigating windows in xfig).
Tried with both the development version of xfig and xfig 3.2.9a: Clicking "Picture", marking with two clicks a reactangle on the canvas, then in the "Xfig: Edit panel", which below says: "POLYLINE: Picture Object" clicking on "Browse", in the window called "Xfig: Browse files for picture import" that opens (usually below the edit panel ?!) choosing the file, clicking the "Apply" button, then "Close", back in the first window (I usually click "Use original size"), then click "Apply" and "Done" (Apply could be omitted).
Please, if you can reproduce the issue with the <empty> filename, carefully observe your actions and report them here.

[Fabiano Baroni]

I was following exactly the same procedure you described, the only difference is that I was pasting the file name directly in the file name field, instead of clicking Browse and selecting it from there.

Actually, if I click Browse and select it from there, the image is not shown (clicking Apply has no apparent effect if failing.png is selected).

I tried with xfig 3.2.9a, and the same issue occurs.

In addition to a blank file name field, if I modify the image with Move Points and then click Edit and select the image, I get this error:

Error in xf_external_path(): Unexpected internal path

This file could be relevant:
./src/f_picobj.c: "Unexpected internal path %s", internal);

[tkl]

Ok, this seems a muddle of xfig, athena and key shortcut interactions. Trying quickly to launch xfig 3.2.9a, I could not paste anything, common keyboard shortcuts are not recognized.
Two things seem to come together here: One, failure to read a png (or a file in general?), the second one of dealing with an empty filename,(<empty> is used here as placeholder). This happens at the location if f_picobj.c which you indicated. Could you start xfig with the debug option, xfig -debug, which reports (apart from a lot of noise) whether an image was read?

[Fabiano Baroni]

I attach the output of two experiments with xfig -debug (using 3.2.9).

In xfig_debug_browse.out , I clicked the Browse button, selected failing.png , and then clicked Apply (nothing happened).

In xfig_debug_paste.out , I pasted the file name directly in the file name field (using the middle mouse button). Here it seems that the image was read (failing.png is a symlink to that long png file name). Then I edited the picture using Move Points, clicked Edit, and selected the image object, and got the
Error in xf_external_path(): Unexpected internal path
error, and then xfig exited with SIGSEGV.

I suspect that the issue might arise from a character limit in the file name.

failing.png is a sym link to
/home/fabiano/neuron/meditation/DDA/DDA_10w_4s/acrosssubs_decodeAprime_Aprimeeach_vs_Aprimealpha_thr_timeGeneralize_single_mdt_med2_vs_mdt_think2_rho_iwin_7-interp_interp_pres.png
[179 characters file name]

I did a copy:
cp -p failing.png failing_copy.png
, yielding a 67 characters file name (including the full path), and working with failing_copy.png does not give any issue.

Thank you!

[tkl]

Thank you, now I get it. The path to images is internally saved as absolute path. To obtain the absolute path, the function realpath() is used. But realpath() resolves all symlinks, which is undesired here. To fix this bug a customized realpath()-function will be needed. Thank you for the analysis!

[Fabiano Baroni]

I noticed something weird (potentially a bug) in ./src/f_picobj.c :

int
external_path(char **rel_or_abs_path, size_t size, char *internal)
{
int len = xf_external_path(*rel_or_abs_path, size, internal);

if (len < (int)size) /* includes len < 0 */
return len;

if (!(*rel_or_abs_path = new_string(len)))
return -1;

return xf_external_path(*rel_or_abs_path, size, internal);
}

A long enough buffer is allocated with new_string(len), but then xf_external_path is called with the same size (typically 128 bytes).

Replacing

return xf_external_path(*rel_or_abs_path, size, internal);

with

return xf_external_path(*rel_or_abs_path, len + 1, internal);

solves the issue and allows xfig to work with long file names without any problem.

Thank you and best regards

[tkl]

Amazing, you went through this weird code section? In addition, I still should replace the call to realpath(). Otherwise, the .fig files will contain the resolved file name of the image, not the path to the symlink. Since the user created a symlink for a reason, resolving it is the wrong thing to do.

[Fabiano Baroni]

Ok, I guess that might also matter for some users, even if in my case it doesn't really matter, I just created a symlink in the process of investigating this particular issue. But the limitation on the full file name length was an issue, and such a low limit was clearly not due to the OS or the programming language (Ubuntu can handle full file paths up to 4096 characters), so I'm happy that I can now use my long file names directly without having to use hard links or some other workaround :)