I am curious what happens if you do pull up the slider like you were and then generate the epub. Does it come out correct in that case-- that is, properly sized and not unduly pixellated? (Something would still seem amiss in Scriv, but it would be informative to know and you would also know that you could work around the bug in the meantime.)
-gr
P.s. Since the epub format is driven by css, it seems to me that any internal dpi marker there might be in the image file would be irrelevant.
I will make a minimal project and send. In answer to your last question, yes and that is at the heart of it. You all had to educate me before I finally presented my final suggestion of a bug. If I slide the slider so that the points = pixels (because I was too stupid to realize that it said points) then the issue is fixed in the sense that Scrivener incorrectly codes the points to pixels and those numbers are correct. In a sense the bug took it one way and my stupidity took it back the other way. This also explains the the amazing (not) coincidence that me misreading the word ‘points’ for ‘pixels’ just happened to make the image the intended size. I agree with your last point on CSS except I can prove that not to be the case. If I break open the Scrivener produced ePUB, edit the code with a tool like Sygil (or even just a text editor) by simply changing the XHTML then the images are correct. I achieve that by not touching any CSS. What is not clear to me is whether the image looses quality if I use the slider to pretend points=pixels. My illustrations are like pencil sketches, so they may not have enough texture to tell. I’ll make a project and send within the next few hours.
In my zip you will find an image ColorBurst.jpg. Photoshop and Preview both agree this is 1080x1440 and 300 DPI. Used Photoshop to create this from the MacBook Pro wall paper. You will also find my minimal project and the resultant ePUB that Scrivener made.
Here is how I made it.
New Project from “Novel with Parts”
Added the graphic to the Front Matter as a cover
I also added the graphics to the second scene of part 1, chapter 1. I centered it and reduced the left indent so that the image is truly centered.
I did not touch the slider and it correctly reports 1080x1440 pixels at 300 dpi. It also correctly reports 259 x 345 points. This is expected since multiplying those numbers by 1/72 inches gives a size of 3.6 inches by 4.8 inches which is the size of a Kindle PaperWhite which is what I want and why I start with 1080x1440 at 300 DPI.
Compile to ePUB3
However, the ePUB contains the file ‘body2.xhtml’ which contains the following incorrect line:
I must be doing something wrong, when I compile this is makes a folder with an ePUB inside but the file only shows the image from my original example but no second rendering of the image from your tag.
I’ll take a more thorough and proper look at this when I’m off break, but in general I do agree that using percentages is better for eBook publishing. If the image is meant to fill the screen, then 100% is the way to go. We do have a way of specifying width by percentages:
<$img:/path/to/image.jpg;w=259;ebook=100%>
I was going to point you to the user manual, but regrettably it looks like 3.0.1 was released without the 3.0.1 manual, so this capability is for the moment undocumented.
As to the default behaviour—I’m pretty sure the Mac works this way because when the RTF to HTML converter was implemented, nobody would have ever dreamed of putting a 300 DPI image into a Web page (and that would have been true even only a few years ago for eBooks as well), and at 72 DPI the output is correct. It only becomes incorrect when points cease to equal pixels.
At any rate, for screen display, em and % are better units of measurement than pixels or points. All of this is perhaps a good demonstration as to why. Generally we have an idea of how big the image should appear relative to the size of the display, so saying 45% or 100% is a fine way of doing so, so long as we have the pixels to back it up—and if an image is a decorative element meant to embellish or work with text as part of its design, then the em unit that scales with the reader’s font settings is preferable.
I realize I started all of this by going on about DPI (the title of this thread) but wasn’t I wrong about that? My current understanding is that this has nothing to do with DPI. It is down to Scrivener reading X points on the slider and coding X pixels in the code.
Well yes and no. The basic answer is that at 72 DPI Scrivener’s reckoning of a point coincides with the size of a pixel, and so if you save your image into the editor that way it will be the right size on the Kindle. The above advice to use the <$img…> placeholder to specify the image as 1080px is identical to dragging the slider down to 1080px. Both achieve the same result.
What you’re running into is a print-context typesetting engine exporting to HTML-based technology with a priority on visual similarity: i.e. hold your Paperwhite up beside the text editor and you should see the 300 DPI image in the editor is about the same as the downscaled image on the Kindle. That isn’t the result you really want however: you want a 1080px wide image—so use 72 DPI. It doesn’t really make sense, for points to be used as pixels, in a technical frame of mind, but from a “WYSIWYG” kind of: just make my blog look like it did in Scrivener, it’s the better result.
Amazon’s recommendation to use 300 DPI is confusing and ultimately meaningless. The Kindle is entirely unaware of the DPI of an image. I think what Amazon is trying to get across to people is that their images should have enough pixels to provide a density of 300 ppi within the desired display width. That however is a mathematical statement for determining how many pixels wide the image should be—not an edict for setting the print dimensions in Photoshop, Scrivener, Word or anything that works in a traditional typesetting context with regards to image scaling. Pay no need to its DPI—or rather, manipulate your use of DPI to achieve your desired end: in this case 72 DPI is your best answer for Web and eBook related technology.
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.
Generally we have an idea of how big the image should appear relative to the size of the display, so saying 45% or 100% is a fine way of doing so, so long as we have the pixels to back it up—and if an image is a decorative element meant to embellish or work with text as part of its design, then the em unit that scales with the reader’s font settings is preferable.
