If we are not supposed to use points, why does the GUI express points, you cannot have it both ways.
You actually do use points for all formats except ePub/mobi.
Katherine
What we seem to be having a hard time communicating is that the debate between points and pixels is beside the point, so to speak. In this context both of those units are inadequate within a flexible layout design; neither has a solid advantage over the other, and in the present tense, neither is terribly reliable or predictable and will differ from one system or device to the next. Given that this is the case, it would not make sense for us to spend time unravelling and changing how this works, if the result of doing so does not in fact provide an improvement in the output (and I would even go so far as to say it would be a detriment).
This has been stated, but perhaps not illustrated well enough. Have you tried what you are suggesting and substituted “px” for “pt” in Scrivener’s generated CSS and then opened the result in the ADE ePub engine and iBook reader and compared it with the Photoshop copy? I have, and it doesn’t solve your problem. It makes it a little larger than the pixel indicated version, but it’s still markedly smaller than the intended image:
[size=80]Here we have a cropped selection of samples as displayed in iBooks. They have been left to scale with one another, all I did was trim out the grey matte so that the illustration can be more concise.[/size]
On the left side we have the image that roughly matches what the graphic looks like in Scrivener’s editor, when imported as a print-ready graphic. On the right-hand side we also have an image that matches what we see in Scrivener, only we’re using a proper screen-ready 72 DPI graphic instead of a print image. In the middle we have something that is awkwardly neither. It is larger than what we have in Scrivener, but smaller than the image as it is intended to be displayed at screen resolution—this is the result you are arguing for, set manually to 259pts in the CSS. In the middle bottom we of course have the file as it opens in Photoshop, and at the scale it is intended to be viewed at.
So yeah—if you feel like your suggestion isn’t being acknowledged, this is part of why. I thought we had moved past that point in the conversation, but did not realise it had yet to be really thoroughly addressed, sorry about that.
Now that we are all hopefully on the same page, the main problem we are facing when thinking about making this more intuitive or flexible, and what we’ve been discussing above, is that the ideal units of measurement are unreliable or difficult to extract from any form of WYSIWYG mechanism rooted in a print-based context, and particularly so in a program like Scrivener, where layout is something done to source material, rather than being an inherent property of that material (like in Word):
- Em scales with the local font metrics around the image. What does that mean in a program that allows one to use 18pt Consolas while writing?
- What is “width: 98%” when the fixed width editor setting is entirely arbitrary, and even more reliable markers of relative measurement between elements in a page and the page, like print settings, are unreliable when one can with the flip of a switch go from paperback novels to printing outlines on A4 (never mind there is no paper with an eBook so any use of paper is as weird as using points and pixels).
Do you have any suggestions toward these issues?
I appreciate your scientific view on this, but lets take a moment to think about your users. Most of them are not typesetters, or coders or web-page creators. Let’s pretend for a moment that I was not in receipt of all the technical education you have provided.
I take an image that is is 1080x1440 at 300 dpi
I place that in Scrivener
To satisfy my curiosity by double-clicking the image
The slider tells me it is set to 346x259 points
I complile
I double-click the ePUB
My Mac opens the application and the ‘view port’ as you call it is set to a the same size as it always opens at, it is not configurable.
The graphic is tiny.
I break open the ePUB and look at the code. It says 346x259 Pixels not points.
I edit that code to either say 100% or change the pixels to points or remove any mention of the size so that it defaults to the native, or embed the picture as a tag
I open the ePUB and it looks perfect.
How can you not see that there is an issue to solve here? Do you not see
If I perform the exact same test of any other ePUB creating program I can find, this problem does not exist. If the resulting code does not reflect what the GUI says then the GUI is wrong. Put it another way. Why does the GUI even bother displaying numbers in Points?
If Scrivener simply removes points in the GUI, your 300DPI image should still output 346x259 CSS px in the HTML, and that would still confuse you and other users… You say “If the resulting code does not reflect what the GUI says then the GUI is wrong”, the resulting code IS correct[1]!!! A CSS pixel states it is based on a 96DPI reference, and you use 300DPI metadata in the image, so a conversion must take place, you cannot avoid it unless you use a standard DPI image.
So what if the GUI said 346x259 CSS px, would that solve this confusion? For ereader users they would at least become aware that CSS and image pixels are not the same thing. But what about all the users that output to Word, or PDFs, or Markdown, or … — perhaps there should be a table of sizes for each possible compile format. I think this would be fascinating for me, but confusing for the users you are describing.
Or should Scrivener perhaps simply remove the 300DPI metadata to then make points and image pixels equivalent? That would have solved all this confusion, but then users may be angry that they think Scrivener is downsampling their 300DPI image to 72DPI (again to reiterate it wouldn’t be, DPI is just metadata).
The solution is to guide HTML and eBook output authors to percentages or other relative units, but this may still yield some confusion and the GUI still has to take the other compile formats that wouldn’t use % or another relative unit into account (what AmberV is discussing above). This is where IMO Scrivener needs to tweak the Scale image dialog.
AmberV: what about vh and vw units — these are relative to viewport width and height, easier to conceptualise than width+height (which is relative to the containing block)? What I don’t know is which, if any, ereaders support vh and vx?
[1] well, almost 
viewtopic.php?f=3&t=50135
I also checked the Amazon guidelines, and it isn’t very clearly written but it does not say images should be metadata tagged at 300DPI, just that (as AmberV pointed out) they should be designed with a 300PPI minimum in mind to yield an image dimension that supports that (that is not the same thing): kindlegen.s3.amazonaws.com/Amaz … elines.pdf (and it recommends CSS px for block images and em for inline images)
Excuse me if I am intruding, but I have been trying to follow this discussion from the start to learn about how to handle images when I in my next project will have to include a lot of them in the final ebook.
To understand all details I sat down and read a bit about dpi and ppi and image sizes and when you write…
… isn’t this where everything goes wrong, from the start? The initial digital image you have is 1080x1440 pixels, right? And that’s all. It has no dpi because it has no physical size. The info about dpi is information for a printer, if you decide to print it on paper. Or is the 1080x1440 something else?
Thanks for the detailed replies. Know I didn’t start this thread (apologies to Mick for intruding), but there is a lot here that, however arcane, helps to scrape away some of the fog from the mud.
I have never thought of Scrivener as being rooted in a print-based context. For me, it has been an agnostic writing studio that has handed over granular print/layout work to post-compile WYSIWYG tools: of its twenty compile formats, only print and PDF are end-point compiles. Need to reset my brain.
And having read nontroppo’s link above (Images DPI - #46 by nontroppo), I can see how difficult this whole issue is for tech savants, let alone end users, especially creative writers whose focus is on words, not recherché pixel-ology. We put (what we think is) a paperback-size cover with (what we think is) a good-quality DPI setting into a project and expect it to come out looking the same. Why it doesn’t, even if for the very best tech reasons of which we are stubbornly ignorant (that refers to me, not the OP), is white noise. We don’t really want to know how or why; we just want it to work – I have seen this frustration with writers/users I know online and offline. Anything that makes the process more intuitive or flexible would be very welcome.
As far as I understand things (and trying to create a simple rule of thumb that I can use going forward), if a user is outputting to an ebook format, it is best to prepare images at 72 DPI, although I don’t really get how that squares with Amazon’s 300 DPI requirement: if I tweak an image in Preview, it asks for a resolution, so doesn’t that figure need to be 300 DPI for Amazon? The dumbness of that question will undoubtably seem immense to those of you who are lucky enough to see both the wood and the trees.
And, to me, it still seems as though the image placeholder tag is the simplest way forward, because (1) it allows users to switch different images/resolutions in and out of final compiles, and (2) it allows users to use the ebook=xx% setting (which isn’t possible with an image imported into Scrivener?).
God, I love the smell of DPI in the morning.
As far as I understand it, the digital image has a pixel size, but no resolution whatsoever until the moment you print it on paper so you know what size those pixels are spread on.
The inch in DPI doesn’t exist until you present the image in a given physical size. Your computer screen has a size and a number of pixels and thus a resolution, but images that you display on a screen only have pixels and, therefore, their size will vary with the screen resolution.
Edit, addendum: And when you change the displayed image size in the editor, using the slider, the no. of pixels is constant but the dpi changes because you are actually giving it a physical size.
It’s a good point of interlude to briefly once again confirm that yes, 72 DPI sRGB graphics are what one should be using in digital publication for the screen (excluding PDF, which is a weird case of being a format built all around print fundamental but primarily used for digital distribution).
All of the above is therefore rumination on whether Scrivener should mitigate the use of incorrectly formatted graphics using a different system of measurement or algorithm for approximating what is ultimately a confusing request made of it, than it currently does.
So for someone looking for the best way to approach digital publishing and images, my advice from what I have observed and tested is:
- Use the above specifications as a starting point.
- Be prepared for the reality that you may need different images or different ways of expressing the sizes of those images for each vendor you target. Nontroppo posted a link to an article about the woes of that, and I can definitely corroborate, having worked with countless people over the years to get consistent looking results in Kobo, Apple, Kindle and Nook. There is no magic bullet. No single image that works everywhere perfectly. No method that solves everything. This is especially true with screen-width/height graphics, that’s where it gets really messy.
Fortunately, Scrivener makes that relatively simple. Image placeholders being text-based tokens can be modified by Replacements on the fly to target different graphics, adjust sizes, add ebook percentage-based instructions, etc. One can also use linked images and swap folders around on the disk if they prefer thumbnails in the editor to text tags. There are a lot options.
So here is how Scrivener works when using proper 72 DPI graphics (whether they be that way from the start of by using Scrivener’s tools to bring the size of the image down to that point):
- If the image exceeds 800x600 in either direction, then it assumes the best mode for displaying this image will be relatively. All size information will be replaced with “width:100%” as an inline CSS style.
- If neither edge of the image exceeds those limits, then Scrivener will not insert any size information with the image, allowing it to be displayed naturally and in accordance with the device’s preference, governing stylesheets, or to allow the user to target the image themselves in their own custom CSS.
So, if you go back to what the OP was reporting: we already support two of the methods they tested that work well. They also suggest substituting pixels for points, but I think we’ve provided adequate documentation to the fact that this would be a step backward, and no more reliable than using inches or picas.
Welllll, take it with a grain of salt. When I say it is rooted in print mechanics, I’m referring to how the internal mechanisms record lengths, how sizes are stipulated, etc. RTF is a format designed to describe printed material. Scrivener uses RTF to store its material, so by nature it refers to images as having fixed point widths, and it refers to fonts as having very precise physical sizes (as opposed to the more HTML-ish relative scaling), and so on. It means that, when it comes to expressing formats that are flexible or dynamic like ePub, a little interpretation is required, and we cannot always extract the most optimum information from the storage format (RTF).
This is all perhaps abstract in the sense that Scrivener isn’t a page layout or desktop publishing program. You aren’t typing on virtual sheets of paper into text boxes and so forth like you would be in InDesign. Saying it uses print mechanics to store data doesn’t mean much, until we get into very technical discussions over why an image uses points for its measurements.
But yeah this whole topic of image resolution baffles even professionals. 
Just do some searching for digital photography articles on DPI to see that even people that make a career out of handling graphics struggle with these principles. When I took design many years ago, we spent several days going over this topic and I don’t think everyone in the class ever fully understood dots per inch vs lines per inch versus dot pitch versus pixels per inch.
It’s a lot for a writer to take in—but if one is going to be self-publishing I’d say it’s just as valuable to learn the basics as HTML and CSS will be. One doesn’t need to become a guru, but knowing some bases like how 72 DPI is what browsers and ePub readers measure by is going to save one a lot of grief.
Yeah that’s confusing. As Nontroppo posted above however, Amazon doesn’t seem to specifically say they want graphics set to 300 DPI in their metadata. They are saying they want images with enough pixels for there to be 300 of them per inch when the image is displayed on a Kindle.
The distinction being: the image should have enough pixels that it could be 300 DPI at a defined width, but the actual metadata setting on the image should be 72 DPI. That setting is for print use only. The pixels are another matter entirely. So feel free to use the DPI settings in Photoshop to figure out the math of how many pixels you need, but when it comes to saving the image leave it set to 72.
As to that, see above. Scrivener has rules for how graphics are treated at 72 DPI and those rules tend to handle how people need images treated in eBooks for most cases. For other cases you can force the issue with CSS, or by using placeholder tags to stipulate a precise measurement or relative screen usage.
There is fundamentally no difference between image placeholders, linked images and embedded images once we get down to compile. By the time the engine is converting graphics to HTML—everything is technically embedded. All linked graphics will be fully imported into the working data at the sizes we stipulate. So don’t worry so much about that aspect of it.
What these different tools provide are benefits to our flexibility as users. Embedded are the least flexible but require less management. Linked to the binder are also low management but allow a little more flexibility. Linked to the file system requires care in managing ones resources around the project, but a lot of flexibility. Placeholders and Markdown usage not only provide that flexibility, but also allow compile settings to manipulate image presentation and selections on the fly, and Markdown users also get a wide latitude of presentation control.
The decision is entirely down to what you want and what you need as part of your workflow. Don’t make the decision or force yourself down a path strictly to appease the compiler. It doesn’t care which type of image you use—and so long as its optimised for the type of document you are compiling, the result should be fairly intuitive.
AmberV: I think a yellow highlight box with a distillation of this discussion would be a welcome addition to §15.6 of the user manual 8)
Thank you, Lunk and Ioa, for your detailed replies. I have read them both at least a dozen times.
For me, that’s the the crux of the issue: incorrectly formatted graphics. Most users I know don’t know what a correctly formatted graphic should be (in Scrivener or anywhere else) [1]. We plough ahead, usually with the assumption that the bigger the numbers (especially the DPI) the better. We should get to grips with the underlying concepts, but most people I know just want a few simple A-into-slot-B examples that they can copy or adapt.
Also, if someone out there in the wider world came up with a simple single measurement, life would be a lot easier.
Why, out of curiosity, 800x600 in particular?
Thanks again to all.
Bridey
[1] A lot of writers (or other people using Scrivener) even struggle with things like indents and tabs and line height and paragraph spacing and … and … and… so the wonderful world of images is a hurdle from another discipline and of another magnitude for them. In a perfect world, we’d all employ specialists to handle typography, image processing, editing, and publishing for us.
A capital plan!
Yeah, I’d have to research the compatibility of those units, but if it is commonly used then that could be more intuitive and less easy to confuse with other functions than percentages.
Oh, and I meant to address this and forgot to:
It is very likely that whatever you are referring to (Sigil, etc.) are not treating images for the print metadata in the least. They are discarding that information, so all they see is your 1080x image and they treat it as Scrivener would if you used 72 DPI with it. It’s apples and oranges really, for so many reasons.
That was the recommended size for full screen and cover image graphics for many years, as that is how big the most common eInk screens were until the resolution explosion took off. So it is safe to assume that any image larger than that is meant to be at least full width, or at least wouldn’t be harmed in presenting it that way. It could be at some point that is no longer a safe assumption, if resolution goes higher—but I wouldn’t be surprised if we’ve plateaued. eInk already has the resolution of a high quality laser print, and arguably nobody would benefit from it being much higher than it is.
Grateful to you, Ioa.
Can’t Scrivener do the same? Discard the print metadata or assume 72 DPI instead of the image’s existing DPI? Wouldn’t that solve the problem?
Absolutely, we could do that, but then we’d have people wondering why when they resized an image in the editor the compiled book outright ignores the size they selected and no matter what always uses the native size of the image—or why the image that looks okay in the editor balloons out to full screen when they compile.
I guess I was unclear.
… discard the metadata when one compiles to Epub format, like other softwares do.
That’s how I understood you, so it must be me that isn’t explaining this right. If the size of the image is discarded when you compile to ePub, then all there is to determine the size of an image is its raw pixels, which means an image will always be the same size coming out of Scrivener to these formats.
And to be clear, when I say an ePub creation program might be discarding the info, I mean it never reads it in the first place, only ever treats the image as pixels, and if it allows any kind of visual resizing at all, is going to be doing so with a simple floating point calculation on pixel dimensions directly. It is using the same technology that the reader or browser will be using, and so none of these complexities that Scrivener faces are relevant—hence apples and oranges.
And Scrivener can’t do the same, for some reason? Skip the oranges and go for apples like the others?