I’m looking at directory full of PDF files, which naturally have a boatload of attributes like PDF:version, or META:keyw (Keywords)
User Guide says: “To do this [choose which attributes to display], open a Tracker window, click on the Attributes menu, and select the attributes you want to display.” But the options here are limited to standard file attributes, and these META:keyw etc. attributes aren’t among them.
I’m probably missing a step here?
Ideally, I’d like to annotate PDFs with a contents list - author and title of articles - which is a little like META:keyw, but not really, so perhaps it would be better to find or add another META:something attribute … which I have no notion how to do.
I may indeed want to index this attribute, but the examples I’m seeing out there display attributes without indexing them all. It seems to be more about attaching an attribute to a whole custom file type.
All attributes that are marked as “Visible” are shown in Tracker:
If marked as “Editable”, the attribute values can be directly edited in Tracker (although the edit UX is a bit wobbly with the delay and all).
The index only affects which attributes can be included in a search (using “query” on the command line, or the “Find” function from the Deskbar menu).
Sadly you cannot mark an attribute as “indexed” in the FileType’s attribute editor, but that could be added easily (and I will infact propose a PR for that).
Note that you CAN search for non-indexed attributes IF you include an indexed attriute in the same search. This is an un(der)documented feature and comes in handy when you want to filter for additional properties but don’t want to create an index for every attribute you might want to include in a search.
This appears to be a bug. I don’t see attributes of the PDF filetype either (on Beta5). Please consider filing a bug.
Normally, as soon as there’s a PDF file in folder, you should see all PDF attributes in the “Attributes” menu. You can check by e.g. copy an image or Person file in your folder. That works, but for some reason not for PDFs…
I usually go into edit-mode by pressing ALT+E (or F2) and then use TAB to move to the next editable attribute (and SHIFT+TAB to go back to the previous one).
Attributes are not actually fixed to a file type. For example, META:keyw (as the “META” stresses), can be used for any file. But if a file type lists it as “Extra attribute” in the Filetypes prefs, you’ll see it in the submenu of the “Attribute” menu in Tracker windows (only you don’t for PDFs for some reason…).
So, this means you could e.g. copy a Bookmark file into your folder with the PDFs, go to the Attributes menu and activate “Keywords” under the Bookmark entry there.
Now you can delete the Bookmark file, but still edit the “Keywords” of any file in your folder. The META:keyw attribute will be added to the edited file.
I had the same issue but closing and reopening the window helped.
I am on the latest nightly though.
Also, good you bring up the “flat” definition of attributes and the possibiltiy of reuse.
I am taking advantage of this in SEN so to reuse indices and definitions, e.g. using “Media:Title” also for Book files. No need to define another attribute for the same thing.
(I’m at 58867, by the way. No PDF attributes for me, no matter how many times I close and open a Tracker window – but that directory now has Bookmark attributes, even after I removed the bookmark file.)
If I go ahead with this, I’d have, who knows, 25Kb of “keyword” data indexed, on a removable. I’m guessing that the size of any index isn’t particularly a burden to the system, as long as it’s relatively static, and guessing that I’ll have that big index whether the removable is mounted or not.
I don’t get the PDF attributes either, no matter if I reboot of boot into the latest nightly…
I assume you misspoke, but to make it clear, the folder doesn’t “have Bookmark attributes”, it just displays them in a column for all files that happen to have that attribute.
AFAIK - others know better about the technical reason - it’s not so much the size of the indexed data (within reason, ofc), but the number of indexed attributes.
Indexes are stored per-filesystem, so for files on a removable drive, they’re indexed on the removable drive’s BFS partition, not the install partition.
It’s both, but yes, the number of indexed attributes matters more.
If there’s an index for, say, Media:Track, but no files on the system have that attribute, then the index will be empty. If there’s only 10 files with that attribute, then there’ll only be 10 entries in the index.