Add archiv (tgz) file to a @Article entry


(Buhtz) #1

I tried to add an archiv (tgz, but could be anything else) file to an @Article.
But the OK button in the file dialog is disabled because no “File Type” is selected automaticly. When I select one the button is enabled and I can save it.

But there is no “File Type” for any archiv or something like “Other”.

Is that part of the Biblatex standard or a “bug” of JabRef?


(Matthias Geiger ) #2

You can manage the different file types using the “Options” -> “Manage External File Types” dialog.
Here you can add additional needed file types (e.g., tgz).

Regards,
Matthias


(Buhtz) #3

This smells like a feature request and a bug report. But I need some more informations about it first. :wink:

For myself I see no need to specifiy a type of the file in the "file = " line of the biblatex file. The filetype is most of the time specified by its extension. So in which usecases does a user need something like that?

It looks like that the possible (valid) values for the filetype in the "file = " line is restricted to the JabRef internal list of filetypes (Options -> Manage External File Types). I tried to manualy edit the file type in the "file = " and set it to “Other”. In that case JabRef ignores it and doesn’t display that in the “File” field (there in the third column) of the “General” tab.
I mean JabRef should display the filetype there no matter if it is in its interal list or not. I see no reason why JabRef shouldn’t do it. Do you?

In the “Manage External File Types” dialog is on “Application” specified for “PDF”. But when I click on the world-symbol of a library entry with a local linked pdf file it is opened without problems. How does open that PDF file without knowing a “Application”? Backwards question: Why is this “Application” in the file types dialog needed - or isn’t it?


(Matthias Geiger ) #4

Buhtz,
this is already working…

The file itself is shown in JabRef - however, as the type is unknown it is not shown (but is also not removed or overwritten upon saving).

If you want to have that file type recognized by JabRef (and potentially linked with an application) just add the type in the Manage File Types dialog.

Because for some filetype a default application is already defined by the operating system. I.e., the default Windows app for PDFs is automatically started. If you want to change the application - or in case no system default is present this can be changed/set in the file type dialog.


(Buhtz) #5

You missed 1. I still don’t understand in which usecases this filetype-field is needed. JabRef & Co could select the open-application depending on the filename-suffix.

The file itself is shown in JabRef - however, as the type is unknown it is not shown (but is also not removed or overwritten upon saving).

This is what I tried to describe. And that behaviour makes no sense. :wink:
It looks like that there is code I JabRef that check if the FileType is known or not. If not it doesn’t show the filetype in the file-field in general-tab. There is no reason for that!
JabRef should never ask that question at that point: “Do I know that FileType”? Just display it in the general-tab where it belongs. At that point it doesn’t matter if the type is “known” or not.
I see no reason why the displayed filetypes should be restricted to the by-jabref-known-filetypes!?


(Matthias Geiger ) #6

In order to be able to define filetype specific application settings.


(Buhtz) #7

In order to be able to define filetype specific application settings.

This is not what I meant. The question wasn’t about the in-jabref-filetypes.

Why is this filetype in the Biblatex-file?

And even jabref don’t need it. Use the file-extension. This would simplify the system/code.


(Tobias Diez) #8

The extension is taken into account, but sometimes Jabref isn’t able to infer the correct file type from it. In these cases the file type field can be used to help JabRef.
To be exact, the following code shows how JabRef infers the correct file type:

    Optional<ExternalFileType> type = ExternalFileTypes.getInstance().getExternalFileTypeByName(entry.getFileType());

    if (deduceUnknownType && (type.get() instanceof UnknownExternalFileType)) {
        // No file type was recognized. Try to find a usable file type based
        // on mime type:
        type = ExternalFileTypes.getInstance().getExternalFileTypeByMimeType(entry.getFileType());
        if (!type.isPresent()) {
            // No type could be found from mime type on the extension:
            Optional<String> extension = FileUtil.getFileExtension(entry.getLink());
            if (extension.isPresent()) {
                Optional<ExternalFileType> typeGuess = ExternalFileTypes.getInstance()
                        .getExternalFileTypeByExt(extension.get());

                if (typeGuess.isPresent()) {
                    type = typeGuess;
                }
            }
        }
    }

(Buhtz) #9

Ja und offensichtlich fehlt da etwas. :smiley: Wenn dieser Code keinen FileType ermitteln kann, bleibt das Feld leer, obwohl im bib-File selbst ein FileType steht.

Konstruiertes Beispiel:
file = {:Files/ct.17.07.176-179.pdf:PDF;:Files/ct.17.07.176-179 - Die Beispielprogramme.tgz:Other},

Warum kann er dann nicht einfach “Other” in das Type-Feld im General-Tab setzen?
Also user denke ich beim leeren Feld: “Oh, da ist kein FileType. Muss ich noch ändern.” Dann guck ich in den bib-source und sehe, ach ist ja doch ein Type da.
JabRef interpretiert hier nicht vollständig die Daten und bevormundet den User. Der String “Other” im bib-file ist ein Datum und wird von JabRef aber unterbunden/versteckt. Das ist einer freien Software nicht würdig.

Es geht hier nicht nur um praktische Aspekte, sondern auch ums Prinzip. :wink:

btw: Muss mich mal wieder (nach 17 Jahren) mit Java beschäftigen. :smiley:


(Christoph) #10

Ich verstehe was du meinst:

Es sollte die Option geben den Filetype Other auszuwählen (wenn ich noch keinen eigenen definiert habe für z.B. tgz) beim hinzufügen einer neuen Datei und das dieser auch gespeichert wird.

Sollte eigentlich machbar sein, Muss man halt nur “Other” als Typ definieren, der nix macht.


(Oliver Kopp) #11

For reference: We discussed a redesign of the file field at https://github.com/JabRef/jabref/issues/98, but we decided to keep is at is. However, I think, this discussion is unrelated to the discussion here, where it seems to offer a possibility to add support for Other.


(Oliver Kopp) #12

Sehr gerne! Wir hoffen, der Einstieg via https://github.com/JabRef/jabref/blob/master/CONTRIBUTING.md hilft.


(Buhtz) #13

Diese Format von “file”: “link:description:type”…
Ist das eine JabRef eigenen Konstruktion oder Bestandteil irgendeines applikationsunabhängigen Standards? In der Biblatex-Docu ist es nicht beschrieben.


(Tobias Diez) #14

Das file Feld wird mMn nur von JabRef benutzt (ggf. noch bibdesk) und wurde danach in den “biblatex standard” aufgenommen.


(Buhtz) #15

“file” wird im Standard erwähnt. Aber dessen Inhalt ist scheinbar nicht festgelegt.
Woher komt also das Format “link:description:type”? Scheint also eine JabRef eigene Geschichte zu sein?


(Oliver Kopp) #16

This was introduced by Morten Alver at the beginning of JabRef. For a long discussion see https://github.com/JabRef/jabref/issues/98. Especially https://github.com/JabRef/jabref/issues/98#issuecomment-134569224

Feel free to join and motivate coders to implement

a) the new format
b) migrations to the new format