Images DPI

User avatar
AmberV
Posts: 23699
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Ourense, Galiza
Contact:

Fri Jan 05, 2018 5:45 pm Post

Well maybe I don’t understand then. For Scrivener to do the same it would become an HTML editor.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
lunk
Posts: 3628
Joined: Wed Aug 21, 2013 4:24 pm
Platform: Mac + iOS
Location: Sweden 64° N

Fri Jan 05, 2018 6:32 pm Post

You say that..

AmberV wrote: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 when we compile to epub, i.e. use Scrivener as "an ePub creation program", as you phrase it, why can't Scrivener behave like one and when it "allows - - visual resizing - -, is going to be doing so with a simple floating point calculation on pixel dimensions directly" and hence use "the same technology that the reader or browser will be using"?

AmberV wrote:For Scrivener to do the same it would become an HTML editor.


This must be where I don't understand.Isn't Scrivener in a sense an HTML editor when it compiles an epub?
I am a user, writing non-fiction and science, using:
* Mac Scrivener 3 on a Macbook 12”, MacBook Pro 13”, and iMac 27”, all running the latest MacOS
* iOS Scrivener 1 on an iPhone 8, iPad Air 9.7”, and iPad Pro 12.9”, all running the latest iOS

mi
mickputley
Posts: 37
Joined: Sat Dec 23, 2017 1:13 am
Platform: Mac

Sat Jan 06, 2018 7:25 am Post

Hey I'm done. I'll let you guys carry on. We are obviously not going to convince each other. You think that it is OK for the GUI to say 346 x 259 *points* and produce compiled code that says 346 x 259 *pixels*. I think that is wrong. You think that other compilers are wrong for coding 346 x 259 *points* to an HTML statement that says 346 x 259 *points*. Please excuse me while I step out of this debate, You have surrounded this discussion in the deepest detailed science around CSS, Typesetting, DPI etc. If you cannot acknowledge that the GUI is not doing what it displays, then I cannot spend anymore time on this. Never before have I felt so unable to form an agreement with someone on such a basic point. I have my work around, the GUI can be ignored. I regret that so many people have spend so much time on the detailed analysis of this subject and not been able to agree that Scrivener does not produce code that honors what the GUI says. I will post no further comment on this subject. You guys carry on the madness if you wish

User avatar
lunk
Posts: 3628
Joined: Wed Aug 21, 2013 4:24 pm
Platform: Mac + iOS
Location: Sweden 64° N

Sat Jan 06, 2018 8:48 am Post

I don’t think it’s madness. My guess there is some fundamental core principle that is so obvious to each one of us that we don’t realise that it exists, or that others don’t see it the same way.

My core principles:
For printing on paper, images must have a physical size.
For displaing in an epub reader, images need a relative size, relative to the size of the reader.
When writing in Scrivener I should be able to size images the way I want, without it having an effect on how they appear when I compile, because in Scrivener writing and compiling are two separate things and the way it looks in one doesn’t affect the other.

To me it seems that AmberV for some reason doesn’t see it this way.

So where do I fail to understand?
I am a user, writing non-fiction and science, using:
* Mac Scrivener 3 on a Macbook 12”, MacBook Pro 13”, and iMac 27”, all running the latest MacOS
* iOS Scrivener 1 on an iPhone 8, iPad Air 9.7”, and iPad Pro 12.9”, all running the latest iOS

mi
mickputley
Posts: 37
Joined: Sat Dec 23, 2017 1:13 am
Platform: Mac

Sat Jan 06, 2018 9:29 am Post

Like I said, you can discuss endlessly the science of this. The compiled code does not honor the setting in the GUI, this whole lengthy and painful conversation seems like smoke and mirrors. If I use any other EPub creator and specify that an image is X pixels I get X pixels, if I specify 100% I get 100%, if I specify X Ems I get X Ems. In Scrivener if the slider says X points I get X pixels. That is just wrong.

User avatar
AmberV
Posts: 23699
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Ourense, Galiza
Contact:

Sat Jan 06, 2018 12:37 pm Post

This must be where I don’t understand.Isn’t Scrivener in a sense an HTML editor when it compiles an epub?

That would be a pretty loose interpretation. It is an RTF editor that calls upon a system library to convert RTF → HTML, or upon MultiMarkdown to generate HTML5 for ePub 3 / KF8. But that’s almost beside the point, what really matters is that in RTF an image is stored, displayed and has its size changed purely through manipulation of the image’s print settings, settings that are invisible (discarded, as I perhaps confusingly put it before) to actual HTML editors and viewers (from the very start to the very end). When you change the size of an image in Scrivener, it does not use pixels to do so, it strictly adjusts the print width/height setting.

