Image sizing

Wow, all the issues are coming up right now :blush:

OK, I have a huge document that has pretty much good enough formatting for this one off run apart from some of the images which are in the text. Some are just a bit big.

Some of the images are PDF clippings, produced in EasyDraw the have come over as PDF objects when pasted, and some are Bitmaps from screen shots.

Now I have a couple of bitmaps that I have inserted using Edit->Insert Image from file and I can scale those by double clicking or right clicking and I get the control.

If, however, I try this with one of the pasted graphics I can’t scale it at all (be it PDF or bitmap). I can of course scale the Compiled version when I open it in Pages but I wanted to keep most of that effort in Scrivener because I may go through a couple of revisions with the customer.

I also note that you get the same behaviour (no scaling) if you do Edit->Insert Image and choose a PDF document.

I have a hunch at the implementation detail around this and I’m hoping the answer is going to be better than I fear :unamused:

The answer is probably the one you fear, alas. PDF files cannot be scaled in the text engine due to technical limitations. It’s really recommended that you use raster graphics for these. Even if your intention is to use them for vector graphics, that won’t work because RTF itself is not capable of embedding RTFs (Scrivener cheats a bit), so the compiler will rasterise them at their current size, sometimes at the reduction of quality. You thus end up losing the vector file anyway. If you need that, I recommend using placeholders (which the current embedded PDFs can certainly operate as). This is all Apple text engine stuff that is very difficult to fix.

What sort of format were the pasted graphics that do not allow resize, do you know? Most raster formats do allow resizing.

Not strictly the case from what I’ve observed AmberV.

I can compile to RTFD and when I inspect the image in Pages it’s showing as a pasted PDF and not a bitmap…?

RTFD is different than RTF. If you are using that format to compile, then PDF will work (sorry, forgot to mention that; but it is of limited use as RTFD only works on the Mac—and then with only some word processors). You still won’t be able to scale them in Scrivener though.

OK, so for my specific purposed where I have quite a few PDFs to get the vector drawings in across a large document and the issue of Pages not recognising Page breaks due to flakey RTF/RTFD support I suppose my only option is to export using dummy page break markers in RTFD, find them in Pages, put in real Page Breaks and then scale the images from Pages…?

That’s a shame since it means the proofing cycle can’t be easily accomplished mainly with Scrivener.

Well, if you need page breaks for proofing, then yes. The only other alternative is using RTF and another word processor to make a .doc file out of it for Pages—and that will drop your vector graphics to raster (although pristine graphics may not be necessary for proofing).

Are you working with an editor for this phase? Otherwise I’d consider using Scrivener’s PDF print for proofs. They may not look perfect, but if you are just doing content level proofing that’s fine. Once you get to layout level proofing—well Scrivener is not the best platform for that. Most people switch to their word processor once it gets to that point, or once files are being swapped with an editor.

I would use PDF but already some of the graphics are flowing beyond one page and don’t fit so I guess it’s going to be the workflow I suggested.

In the long term I need to work out a better solution since being turned on to Scrivener I can see it’s the perfect tool for maintaining technical documents over many generations. I really don’t like to fall back to raster graphics when I have some vector drawings in the main document if at all possible… it just calls into question (from others) why I use Scrivener at all for these tasks.

I do agree, it is nice to use Scrivener for as long as possible into the proofing and editing phase. The tools it has to make the principle writing phase easier are extremely useful for editing, too. Pushing that line until it breaks with convenience is more often than not, a beneficial thing—but I think for most people, undeniably, there is a line somewhere, and once you cross it, it becomes difficult to keep on with Scrivener—even if just because your editor needs one long file while you have 400 small files in your outline. :slight_smile: The two philosophies don’t mix very well in a technological landscape where thinking of documents in small pieces is relatively unsupported. You can handle that with the folder sync tool, but I doubt many editors will take very kindly to having to proof your work in dozens or hundreds of small RTF files.

If you have the time, you might poke around in the tips & tricks and usage boards, here, and see what others have done to help extend Scrivener’s usefulness into the post-writing phase.

Also, in principle, I agree with that. It is like I said initially though: a technical problem. The text engine in use doesn’t have good vector graphic support, and adding that on top of Apple’s code is quite challenging—possibly not even feasible, to the point of being on a list of things that would be nice, if it were ever possible to do a full text engine from scratch (something a single programmer couldn’t do without abandoning everything else for a very long time).

Placeholders are probably the best answer, and using RTF. That means a longer final polish phase when the placeholders fixed in Pages, but that is something you should only do as much as absolutely necessary—same as converting rich text to stylesheets; that’s another thing that can take a while to do—and another thing on the long “it would be nice” list. :slight_smile:

This thread is almost 6 years old. Has any effort been done to address this? Having to use raster graphics is not a solution.

Nothing has changed from what I stated before:

I.e. in the time since I wrote this we’ve been working on Scrivener all this time, not reinventing Apple’s wheel year over year. It’s still the same engine and it’s still in Apple’s court whether or not they choose to improve it and how.

You mentioned before you were using MMD though—doesn’t that essentially mean you can already do what you want? That writing system isn’t limited to what Apple’s RTF editor is capable of doing, and is in fact largely oblivious to it. If you want to include an SVG or PDF in your work, then there are ways to do so that bypass editor limitations. After all the entire premise of the format is that you can write high-quality output with nothing more than a plain-text editor like Atom or Vim.

Jumping in here…sorry if I’m in the wrong topic.

Is this discussion for the problem of pinch-to-zoom being the only way to resize a jpg that you have in a document? That’s what I need to find out about. I can’t pinch accurately enough to resize the jpg to fit the window on the right, and I’m wondering how to get Scrivener on my Sierra (latest version) MBP to “fit to window” the jpg so that I can see it better.

If not, I’ll start my own thread.

I think that is a different topic, but to answer: if the image is in the editor and something meant to be a part of the draft, then you double-click it for precise size control (though sizing before-hand in an image editor will always beat using the system to resize it). If you are talking about a JPG in the binder and it’s too big (or small), the zoom gesture is just for convenience. Again, double-click the image for precise control, including a fit-to-editor option.

What I need is the ability to scale vector graphics so that they don’t always fill entire page width when printed. I don’t want to have to rasterize them to accomplish that. I’m using the RTF/RTE editor, not Markdown. Right now I’m considering adding white space to the charts to force them to scale down as they take up way too much page space as it is.