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 :)

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

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

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

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

Thank you @tkl, actually with a more recent version (3.2.8b) the -F option works for outputting to png (but not to svg), and the font size still shrinks a bit but not as much. If I set units to Imperial (fraction), and then export to png, the font size looks ok (as in xfig). The same result is obtained using fig2dev with the -F option. When exporting to svg, font size is still shrunk (maybe because fig2dev does not recognize the -F option for exporting to svg, or at least that might be part of the...

Thank you @tkl, actually with a more recent version (3.2.8b) the -L option works for outputting to png (but not to svg), and the font size still shrinks a bit but not as much. If I set units to Imperial (fraction), and then export to png, the font size looks ok (as in xfig). The same result is obtained using fig2dev with the -L option. When exporting to svg, font size is still shrunk (maybe because fig2dev does not recognize the -F option for exporting to svg, or at least that might be part of the...

xfig (through fig2dev) reduces font size when exporting by a factor of 1.3229. I first thought this might be related to the particular point size adopted in xfig (1/80 inch in xfig/fig2dev, as opposed to 1/72 inch), but that's not the case (80/72 = 1.1111). Actually, the -F option is not recognized by fig2dev when exporting to png, and one gets the error Argument -F unknown to png driver. Opening xfig with the -correct_font_size option does not have any effect either (as expected from fig2dev not...