I am disappointed by your increasing sarcastic tone and would like this issue escalated. Of course it is a bug, I am specifying a number of points in the slider and Scrivener is coding the HTML as pixels instead of points. Everything else is smoke and mirrors.
My support experience has damaged my opinion of this product, I have moved from elation to frustration and disappointment.
I would appreciate communicating with your supervisor or a developer.
Ioa, this is genuine ignorance and a desire to learn, not an attempt to inflame.
What goes in, as far as I see it, is a paperback-size image. What comes out is something much smaller. It doesn’t look like a front cover from a book, filling one whole page.
This is emphasised by the fact that if we leave the image outside of Scrivener and compile using a placeholder tag, it still looks like a paperback-size image (see post above: Images DPI - #16 by Bridey).
I understand about using the placeholder image tag and setting the ebook percentage, but is it possible to achieve the same 100% if the user drags an image in from the binder within Scrivener?
I’ve long struggled when working with imported images that I can actually see in Scrivener, though appreciate that it isn’t a layout/image program. They always look smaller than the originals outside of Scrivener, which is partly why I have defaulted to using placeholder tags: the compiled images look more like they do in Photos or Preview etc.
Very confused…
FYI, Ioa is head of support. Keith is the only Mac developer (and founder).
The mapping between points and pixels (and physical pixels and CSS px units) is not straight forward!!! There are several intents at play — especially when different devices deal with multi-resolution displays differently. Once upon a time, we had a simple rule. 1 inch is 72 points, and mosts screens used an broadly equivalent resolution so 72 (or otherwise 96) physical pixels was also roughly 1 inch. Now we have retina displays, 300DPI ereaders and the like and the question is the pixel does not mean what we used to mean by it. On the Mac, with retina displays, a pixel is actually not a pixel, but 4 pixels (2X and 2Y), and when it tells you the resolution width is 1800 it really uses 3600 display pixels and scales back to make things the same size as if it was 1800 traditional pixels on a 72dpi device.
So the pixel is a relative measure that tries to follow the general intent. Here is what W3 the organisation that maintains HTML and CSS that EPubs are made from has to say:
w3.org/Style/Examples/007/units.en.html
Clear as mud. They go on to clarify:
So pixels in CSS are not equivalent to image pixels, but the intent to display. If you have a 300DPI image then you have to recalculate the CSS px values to follow the intent of the 300DPI. That is what I think Scrivener is doing, it is saying display a 900x1300 physical pixel image with a 300DPI resolution (screenshot below) to yields an equivalent CSS reference pixel of 216 x 312px [ 300/72 = 4.16 → 900 / 4.16 = 216]
You cannot simply treat a CSS pixel as a physical pixel, otherwise each device may show an image at a different size (because they also treat physical pixels differently). That is why this is not a bug, and what I think Ioa was trying to convey.
postscript: the dry definition of the CSS reference pixel is here (assumes 96dpi to yield a size of 0.75pt):
Ouch. Brain needs to work too hard.
So if a user wants to display an image at 100%, they can use the placeholder tag and the ebook=100% setting but keep the original file outside of Scrivener, but once inside Scrivener it is restricted to a reduced pixel-defined output?
Mick’s original image is 1080x1440 pixels. When output, it is height:346px;width:259px.
I just don’t understand why it gets changed. If it goes in with a set pixel size, why isn’t that size maintained? 1080x1440 pixels in and 1080x1440 pixels out. (If your post above explains the answer, I apologise for asking again. I just don’t get why outside of Scrivener it can be one thing, but inside it is something else.)
It doesn’t get changed!!! - in my test I added a 900x1300 300DPI image to Scrivener’s binder, then drag it into a document, then compile it to EPub3 and in the EPub ZIP file the image is still a a 900x1300 300DPI image. Scrivener is NOT changing any images (at least not for this workflow). It utilises CSS reference pixel values in the HTML to size it to retain the 300DPI intent.
Again the image is not changed, the CSS is simply saying that to display a 300DPI image using CSS reference pixels it need to apply the maths [300/72 = 4.16 | 1080 / 4.16 = 259][1], the image is unchanged (and because it is actually still 1080physical pixels, will display with a higher visible resolution). It is an incorrect assumption to expect a physical pixel to always equal a reference pixel. Mick should just remove the 300DPI metadata from his images, and stop worrying about pixels and start thinking about the final goal.
Use Percentages for ereaders is what seems to be the simplest solution. If the image looks low resolution, increase the size of the source image and keep the percentage the same.
[1] I would argue Scrivener is actually applying wrong maths because the reference pixel in CSS is not 1pt but 0.75pt (as it is based on a 96dpi reference) so it should be 300/96=3.125 → 1080/3.125 = 346
Thank you.
I need to digest.
Understand all the words, but not why images inside and outside of Scrivener are treated differently. The same image dragged into Scrivener looks smaller than the same image compiled from outside Scrivener. If a user wants to display an image at 100%, we know it will scale to 100% of what is available on the reader’s device: it won’t overlap any boundaries…it remains fluid. I don’t get why Scrivener doesn’t just output a percentage (or have that as an option) for images dragged into projects. Few people would want their ebook cover crunched down to a third of its original size.
I’m happy as I use placeholder tags. I know that other Scrivener users are similarly perplexed by what happens to their images once inside Scrivener. I advise people to use placeholder tags or or manage images post-compile, but I would still like to understand as much as I possibly can.
If your image is 72DPI, it will look the same in Scrivener’s binder as it does in macOS Preview:
The problem is if you start trying to use DPI, thinking it is doing something it is not. Preview does not scale images to take DPI into account, nor does an image editor like Pixelmator because they are physical pixel based, so they both will look different to Scrivener. But look what happens in Microsoft Word 2016 when I drag in my 300dpi (top) and 72dpi (bottom) image (remember this is the SAME 900x1300px image, only the DPI metadata is different), Word is doing eactly what Scrivener does, read the 300dpi metadata tag and size the image to respect that intent:
I think I agree that allowing to have Scrivener’s “Scale Image” dialog to work in percentages may make some sense, but consider that the width in scrivener is not a hard value, it depends on the writing mode (page view etc) you are in and your editor width settings — Scrivener must appeal to both the editing side and the compile side. And each output format the % will mean something different! But for ebook users having a % entry would at least bring parity with the recent addition to the placeholder syntax…
Sorry I’m clueless as the whole antagonistic undertone from the posts a bit ago. It seems there is some reading into the tone here that certainly wasn’t intended. I’m not inclined to get in a tussle over it however. As noted you are alas already speaking with “the super”, and I don’t think anyone else on our tech support staff has extensive experience in graphic design—at least I’m always the one that gets deferred to for questions of this nature.
Hopefully you manage to find the best way to use Scrivener from someone else then, if you’d rather not work with me.
⠂─────── ⟢⟡⟣ ─────── ⠂
That’s a good question! Think in terms of relative sizing and whether or not the image is in fact the right or wrong size in context with the other elements in the editor. Here is a simple test demonstrating what I mean:
Drop the example ColorBurst image into an editor. We know from the numbers that it is set to display 259pts wide.
Set your font to Courier (or any perfectly 10 pitch font) and create a number scale along the bottom of the image. You will be able to fit 36 characters along the bottom of the image. A 10 pitch font means that 10 characters will fit within an inch. Thus our 36 character “ruler” correlates with the known fact that 259pts = 3.6". The image is perfectly sized within the context of the text.
All right, so the contention is that the image is larger in Photoshop than in Scrivener. So let’s test that. Do the same exact thing in Photoshop with the 12pt font along the bottom of the image. You should get the same result: 36 characters in a 10 pitch font = 3.6", just as the image is set to print.
So why is the image larger in Photoshop? There is a very simple answer to that which should probably be more obvious now that you have the same exact text typed into two different places using the same exact metrics: the font in Photoshop looks about twice as large.
The answer is that tool in the lower left hand corner of Scrivener’s editor, which in the screenshot shows “100%”. Try setting that to 210% and then see how things compare to editors, like Preview and Photoshop, that display the image bereft of any typesetting or page layout style factors. Why 210? I don’t know, that seems to be the factor by which macOS considers native scaling vs the literal pixel weight it takes to construct fonts and pictures at a certain scale. It’s not displaying a 12pt font at its literal size using the pixels of your display to do so—it is scaling it to create a useful balance.
So that’s why a postcard sized image looks a bit smaller in Scrivener—it is still postcard sized, and if you blow up the magnification of the editor so that the text and layout matches a sheet of A4, you will see that it is the correct size—you’re just zoomed out by default. 
Yes. That is what I mentioned above when I said that using 72 DPI images and leaving the slider alone—or using the slider to set the image to 72, has the same exact effect as using a placeholder and stipulating the width of the image to its raster size. Both will be detected by the software as “native size”, and result in 100% being used in the eBook output automatically. Here is the HTML one gets when using the slider to correct the image’s settings back to screen-optimsed 72 DPI:
<div><img src="images/ColorBurst1.jpg" alt="" id="colorburst1" style="width:100%;" /></div>
Hence, one doesn’t need “code” if they don’t want it. That isn’t sarcasm.
Yeah there are a lot of problems with percentages being based on the sliders. I think a better approach is probably more in line with how the placeholder works: you still have static measurements (the slider) because that is how the text engine is designed, but you can override that for contexts where it makes sense to do so with a separate setting.
It’s a bit difficult to convey precisely what the means in a short UI label though. You’d have to somehow convey that the percentage only applies to dynamic viewports like eReaders, that it has nothing to do with the appearance of the image in the editor, will be ignored when compiling to PDF, and isn’t actually a modification or scaling of the image itself, but rather a declaration of how much of the relative viewer space available the image should occupy. I.e. it’s not “display the image at 50% scale”, it’s use 50% of the viewer to display this image—which might in some cases be magnifying the image by several thousand percentage points, if we have it blown up on a 16 x 16 monitor grid at a convention centre wall.
Whew.
Yes, explaining the intent is tricky indeed! As we’ve seen with pixels, it is easy to jump to conclusions based on false assumptions due to a technically complex space. How about: “EBook device width override [ 75% ]”, or just short circuit this and directly say “CSS width override for EBooks [ 50% ]”, it is up to the user to understand what CSS width actually specifies.
Using technical language might indeed be the best approach if the capability is elevated to the UI. It might also be better to have a toggle between “%” and “em” after the numerical entry field. For things like dividers and fancy capitals, you’d want the image to scale with the layout.
The question is whether having a technical setting off in a panel like that is a worthwhile code expense over the placeholder stuff. Would the original confusion have been resolved by such an approach, and would a hypothetical individual adverse to working directly with the technical underpinnings of an eBook be inclined to self-resolve point/pixel/DPI/screen/print/ppi/resolution madness via that approach?
Hmm, maybe breaking the panel up between print settings and digital settings too.
Anyway, in the words of Dante. 
I give up. You clearly feel that when I set the slider to state 346x259 POINTS I have an unreasonable assumption that the code Scrivener produces would state 346x259 POINTS instead of 346x259 PIXELS. If we cannot get on the same page about that, then this conversation isn’t really going to go much further.
Mick, it is not what we may feel that matters, it is the specifications of the output medium that define this. Points are not used or generally recommended to set image sizes, but CSS pixels are:
w3.org/Style/Examples/007/units.en.html
A pixel in CSS is NOT an image pixel, they are not the same thing. You have not understood that 100px in CSS can actually contain 1000px worth of image data.
Why not just remove the 300DPI metadata from your images, you do not lose any image quality, and then the correct translation Scrivener makes will match your feelings that a pixel in CSS is the same as an image pixel.
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):
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)