When you compile, it uses these print settings to derive the number of pixels the image should be displayed at. It does this by calculating off of the visual size provided by the user’s adjustment of the image’s print settings. Go back a bit and look at my screenshot of how the result in iBooks is identical to the original image in the editor—that’s it working the way it should be, and if Calibre had a slider and you used it to make the image that small in its editor, you would get the same result in pixels I’m sure.

So in a roundabout way, it does do what you are saying: the image is ultimately adjusted via pixels and its final size is expressed in the correct number of pixels it takes to display the image at the requested size (which might not be the expected size thanks to differences in screen display technology—but that’s why we should not use print settings for ePublishing in the first place, and why all of this is, as I referred to earlier, mitigation).

When writing in Scrivener I should be able to size images the way I want, without it having an effect on how they appear when I compile, because in Scrivener writing and compiling are two separate things and the way it looks in one doesn’t affect the other.

Well that on that point I would agree! :) Unfortunately that’s not how it works however. In fact I wrote a post-processing script that strips all of Scrivener’s resizing information out of the MultiMarkdown file because I don’t care one bit how big the image is in the editor. I only change that to make it convenient for how I work.

But—that’s not how it is programmed to work and that is I don’t think how most people would expect it to work. I am positive most people think that the image they see in the editor is representative of how it will print or be displayed on the screen, and so in every method that Scrivener produces images into the output—even to formats like LaTeX—it strives to replicate the editor settings.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
lunk
Posts: 3628
Joined: Wed Aug 21, 2013 4:24 pm
Platform: Mac + iOS
Location: Sweden 64° N

Sat Jan 06, 2018 1:21 pm Post

AmberV wrote:
I am positive most people think that the image they see in the editor is representative of how it will print or be displayed on the screen, and so in every method that Scrivener produces images into the output—even to formats like LaTeX—it strives to replicate the editor settings.


I think this is the crux of the matter, because this means that if one alternate between different platforms and screen sizes (I run Scrivener on a 27" iMac, a 12" Macbook, a big iPad Pro and an iPhone 8) and resize one image on one device, another image on another device, and so on, the output will be completely screwed up because Scrivener strives "to replicate the editor settings".

I think the initial assumption, that "most people think that the image they see in the editor is representative of how it will print or be displayed on the screen", is both correct and incorrect. Most newbies think that is the way the editor should work for text because they are used to wysiwyg editors like Word, so for newbies the assumption is correct. But sooner or later they understand that the text in the editor is one thing and the compiled output something else, and by then they have understood that Scrivener is NOT a wysiwyg editor and hence the compiled output does NOT reflect how things look in the editor (unless you explicitly tell the compiler to compile 'as-is'). At that point the initial assumption becomes totally illogical and incorrect, and creates confusion.

I think KB should really think a bit about this. Scrivener can't be a wysiwyg editor for images when it isn't for the text.
I am a user, writing non-fiction and science, using:
* Mac Scrivener 3 on a Macbook 12”, MacBook Pro 13”, and iMac 27”, all running the latest MacOS
* iOS Scrivener 1 on an iPhone 8, iPad Air 9.7”, and iPad Pro 12.9”, all running the latest iOS

User avatar
AmberV
Posts: 23699
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Ourense, Galiza
Contact:

Sat Jan 06, 2018 2:07 pm Post

Well, I think at this point you’re talking about something entirely different than the OP though. They don’t agree with how Scrivener measures images, but they obviously rather strongly want those numbers used for something rather than ignored entirely!

But yes, for ePublishing specifically, the problems you point out with using fixed units of measurement like points and inches is that these things are visually different depending on the device. That is why a general statement of “75% of the virtual page” is usually going to be a better approach. Go for it—you have the tools available to do that.

Something like you’re talking about is probably better put as a new feature request—I’d suggest a checkbox because ignoring image size definitely shouldn’t be default behaviour!
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
lunk
Posts: 3628
Joined: Wed Aug 21, 2013 4:24 pm
Platform: Mac + iOS
Location: Sweden 64° N

Sat Jan 06, 2018 2:41 pm Post

AmberV wrote:Something like you’re talking about is probably better put as a new feature request—I’d suggest a checkbox because ignoring image size definitely shouldn’t be default behaviour!


