macOS Sonoma + Latest Scrivener (which is random crashing quite a bit, but I can’t pin down a cause, often when changing a setting)
You might want to try saving your preferences as a preset and do a full .prefs file reset. It could be something got messed up in the upgrade. A messed up setting could cause a problem either when changing the .prefs file or when accessing a piece of interface using that setting.
Okay, I see what is going on. If you look at the RTF file itself in a text editor, you’ll see that the linked image is referenced along with its display size, which is stipulated in points. So the PNG for example is 595pts wide, but at 400 DPI the pixel width is 3308. Thus given the data it has to work with, it appears “resized”, even though you haven’t touched it.
My testing was done with screenshots, which use the native resolution where points = pixels, and so that is how I got the result I did. So from this the current implementation is a bit limited in that it only works with screen resolution graphics. I think this could be generally improved by having the compiler’s reckoning of an image’s scale be determined by the same algorithm that generates its display size into the RTF code. That should be a more accurate understanding of whether the display data in Scrivener is representing the display metadata for the image itself on the disk (binder or direct link). I think that’s probably an easy enough tweak, and it doesn’t involving changing how the image is stored or anything.
But, for now post-processing remains the answer on that score.
Units in Output
Do you think it might be a good idea for us to be more literal with what we are putting as size data into the Pandoc output, as we do for MMD? From the reading of the documentation, it seemed like it would be effectively treated correctly to let it handle things with fallbacks, but since it is using 96DPI as a base for pixel conversion to print measurements, that isn’t so good.
Here is a test I ran:
{width=595 height=233}
{width=595pt height=233pt}
LaTeX output:
\begin{figure}
\centering
\includegraphics{400dpi.png}
\caption{400 unsized exampe}
\end{figure}
\begin{figure}
\centering
\includegraphics[width=6.19792in,height=2.42708in]{400dpi.png}
\caption{400 scaled example}
\end{figure}
\begin{figure}
\centering
\includegraphics[width=8.26389in,height=3.23611in]{400dpi.png}
\caption{400 points}
\end{figure}
When the unit is stipulated as points, we get an accurate conversion of how wide 595pts are on paper. Which is of course the intention behind Scrivener using that number.
But, on the other hand, when I convert to HTML, the use of points as units causes it to convert to the same inch measurements, which are not recommended in CSS.
So the other solution is for us to add --dpi 72 to the internal command lines, which causes “595” to equate to 8.3in without having to stipulate a unit. In the above example if I add that to the conversion command, both the second and third images come out correctly, in LaTeX and DOCX.
That doesn’t help people using the Processing pane, and having to somehow know that they should almost always use that because of how Scrivener works. I could certainly add it to the “Basic Pandoc” compile format starter, which would help. And I guess we could maybe add it into an empty arguments field when the Pandoc Syntax checkbox is enabled. Maybe that’s good enough?
In your experience, is that a good solution though? From my testing it looks safe, and is producing the right results.