On 03/13/2013 03:48 PM,
philipp...@uniklinik-freiburg.de wrote:
> I found your great tool for my Sony prs t2 on-line and have been playing
> with it today. It is exactly what I need for reading my scientific
> literature and for the most part it seems to run fine for me (using a
> MAC OS 10.6.8). Great work!
Thanks! Glad to hear it's working for you.
> One question that came to me was how to add several files at once since
> I would like to add 80 papers to the sony.
There's no way to do this with the GUI at the moment. But this is the
sort of thing that command-line interfaces excel at. If you're using
the bash shell (I think this is the OS X default now), you can use
for f in *.pdf
do prsam add $f
done
to add all all the PDF files in the current directory to the PRSAnnots
library. All of the options from the GUI are available on the command
line; run
prsam add -h
to see them.
> I was also wondering if there is a good reason why a new pdf
> (.annot.pdf) is created on the computer instead of adding the notes
> to the original one (basically overwriting it). Is there a way to
> avoid this new file maybe by changing the name of the newly created
> file to the original file name? It would be great if you could
> comment on that.
There's two reasons to do it this way. First, it means that if
PRSAnnots messes up writing the annotated PDF file, it won't destroy
your existing copy. Second, it makes it easier to create an updated
annotated version - we just put all of the current annotations on the
original file, instead of trying to strip off the old ones first.
Whether these are *good* reasons, I'll leave you to decide.
One way to deal with this would be to move the original file to a hidden
name and put the modified file in its place. If this would be of
interest to you, let me know. I don't think it would be the default,
but it could be an option.
>
> While playing with it today I came across the issue #7 with the
> highlighted text not found. If I got it right it is a problem with the
> line break so I should be fine if I mark every line individually as a
> work-around. I am not sure if this is too annoying but I'll give it a try.
Finding highlights is a pain, and there's no way to ensure it's going to
work, I'm afraid. My suggestion is to make highlights of moderate
length - long enough to be a unique bit of text but no longer. Avoiding
line endings and non-English letters will probably help.
I realize this is frustrating. It bugs me too, but I haven't been able
to reverse engineer how the reader is storing the highlighting info. So
we're stuck with this buggy text matching for now.
Robert