Maybe the whole thread can be summarized as: Using images is tricky because there is no general simple solution that fits all alternative outputs. :)
I am a user, writing non-fiction and science, using:
* Mac Scrivener 3 on a Macbook 12”, MacBook Pro 13”, and iMac 27”, all running the latest MacOS
* iOS Scrivener 1 on an iPhone 8, iPad Air 9.7”, and iPad Pro 12.9”, all running the latest iOS

User avatar
devinganger
Posts: 1717
Joined: Sat Nov 06, 2010 1:55 pm
Platform: Mac, Win + iOS
Location: Monroe, WA 98272 (CN97au)
Contact:

Sun Jan 07, 2018 5:03 am Post

AmberV wrote:Well, I think at this point you’re talking about something entirely different than the OP though. They don’t agree with how Scrivener measures images, but they obviously rather strongly want those numbers used for something rather than ignored entirely!


I'm been following the discussion without really *following* it (if you know what I mean) as I haven't used Scriv to embed images yet, however that's not entirely tracking with my understanding of the OP's complaint. They're complaining about the *unit labelling* of the numbers (e.g. it says they're points when they're not) -- and surely, if that's the case, that's a valid complaint?

I mean, I get that it's complex and there are multiple ways to do things, but if there is behavior that is objectively wrong, that should still qualify as a bug, yes? Even if in this case it is wrong because Scrivener is assuming 72DPI which is the magic point where pixels = points...isn't the fix simply to change the label?
--
Devin L. Ganger, WA7DLG
Not a L&L employee; opinions are those of my cat
Winner "Best in Class", 2018 My First Supervillain Photo Shoot

User avatar
Bridey
Posts: 390
Joined: Wed Nov 22, 2017 2:24 pm
Platform: Mac

Sun Jan 07, 2018 9:00 am Post

...but, but, but, but the points are accurate/carried through in other compiles. If the unit labelling was changed to pixels, wouldn't it then be "wrong" in those other compiles?

Points.jpg
Points.jpg (249.31 KiB) Viewed 1281 times

User avatar
Bridey
Posts: 390
Joined: Wed Nov 22, 2017 2:24 pm
Platform: Mac

Sun Jan 07, 2018 10:12 am Post

This is interesting...

KB wrote:I'm not doing any conversion for px when adding image sizes to epub etc, just using Apple's image size width and height. Essentially, if the pixel width/height of the image does not match the points width/height, then Scrivener knows the image uses a non-72 DPI and then adds the point width/height as the pixel height/width for the HTML. i.e.:

Code: Select all

if (img.pixelsWide != img.pointsWide || img.pixelsHigh != img.pointsWide)
... include "w=[img.pointsWide]px" etc.


viewtopic.php?p=257039#p257039

User avatar
AmberV
Posts: 23699
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Ourense, Galiza
Contact:

Sun Jan 07, 2018 10:15 am Post

It would all perhaps be less confusing if CSS used a different word for its unit of measurement here, like ponies, instead of pixels (which aren’t the same as pixels in a raster). If we compiled and got an image 246 ponies wide, some people might giggle, but I think we’d all better understand it is a conversion to a different display system meant to produce a visually similar result from the source. :)

As noted in this thread over here, there is a good point in that Scrivener may be using the wrong (PostScript vs CSS) conversion formula for converting print sizes to HTML sizes, but even with that tweak made to the software, the confusion above would still exist. After all the UI will now state the image is 1080 pixels wide, 249 points wide and then export the graphic to 346px in the CSS. Is that more or less confusing than 249px?

Yeah, I like ponies better I think.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
Bridey
Posts: 390
Joined: Wed Nov 22, 2017 2:24 pm
Platform: Mac

Sun Jan 07, 2018 10:19 am Post

You know what a pony (and trap) is in Cockney slang? :shock:

User avatar
devinganger
Posts: 1717
Joined: Sat Nov 06, 2010 1:55 pm
Platform: Mac, Win + iOS
Location: Monroe, WA 98272 (CN97au)
Contact:

Sun Jan 07, 2018 10:32 am Post

So why not say "CSS pixels" -- which seems to be the most accurate term for now and is specific enough that "pixels vs. CSS pixels" could be a FAQ entry -- and make it clear that the DPI stuff is distraction? Using "points" when that is not accurate to all compile targets (and if I understand correctly, this setting is there long before Scrivener knows which compile target is going to be used) is misleading.
--
Devin L. Ganger, WA7DLG
Not a L&L employee; opinions are those of my cat
Winner "Best in Class", 2018 My First Supervillain Photo Shoot