Thu Jan 04, 2018 12:39 am Post
Thu Jan 04, 2018 1:57 am Post
Thu Jan 04, 2018 7:30 am Post
mickputley wrote:I take an image that is is 1080x1440 at 300 dpi
Thu Jan 04, 2018 12:22 pm Post
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).
Thu Jan 04, 2018 12:48 pm Post
Bridey wrote: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
Thu Jan 04, 2018 12:51 pm Post
Bridey wrote: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.
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, (1) because 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?).
Fri Jan 05, 2018 2:48 am Post
Fri Jan 05, 2018 8:25 am Post
AmberV wrote: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.
...
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.
Fri Jan 05, 2018 1:46 pm Post
nontroppo wrote: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
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?
mickputley wrote:If I perform the exact same test of any other ePUB creating program I can find, this problem does not exist.
Why, out of curiosity, 800x600 in particular?
Fri Jan 05, 2018 2:44 pm Post
AmberV wrote:mickputley wrote:If I perform the exact same test of any other ePUB creating program I can find, this problem does not exist.
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.
Fri Jan 05, 2018 3:08 pm Post
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?
Fri Jan 05, 2018 3:13 pm Post
Fri Jan 05, 2018 4:38 pm Post
Fri Jan 05, 2018 5:27 pm Post
In total there are 5 users online :: 0 registered, 0 hidden and 5 guests (based on users active over the past 5 minutes)
Most users ever online was 1048 on Mon Feb 06, 2012 9:07 pm
Users browsing this forum: No registered users and 5 guests