GNOME Bugzilla – Bug 122173
&[path] should be rationalize
Last modified: 2005-04-01 20:44:09 UTC
In Excel XP there is the possibility of specifying &[file] and &[path] fields in the header/footer setup which will be replaced when printing with the filename (ie. workbook.gnumeric) and path (ie. /home/patrick) respectively. This would be a useful addition to Gnumeric since printed reports developed in the spreadsheet often needed to be looked up again and is facilitated by the ability to immediately locate the appropriate file.
Gnumeric already accepts &[FILE] printing the path name of the current file. (And considering the current code it would be trivial to make &[FILE:0] print the basename only.) Note: in a custom format preview &[FILE] is invisible but will be shown in the print preview.
It prints the _relative_ path to the file. We should probably fix that to being the basename (if that is what xl does), and add a PATH entry for XP compatibility. Should be pretty simple aside from rationalizing the path. We can throw it in for 1.2.1
We now have in cvs (for 1.2.0): &[FILE] prints the basename of the file &[PATH] prints the absolute path and file name of the file There is one minor problem remaining: &[PATH] is not rationalized so that it may be /home/aguelzow/cvs/gnumeric/../../file.gnumeric if the file was opened from the command line as ../../file.gnumeric.
That's great Andreas but it might be better if path just meant the path since it is split this way in xl? I suppose &[path]&[file] in xl could be reduced to just &[path] on import and vice versa but wouldn't it be less work to have direct mappings?
According to the MS Knowledgebase [&Path] should stand for the complete path with filename. (At least the way I understand it.) I do not have XL2002 to try it out. If you are able to use a copy of XL2002 please let us know what it is doing.
Checking a few other web sites, I find that you may be right. I have changed the behaviour of &[PATH] but it may still be nice if you could confirm that %[PATH] does not include the basename.
This appears to have been fixed in the meantime.