> On Nov 12, 2015, at 13:18, Marc H. Scholl <marc.sch...@uni-konstanz.de> wrote: > > Christian, > > > > On Tue, Nov 10, 2015 at 21:01h, Christiaan Hofman <cmhof...@gmail.com > <mailto:cmhof...@gmail.com>> wrote (with possible deletions): >> […] >>> 2. drawing in presentation mode: drawing is not working at all (nothing >>> shown, no anotations added) >>> >> >> Is the note also not there after you go back to normal window mode (look in >> the note table)? I think I may know what goes wrong, at least during the >> drawing (afterwards, it would be the same as above). To test this, could you >> try to set the SKUseNormalLevelForPresentation hidden pref (See the Wiki)? >> To do this write the following in Terminal.app (while Skim is not running) >> and hit Enter: >> >> defaults write -app Skim SKUseNormalLevelForPresentation -bool true >> >> Does the line show after that (at least during drawing)? >> >> You can reset this hidden pref afterwards using “defaults delete -app Skim >> SKUseNormalLevelForPresentation”. > > … I checked both: > > 1. by looking at the list of notes, I could verify that indeed the freehand > WAS added - it is only that it never shows when drawing in presentation mode, > and > > 2. if I set the hidden pref, as advised by you, then the drawing DOES show > while the pen is on the tablet and goes away when it is lifted. >
Great, that confirms what I thought. This will then be fixed in the next release. >> >>> Point 2 is particularly bad, since I was using freehand anotations a lot in >>> my lectures. >>> >>> In addition: what I noticed in scenario 1: when I draw quite a bit without >>> lifting the pen, some fragements—not necessarily contiguous ones—of the >>> line will stay visible once I finally lift the pen (possibly the line >>> fragments have been shifted on the paper, I’m not sure). It doesn’t seem to >>> be reproducible when that happens and what parts remain visible…. Strange! >>> >>> And btw: same behavior, if I use the magic trackpad to draw. >>> >>> Cheers >>> —Marc >>> >> >> This is weird. This may indicate that PDFKit does draw the notes, or at >> least attempts to, but messes up the coordinate systems when it draws lines >> in the notes (they seem to fail for all notes that consist of lines). This >> actually makes a bit of “sense”, as the also mess up the coordinate >> transformations on El Cap when copying parts of the PDF (which we had to >> work around), and for notes that are drawn on rotated pages. So this may >> just be another case of that same bug (or the same Apple developer with a >> bad sense of direction). > > Indeed I verified that: if I draw a „big“ freehand annotation, some parts of > it are shown after lifting the pen. By double-clicking on the item in the > notes list, one can see that the bounding box is in the right place, but the > parts of the lines that are shown are shifted (towards the bottom and the > left, in my case on a landscape formatted pdf). > > Best > —Marc Thanks, that gives me some idea as to what Apple does wrong exactly. They don’t take into account for the fact that the lines are saved as relative to the note itself, and not relative to the page, so they draw as if the note is shifted to the lower left of the page. I also suspect that they forget about the page rotation, from what I have seen for other types of notes. I have passed this on to Apple, they really should fix this now, it should be pretty simple for them (but not for us). Christiaan
------------------------------------------------------------------------------
_______________________________________________ Skim-app-users mailing list Skim-app-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/skim-app-users
