#747 Wrong export of file attribute to bibtexml

[Christian Berndt]

When exporting to bibtexml one file record is expanded to an absolute path. For example the (via "Synchronize file links") set file field:

file = {BDPP0005-A4.pdf:BDPP0005/BDPP0005-A4.pdf:PDF;BDPP0005-NoScale.pdf:BDPP0005/BDPP0005-NoScale.pdf:PDF;BDPP0005-WithGrid.png:BDPP0005/BDPP0005-WithGrid.png:PNG
image;BDPP0005.png:BDPP0005/BDPP0005.png:PNG image;BDPP0005-NoScale.pdf:BDPP0005/BDPP0005-NoScale.pdf:PDF}

produces following bibtexml export:

<bibtex:nstandard name="file" type="pdf" description="BDPP0005&\#45;A4.pdf">BDPP0005/BDPP0005&\#45;A4.pdf</bibtex:nstandard>
<bibtex:nstandard name="file" type="pdf" description="BDPP0005&\#45;NoScale.pdf">BDPP0005/BDPP0005&\#45;NoScale.pdf</bibtex:nstandard>
<bibtex:nstandard name="file" type="png" description="BDPP0005&\#45;WithGrid.png">BDPP0005/BDPP0005&\#45;WithGrid.png</bibtex:nstandard>
<bibtex:nstandard name="file" type="png" description="BDPP0005.png">/var/www/digitalpantheon.ch/repository/BDPP0005/BDPP0005.png</bibtex:nstandard>

The first 4 records are as expected while the last is expanded to its absolute path.

I have no idea why the export fails only for one record. But it fails with exactly one record of the file-field. (i.e.: if you have only one record in the file attribute, the path will be expanded to the absolute path instead of using the relative path of the file).

It seems to be a problem with the "ugly hack" in the net.sf.jabref.export.layout.format.WrabFileLinks - class (line 123) but I was not yet able to fix it.

[Morten Omholt Alver]

Thanks for reporting this!

The correct behaviour is to expand all links (it seems like your expectation is the opposite - why would you want the relative links only?), and I haven't been able to reproduce the behaviour where only the last one is expanded. Is there any difference between theses file links - i.e. are all present below the file directory? Also, does this problem occur predictably (just making sure, I think your description indicates that it does)?

[Christian Berndt]

I see - in deed i expect the file references unexpanded in the export. Im using the bibtexml export to create an online repository for a research project. (an html-"skin" generated via xslt from bibtex(ml) metadata. And the path to the resources on the server is not necessary the same as on my local machine.) So I'm interested in a "relative" link to the resource like in the bibtex-src.

Regarding your second question: you're right. It's not always the last file in a set. The position of the expanded reference varies but I can't see any pattern. When there is only one file reference, this one is expanded. When there a multiple references only one is expanded but not always the last. All files are present on the "expanded" location.

I'll attach a sample of my bibtex-src and the bibtexml export so you can investigate the problem with a real live example.

[Christian Berndt]

Bibtexml export with expanded and unexpanded file links

[Christian Berndt]

Bibtex Database with relative file links

[Morten Omholt Alver]

Christian,

it's not so easy to test it with your example, because file expansion depends on the file being present. But if you can try a test version with some extra debugging output, we can probably figure out what's happening.

I've put it at the following address: http://129.241.10.111/JabRef-2.4.3.jar

If you try it, do the export and open Help -> "Show error console" and tell me what is displayed in the "Output" tab.

[Christian Berndt]

Morten,

I tried the export with your JabRef-2.4.3.jar. When I try to export to BibTeXML I get a NullPointerException. Output of the error console:

Opening: /home/berndt/Desktop/Inventory20.bib
Globals.prefs.fileDirForDatabase: '/var/www/digitalpantheon.ch/repository'
Filedir: '/var/www/digitalpantheon.ch/repository'
Unexpanded link: 'BDPP0001/BDPP0001.jpg'
Expanded link: '/var/www/digitalpantheon.ch/repository/BDPP0001/BDPP0001.jpg'
Globals.prefs.fileDirForDatabase: '/var/www/digitalpantheon.ch/repository'
Filedir: '/var/www/digitalpantheon.ch/repository'
Unexpanded link: 'BDPP0002/BDPP0002.bmp'
Expanded link: '/var/www/digitalpantheon.ch/repository/BDPP0002/BDPP0002.bmp'
Globals.prefs.fileDirForDatabase: '/var/www/digitalpantheon.ch/repository'
Filedir: '/var/www/digitalpantheon.ch/repository'
Unexpanded link: 'BDPP0003/BDPP0003-A4.pdf'

