I don’t believe I agree. When I paste a picture into Scrivener and the slider says 346 x 259 points it codes 346 x 259 pixels. That is an error. The fact that I manifest the error by using a 300 dpi document shouldn’t matter.
Forget what I mentioned about the Kindle. I am only using that as an example because I want to maintain one ePUB formats and not two. Amazon advises to publish by injecting ePUBs into their system not Mobi (although I confess they often change their mind). But never mind that. When Scrivener codes the picture at 346 x 259 pixels it is not doing what it said it will do. The bottom line is - it looks tiny because the code is wrong. I really would like this fixed, I appreciate the work-arounds but If I wanted to write code I’d be using InDesign or Sigil or something else. I really want to use Scrivener’s excellent features including the WYSIWYG aspects.
Sorry, I don’t quite know what you are looking for then. The engine already works on a WYSIWYG framework, where an image about the size of a business card in the text editor comes out about the size of a business card on a Kindle/iBook/Webpage/etc. Just like it does in a PDF, or Word.
What you seem to be asking for is something other than that, where an image the size of a business card blows up to be the size of a postcard (how it knows that’s what you want, I don’t know). You can have that happen, but one needs to set the image to 72 DPI which will make it work in a more expected fashion with Web-based technology. No “code” necessary.
As I said, technically Scrivener’s use of points in a pixel field is inaccurate, but it achieves a consistent look (at least, as much as one can expect across different displays). That’s the reasoning—and if we changed that (assuming we even can, again I think this is how the text engine works) I’m sure we’d get nothing but complaints if the stuff that came out of the HTML/eBook format looked on average three to five times larger than in the editor.
What I am looking for is for Scrivener to honor the setting on the slider. Right now it does not. I ask for so many points and I get pixels instead. What you seem to be telling me is that I have to change my DPI to compensate for the bug. Here is an example of the issue. When I open an ePub on a Mac, the application open the page at about 6.5 inches x 5 inches. A 72 dpi image looks significantly inferior to a 300 dpi image, I do not want to compensate for incorrect code by changing my DPI, I just want it to do what it says it is going to do which, by the way, every other product I have tried works.
As for keeping a bug because people are used to it… L&L are pretty much telling us that we have to re-learn the product for version 3. What a perfect opportunity to fix this.
An image the size of a business card blows up to be the size of a postcard
I am not asking for that. My image correctly displayed in photoshop at 100% is the size of an ebook page. When I open the page on the ebook reader it is tiny. We seem to be so far off the same page I attach a screenshot.
“(how it knows that’s what you want, I don’t know).”
It knows what I want because I tell it using the slider
“No code is necessary”
It is the Scrivener code the is specifically telling the reader to take the number of points I specify and wrongly specify that as pixels.
That’s how it is intended to work. The above is not a bug.
If you want what is on the right side of the screen to end up being as large as what is in Photoshop (postcard), then you have been given the simple answer for how to achieve that result—and it involves making the left side of the screen look that way too.
As for your iBook window, all that demonstrates is that the image is smaller than the viewport you’ve created for it, which probably has more to do with the fact that the image was optimised for a small Paperwhite screen, originally. DPI is not used by any technology that displays eBooks. The metadata that is used to calculate the DPI is not used.
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.
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:
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):
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
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.
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:
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.
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.
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 mayfeel 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:
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.
