Due to the fact that the %details-F_file_upload% keyword is not available for an asset builder of asset type “PDF File” (Bug #2306), I’m having to use an asset type of File.
Is there a way to restrict this asset builder to only accept pdf files?
No. That's why you'd need to use a PDF File asset type. Its the only way of restricting the asset builder. Also, if you don't upload your PDFs as actual PDF File asset types, they will not be indexed by the Search engine.
So until this "feature" is fixed as a bug, you're forced to create your pdfs in the backend and not via an asset builder page.
This only affects Asset Builders with Custom create forms. If you do not customise the create form, you can create PDF Assets with an Asset Builder.
True, but the default asset builder create form is ugly 
Maybe try fixing its layout with javascript? I could work for now, and make it not so ugly.
Yes, I'm not going to debate you on that. However, check the Layout Manager -- in v3.16 there is the option to disable the edit.css from being painted in Simple Edit (which I think includes the Asset Builders, but I admit I'm not 100% sure). You might find it easier to style with this disabled.
Changing that option made no difference at all to the asset builder.
Ah, bum. Can you log that as a feature request so that I can at least take a look at changing that myself when I have a spare moment? Though, the irony is that this is one of the reasons the custom create form was created. :)
Just noticed that the look and feel under simple edit didn't change when I set Yes or No for the Output edit css file.
All that happened was that the following line was removed or not depending on whether yes or no was selected.
<link rel="stylesheet" type="text/css" href="http://***********/__lib/web/css/limbo.css" />
I don't even think this css file is being used as changing something as simple as the body background colour to red did nothing at all.
That CSS should contain all of our default editing styles (as used by the Administration Interface).
So it's not used in "Simple Edit" mode?
It certainly get's loaded when I view the source of the iframe but it doesn't seem to be applying when I change it.
It is used -- if you disable it, the CSS should not be painted into the frameset. Or, you can override the styles with your own CSS (its painted before any of the CSS files in the design are painted).
As I said earlier, when I set the body background to red nothing happened in the frameset that I could see whether it was on or off and there was no variation in the display of anything else with it on or off.
Where are you setting the body background? In that CSS file? If so, make sure your browser hasn't cached it. We don't recommend editing that file directly, as it will get overwritten when Matrix is upgraded. Rather, you should be overriding the styles with your own CSS (or disabling the file completely). Most likely what is happening is your own body background tag is overriding the limbo.css.
OK, I worked out I could just put the relevant css into my site css and use the !important flag where required to stop it being overridden. Still not the nicest way to do it but until we can get the %details-F_file_upload% keyword available for custom layouts for pdfs (and all other file types it isn't currently available for) it will have to do I guess.
The css is applied for asset builders like it is for simple edit. Sorry for the statement earlier saying it wasn't. It required the !important bit as stuff was being overriden down the line.
Glad you found a solution.
I'd say this is a bug as well, rather than a feature.
Keywords should be inherited from the parent asset. Whether that's done by compile_locale.php or at runtime, or by the keywords being added to each asset, I don't think it matters; but we can't currently expose individual metadata fields when uploading files from the frontend, and that is very annoying and confusing for our users.
Keywords are inherited from parent asset types, where they are not overridden by the child. In this case, the PDF File asset has its own upload process, so requires its own upload keyword. However, I'm not sure what that has to do with individual metadata fields being exposed? The Asset Builder can expose any field from the metadata schema you chose to apply during the create process.
You can only expose individual fields from the schema by using a custom layout. And you can't use a custom layout for PDF files because the upload keyword doesn't work. So for PDF files, it's all or nothing.
Incidentally, if you have more than one asset type on the asset builder, the metadata isn't usable anyway, because of a javascript problem - I will log this as a bug separately.