Thank you!
I had wondered whether Scrivener might have been modifying the images internally. For some reason, I had missed or forgotten the preferences setting you mentioned, so obviously the reason why png images I imported into Scrivener always were coming out as jpegblip is that Scrivener converted them into jpegs! That clears up one bit of confusion.
As for the image-scaling business, your answer also clears up some confusion for me. So on import of an RTF file containing an image, all of the possible RTF scaling and sizing information is ignored, and the image is simply placed into the text? I didn’t suspect that. I did know that Scrivener resizes images; in fact, it appears that one must use this function to get a printable file if the original image is larger than the margins, but I was hoping to be able to import RTF files that contained images that were already sized correctly. How does Scrivener do the resizing on export, does it actually recompute the image bits and put out a file that has different dimensions from the image’s dimensions on import at the bit level? Is this why one must choose an image output format, because the images are being recomputed on export?
Now, your explanation of how the numbers used in the exported picw & pich commands are derived is less clear to me. I spent quite a bit of time on Internet trying to find a rule for this, and what I found was that the size of a pixel is intended to vary depending on the output device. That is, there is no constant size of a pixel. Apparently, this fact has confused Windows-based developers of, e.g., forms that must display and/or print on a wide range of devices, for quite some time. I guess that early on, most people assumed 96 dpi, since that corresponded to VGA and other early displays, but of course that changed with different displays and was useless with things like laser printers. I believe that on Windows, there was a system-wide pixel-size parameter that could be set to control this on different machines according to the main display’s resolution. If you look at the early, Windows-only bitmap graphics formats that were being inserted into RTF files back then, you’ll see that the dimensions of the bitmap were found only in the picw/pich commands; they were essential for the correct intepretation of the hex-coded bits. Later, when the “metafile” formats were developed, they were also encoded into the graphics files themselves, as of course they are in jpegs and pngs, and picw/pich became redundant. If Scrivener is, in fact, recomputing the image bits as they are resized, then I suppose the exported pixw/pich numbers are the actual dimensions of the (recomputed) image and therefore they don’t have any connection to image size in twips or inches except in terms of whatever Word might be using as its default dpi setting.
The picwgoal/pichgoal commands, along with all the other image-scaling commands, were aimed at the problem of printing RTF files, because in the world of print, pixels are the wrong way to do things and points, twips, and dynamic rescaling of images are the right way.
So, in my playing around with these files, what I found was that it was not necessary to modify the content of image files at all, for Word, they can be resized simply by changing the picwgoal/pichgoal commands preceding them. However, this doesn’t work with the picw/pich commands, and in fact, as I said before, Word may be ignoring them completely; it definitely does so in some cases. (In any case, if Scrivener is simply copying the actual dimensions encoded into the embedded–resized–image file, they are redundant.)
As to why I am doing this, well, I’m still in the mode of trying to make submittable manuscripts in APA format that are Word-compatible. One of the new requirements is that figures be incorporated into the text on the same page as the figure caption (previously, they were submitted separately as high-resolution image files). I’m trying to understand how Scrivener’s conception of RTF images differs from Words, specifically as it pertains to Word’s notion of embedding an image file “as-is” (i.e., full resolution, just copied into the text file in hex or binary format), but scaled for printing in a specific manner. It would be useful if the full-resolution versions of the figures could be embedded into the submitted manuscript rather than having to provide them separately later on.
Thanks again for your illuminating reply, RTF is just unbelievably opaque.
Greg Shenaut
).