Resizing embedded PDF (bug/wish tracking system)

Thank you for the great product. I like it very much and now try to use it for my work. I have a few wishes which I believe improves the usability of Scrivener. I found that some of them are already requested in the forum, so I don’t post them because you ask us not to post a “+1” kind of message.

However, I still want to know which of the requested features are chosen for your future product.

For example, I often paste PDF graphics into my document. And inability of scaling the pasted PDF images is a critical problem to me. This was already asked in the forum and you just answered it’s not possible. Because the problem is critical (manually resizing each image before pasting totally disrupts my writing work), I may stop using Scrivener if you won’t implement it in near future.

So a question is “Are you going to implement scaling of embedded PDF images?”

My more general request is to use a bug/wish tracking system. Through such system, users can know what issues/features you are working on now, and what the future Scrivener will be like.

Just a quick question: Is there any particular reason why you need to use PDF images instead of TIFF, PNG, or JPEG? I ask because generally most print houses prefer TIFF for print work anyway, and the other two are pretty well supported by many applications. Embedded PDFs, on the other hand, are much less supported. If it is vector graphics you are getting at, EPS is a pretty good standard for that too, and has broad support amongst printers.

The issue with embedded PDFs is that it is kind of an Apple hack. It works, barely, but like I say it isn’t broadly supported to my knowledge. You might have some specific workflow that is atypical from industry standards, but I thought I would ask anyway.


As Ioa says, embedded PDF files aren’t really supported in most word processors anyway. It’s technically not possible to rescale embedded PDF data, so no, this isn’t planned. However, again as Ioa says, you should embed your images in a different format - any regular image format, such as JPG, PNG, TIF, whatever, will scale fine. Scrivener fully supports image scaling in text; it is only embedded PDF files it can’t scale.

Ioa is looking into an automated bug tracking system in the future, but I don’t really have any plans to make public which new features I am or am not working on. As we make clear on our About page, we want users to judge and buy Scrivener based solely on its current features - we make no promises about future features. Although Scrivener 2.0 has a raft of new features, it is mainly about making the core features of 1.x stronger. The core of Scrivener is exactly what I wanted, so it’s just about making it more mature and intuitive now. (Another reason a tracking system wouldn’t make much sense for a wish list is that I don’t add new features based on votes. Users are always welcome to add to wish list items on the forum by replying and explaining why they would use such a feature or how they see it being implemented or fitting in, but just replying with a “+1” or “me too” is just rude and wastes time, as it means Ioa or I clicking through to find that in fact nothing of value has been added to the thread.)

Thanks and all the best,

Thank you for replies.

I am a scientist and was thinking to use Scrivener for technical/scientific writings. Not for academic journal papers but for longer documents.

In my work flow I use PDF a lot. I keep graphs and figures that I made in PDF. I prefer PDF because it’s editable without losing quality, and can easily be converted to any formats when necessary. For my purpose, uneditable raster formats are not good for draft writing stage. As far as I know, Pages and Mellel properly handle embedded PDF images although MS Word does not (a pasted PDF is converted to a raster image).

I thought PDF is the primary vector format in Mac OS X. internally convert EPS or PS files to PDF when it opens them. When I copy a part of a PDF, PS, or EPS document and paste it in a TextEdit document, the pasted graphics becomes PDF. So it’s surprising to me that PDF embedding is not well supported by the OS.

Anyway I understand your choice. I’ll try to find a workaround.

The OS X text system that Scrivener uses inserts PDFs into text inside an enclosing scroll view. This is so that it can handle PDFs with multiple pages, so you can scroll through them. It’s not ideal, but this means that you can’t really scale them.

More importantly for Scrivener, Scrivener is RTF-based, even more so with 2.0. RTF cannot save PDF images, and so they will get converted to PNG or JPG files internally in order to be embedded into the RTF.

All the best,

You’ll find things like that all over OS X, really—but especially in and around the text system. Much of their text system feels as though they had some great ideas at one point, and then some visionary got pulled out of the department and nothing much has happened since. Exporters with stupid and obvious bugs in them, clunky tables, text-smudge-bug, the only part of the OS that gets slower with every release—and yes, the oddball PDF handling too. Scrivener already does a lot to patch up the base system text code!

Thank you all. I understood that PDF embedding is hard to implement in Scrivener.

Here is an alternative idea for better PDF handling.
How about to embed a zoomable preview image (automatically converted to PNG by Scrivener) in the text and to allow us to open the actual PDF stored under the Research folder by clicking the preview? Currently to drag and drop a PDF under Research folder to a text makes a text link without a preview.

It would be even greater if Scrivener supports LinkBack and allow us to store any LinkBack-supported content in the Research folder.

LinkBack is a great idea that unfortunately never really took off. The list of supported apps has been pretty much the same for years, although I note the TeX geeks seem to have jumped on it since I last checked. When I first heard about QuickLook, I had hoped Apple saw the light, and that applications would be able to easily write their own document browsing portals, like Apple has done for PDFs and such, and that any other application could drop a QuickLook viewer into their program—pretty much expanding and linking every application to one another that supports QuickLook. Alas, Apple didn’t see the light. :slight_smile: QL remains immensely untapped to this day.