I noticed something else: if I drag in a pdf image and compile, the pdf image is included in the output directory as I would expect. But if I insert an pdf image using “linked to file” from the edit menu and compile, the image is converted to a png file. I’m not sure if this is specific to the beta or whether it also occurs in the stable version. I’m also not sure if it’s a bug or a feature, but it’s not what I expected and ideally would have liked. Is this a “bonafide bug” or a feature?
It’s a bit of both. When exporting linked images, it ensures they are in either JPG or PNG format, if I recall correctly (it’s the Jubilee Bank Holiday here, so I’ll check the code itself on Wednesday). But this includes PDF files, and I guess I didn’t realise they shouldn’t be converted. I can easily amend the code so that PDF files get exported as-is, and have added it to my list for the next update.
All the best,
Keith
With build 18217 I’m finding that if I save and close a scrivener project with PDFs displayed (in my case with a horizontal split display), I find when reopening it the PDFs are blank until I scroll or switch horizontal - > vertical split, i.e. force scrivener to redraw. If I have a scrivener document and PDF open, only the PDF fails to redraw. I don’t remember seeing this with the previous beta. Unsplit display of a PDF also draws blank on restart, interestingly switching to split display one PDF displays and the other stays blank…
The changelog is a joy to read by the way, lots of useful changes!!!
I’ve been seeing the same thing as well, whatever pages (or parts of pages) are visible when the PDF is first viewed are blank. So if you’ve got 2-page layout and enough screen space to see 2 full pages and the top 1/3 of the next two pages, they will all appear blank. Once you scroll it all shows up as it should and there are no problems from that point onward.
I haven’t been able to find a reliable reproduction case, however. It seems like one computer does it more often than the other. Lion, by chance?
Yes, this is a Lion bug - it should be fixed in the next beta. It seems that in the most recent version of Lion, Apple turned on an internal flag in Interface Builder for the standard PDF View which tells it to use something called “concurrent drawing”. This causes the buggy PDF drawing, and it can cause crashes when you close projects that have been viewing PDF files (at least, it seems so far that the PDF-related crash is caused by the same issue). You’re seeing this in the latest beta because it was built on Lion 10.7.4, which changed the behaviour (programs built on earlier versions of OS X, including the release version of Scrivener, don’t have the problem). As I say, this should - I hope - be fixed for the next update, as other developers have faced the same problem and posted the solution in Apple’s developer forums.
Another buglet in 18217: when I try to open a PDF using the external editor icon in the status bar, I get the following even though Preview does successfully open the PDF:
[code]The file could not be opened.
There was a problem opening the file in the program “(null)”. Please try opening the file in a different program, or ensure that (null) is installed properly[/code]
Although the message has a bug in it (it shouldn’t say “(null)”), this means that there was no default application set up to open this file type, or, at least, that OS X didn’t return it correctly: if there is no application associated with the file type within Scrivener’s settings, then it just calls on OS X to open the file in whatever application it chooses. It’s strange it isn’t working, though. Is this opening with all PDF files, or only one? What happens when you export those PDF files and double-click on them in the Finder?
Sorry I may not have been clear, even though I get the error requester (and bouncing Scrivener dock icon warning), Preview does still open the PDF from Scrivener. It happens to all of my PDFs tested so far.
If I export the PDF from Scrivener, then it is shown to open with Preview (⌘i Get Info) and does open without problem on double-click. Preview is the default app for PDFs — i.e. I haven’t changed it.
I do have a second Lion partition, and LaunchServices has the other Preview indexed in its list, but Finder has no problems opening with the correct Preview.
I can reproduce this bug here. I run Mountain Lion Developer Preview 4. I can try to reproduce it under 10.7.4 tomorrow, if this helps.
I have a possibly related problem: I can Quick Look pdf and other documents from the Reference pane just fine, as long as I am not in fullscreen composition mode. When I try the Quick Look the same files in composition mode (context-click on the file icon in the Reference pane → Open in Quick Look) I only get an empty Quick Look window with the text “no items selected” in it. EDIT: I have this problem on OS X 10.7.4 with the stable Scrivener release, too. Am I doing something wrong here?
Ah, okay, this was just a bug in that last beta, which has been fixed for the next update (or rather, for the official 2.3 release, which is later today).
As for QL not working in Compose mode, gah, that’s a stupid QL bug - as soon as the QL panel is opened, it switches focus to the main window for no good reason, into the text view, and by default text views are set to act as QL controllers and thus it returns nothing. I’ve worked around it so this should be fixed too for 2.3.
Keith, you are my hero. Half of my rather lengthy support email is already obsolete now Let’s hope this 2.3 release arrives very soon EDIT: I can confirm that the problems are fixed in the final 2.3 release. Thanks again.
Thanks. And sero, you should have noticed that your other request made it into 2.3, too - you can now remove .tex as an importable type from the Plain Text Import Types preferences.
When exporting linked images, it ensures they are in either JPG or PNG format, if I recall correctly (it’s the Jubilee Bank Holiday here, so I’ll check the code itself on Wednesday). But this includes PDF files, and I guess I didn’t realise they shouldn’t be converted. I can easily amend the code so that PDF files get exported as-is, and have added it to my list for the next update.
Let’s hope this 2.3 release arrives very soon 