Stacktrace of the Exception:

java.lang.NullPointerException
at net.sf.jabref.export.layout.format.WrapFileLinks.format(WrapFileLinks.java:136)
at net.sf.jabref.export.layout.LayoutEntry.doLayout(LayoutEntry.java:238)
at net.sf.jabref.export.layout.LayoutEntry.doLayout(LayoutEntry.java:177)
at net.sf.jabref.export.layout.Layout.doLayout(Layout.java:149)
at net.sf.jabref.export.ExportFormat.performExport(ExportFormat.java:241)
at net.sf.jabref.export.ExportFormats$1ExportAction$1.run(ExportFormats.java:244)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at spin.Invocation.evaluate(Invocation.java:175)
at spin.off.SpinOffEvaluator$1.run(SpinOffEvaluator.java:108)
at java.lang.Thread.run(Thread.java:619)

(With the same sample as posted previously)

[Christian Berndt]

Morten,

I think I found the pattern: all files with a minus (-) in their name fail to get expanded. Hope this helps - otherwise I have to rename quite a lot of files ;-)

[Morten Omholt Alver]

Ok, the exception was triggered by my debug message. Could you download it again from

http://129.241.10.111/JabRef-2.4.3_2.jar

and try again?

[Morten Omholt Alver]

Ok, it's caused by the XML character conversion which happens before WrapFileLinks is called. Perhaps the character conversion should be omitted here.

[Morten Omholt Alver]

If you try

http://129.241.10.111/JabRef-2.4.3_3.jar

I've removed the XMLChars formatter for the file field. Let's see if that solves the problem with file expansion.

[Christian Berndt]

That solved the issue.

With your JabRef-2.4.3_3.jar all file links in the bibtexml-export are expanded as intended, also files containing a minus (-) in their name. Exactly the opposite of what I expected. But I have already wrote a task which rewrites the export for my purposes.

Many thanks for your immediate fix!

Looking forward for your next release. Great tool!

Kind regards,

Christian

[Christian Berndt]

Bibtexml export with expanded filenames with JabRef-2.4.3_3.jar

[Nobody/Anonymous]

Good. I have to consider whether there was a reason in the first place to have the XMLChars formatter there, but probably file names shouldn't be mangled like that.

One thing I can do in regard to your problem is to add a marker to the WrapFileLinks formatter that inserts file names without expanding them. That would make it easier to control the output in custom exports, but wouldn't have any effect on the built-in exports (which would have to use one or the other).

The inability to customize export filters (without editing layout files) is an architectural limitation that I'm not sure how we could address.

[Christian Berndt]

A marker in the WrapFileLinks formatter for custom exports would be helpful for sure. I haven't yet tried writing a custom layout file. But it should be a manageable task.

I'm not sure which format (expanded or unexpanded links) I'd prefer for the default behaviour. Well - you know, I expected the bibtexml export to give a true accound of my bibtex bibliography (with relative links).

Actually I chose the JabRef bibtexml export as a starting point for my xslt-transformations because bibtexconverter (http://bibtexml.sourceforge.net/details.html) after my fancy converted a bit too much. (converting keys to lowercase, rewrite authors & editors to lastname, firstname and so on.)

[Morten Omholt Alver]

It is actually very easy if you simply want a modified BibteXML export. You need to get the three bibtexml*.layout files from the JabRef source tree, and just modify that and register it as a custom export. Of course, the new marker in WrapFileLinks will not be available until the next JabRef release unless you use the SVN version.

@morten: I just ran into the same trouble with the absolute paths in the BibTeXML file as chberndt did in March. Why do you think it is a good idea to have them expanded as absolute paths there? This prevents it from any usage outside the location where it was generated :-(

I can solve my issue doing a hack of adding a regexp in my tool processing the BibtexML file to remove them, but this is not a nice solution.