Now what I don’t like with automated solutions is that occasionally they don’t work – and that’s of course when you’ve no time to debug and fix it.
My automated solution of bibliography generating using BibDesk is massively effective, except that it occasionally fails.
So instead of running a Preview nicely such as this:
I’d run into an error with the LaTeX preview not showing up, but throwing me some error log that, as it nicely says, “may or may not help.” Now I had run into this very infrequently, but it was sufficiently annoying that I figured out that I had to remove a particular temporary directory, and I’ve actually kept it as first line in every book list so that I can quickly look it up (see red arrow above). Well, this morning, at my normal mental boot time at 4:30, my system greeted me with again with this “come on let’s procrastinate a bit and fix this other annoying issue first of all” as I just happened to see this in one of my recent documents:
As you can see in the image above, the encoding is somehow broken. And yes, I got an error in BibDesk as I wanted to preview. I had the good idea to look into the system log and saw that actually there was an encoding error, and it even said in which directory it happened to be in – which was of course the directory that a long while ago I had already figured out by trial and error. Turns out, while the LaTeX log won’t tell you anything in this case, BibDesk actually captures the error – so it makes sense to check out the system log, as well:
Searching into my actual bibliography file, I saw this:
So obviously when copy-pasting the metadata from the article that I had downloaded somewhere, OSX was overly intelligent and copied over some special characters that I really don’t want in that ASCII file. Here’s a way how to locate those:
So, as part of the import process or regularly, that’s a way to spot them before they go unnoticed.
