We've currently got Category.image, Category.video, etc. The troublesome one is Category.other. Many skins support images, videos, web locations, and PDF's, but not things like Word documents or zip files. As a result, a lot of otherwise simple tests become clumsy compound affairs:
Not sure I understand the use case for that. If you look at the list of jAlbum supported file types, once you get past images, videos, audios, web locations, and PDF's, it's a pretty motley collection - mostly things I've never encountered in a live album. And it includes some things like DjVu files, which haven't been seen in the wild in almost two decades.
I was thinking that since you mentioned Word and zip files as well as PDF there might be a requirement for more than just a PDF object category. Most 'other' file types might be oddball and not often used, at the moment, but an extensible object category would add a bit of future proofing.
Users can already extend the supported file types using their own custom filetype.xml file. Object categories could similarly be extended either via the skin or the user's config directory.
About ten minutes of coding and testing. It would have been quicker, but at this hour of the morning my eyes don't work very well, and sometimes can't tell the difference between a minus sign and an equals sign.
I happen to love the Stream API, but I usually need to look up the details. Add the word parallel() to the chain, and the whole thing is solved by multiple CPU cores as well That helps speeding up traversing deeper folder structures.