Images and intrinsic sizes
26 views
Skip to first unread message
Andrew Scholer
May 19, 2025, 2:47:54 PM5/19/25
to prete...@googlegroups.com
Currently if you add an image but do not specify a width, it is set to 100%. I think there needs to be a way to render images at their native size instead of guessing at a width that will render them appropriately.
The current options become particularly frustrating when there are multiple images that are different size but both have comparable elements (especially text) that should be rendered at the same size. Below is an example of what I mean (orange added to show bounds of images). It looks odd if the text in the two images is different sizes because the first image is stretched to the same size as the second one.
To fix this, I currently am left to manually fiddle with the % width until I get similar sizes. Even then, I may be doing an awkward size scale (31%) that doesn't produce exactly the right final pixel size and thus ends up with slightly blurry details. (Even an SVG doesn't look great if the details end up scaled to non-integer widths).
To fix this, I currently am left to manually fiddle with the % width until I get similar sizes. Even then, I may be doing an awkward size scale (31%) that doesn't produce exactly the right final pixel size and thus ends up with slightly blurry details. (Even an SVG doesn't look great if the details end up scaled to non-integer widths).
What about an image@width="intrinsic" that omits creating the % width? The max-width would be constrained to 100% to allow graceful embedding in things like sidebysides. But there would be no size forced on them other than that cap. Left/right margins would be forcibly simplified to 0 or auto and default to auto.
For print output, I see table already has some latex to resize down if necessary but not resize up. Perhaps the same trick could be applied for images with instrinsic width?
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
David Austin
May 19, 2025, 4:43:53 PM5/19/25
to prete...@googlegroups.com
I support this feature. PreFigure makes math labels with MathJax, and ideally the labels would be the same size as in the surrounding text. I believe that Andrew's suggestion would make this easier.
David
--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N8DL7V24WzA1N1wX0OO52xS3s4MVg2Bbppgza4iEeZ1HA%40mail.gmail.com.
Andrew Scholer
May 20, 2025, 2:15:05 PM5/20/25
to prete...@googlegroups.com
Should intrinsic size be the default? Given that the native behavior of adding an image to an HTML page or LaTeX document is to display the image at its native size, is that what authoring an <image> with no width should do?
It looks like there is a $docinfo/defaults/image-width that authors could use to specify either "native" or "100%". But, to me at least, it feels like the out of the box experience should be native.
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CANXmVMBrdunSY3u9Mx4599K-xoo_9C2%2B3XeN-jKh6mvGU05%2Bdg%40mail.gmail.com.
Enrique Acosta
May 20, 2025, 4:18:38 PM5/20/25
to prete...@googlegroups.com
I also support this feature. Being able to have consistency of comparable elements between figs seems to be a very good feature. I also agree with Andrew that having the option to set this as the default behaviour would be very useful.
I currently "hack" my way to get Pretext outputs to do this native image sizing by not adding @width specifications and overriding the 100% width as follows:
For HTML, use a custom css that redefines the img tag styles with:
width: unset;
max-width: 100%;
height: auto;
width: unset;
max-width: 100%;
height: auto;
and then have the project file load that extra css.
For LaTeX, adjust the output .tex file by:
* Loading \usepackage[export]{adjustbox}
* Replacing all \includegraphics[width=\linewidth] with \includegraphics[max width=\linewidth]
(the adjustbox package is what enables includegraphics to have the option "max width", which reproduces the same behaviour as the CSS max-width: 100%)
Happy to share more details if at all useful.
Enrique
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N_QpGySKNzR4hMtiKL%2BV3ZTvE3%2B_v1btR%3DYb7HHfBRCBg%40mail.gmail.com.
David Austin
May 21, 2025, 7:51:30 AM5/21/25
to prete...@googlegroups.com
Yes, it feels to me like this should be the default when a @width attribute is not given.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N_QpGySKNzR4hMtiKL%2BV3ZTvE3%2B_v1btR%3DYb7HHfBRCBg%40mail.gmail.com.
Rob Beezer
May 21, 2025, 11:22:33 AM5/21/25
to prete...@googlegroups.com
(Small troubles with my email, this was sent yesterday.)
My first reaction to Andrew's post is to suggest this is an HTML-centric view of
PreTeXt source. But Enrique's LateX example gives me pause.
@Enrique - your LaTeX code presumes each image has a size in physical units
(inckes, points, etc). No?
We use PDF, PNG, SVG, and JPEG. At least. Sometimes they are converted from
one format (which we generate from source) into other formats.
PDF, with its page orientation must have a physical size. PNG can have a
recommended DPI, and has pixel dimensions, hence you can compute a size. JPEG
are JPEG, we just support this in HTML, LaTeX, EPUB, Kindle, Jupyter as a usable
format for "external" images (e.g. photographs). Do they always have a physical
size. We prefer SVG for HTML and EPUB. I think the notion of a physical size
is even more alien for these. (Of course, the S stands for "scalable".)
Are you able to shed some more light on all this?
Rob
On 5/20/25 13:18, Enrique Acosta wrote:
> I also support this feature. Being able to have consistency of comparable
> elements between figs seems to be a very good feature. I also agree with Andrew
> that having the option to set this as the default behaviour would be very useful.
>
> I currently "hack" my way to get Pretext outputs to do this native image sizing
> by not adding @width specifications and overriding the 100% width as follows:
> *For HTML*, use a custom css that redefines the img tag styles with:
> width*=\linewidth]
> CACm44N8DL7V24WzA1N1wX0OO52xS3s4MVg2Bbppgza4iEeZ1HA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> dev+uns...@googlegroups.com>.
> jKh6mvGU05%2Bdg%40mail.gmail.com <https://groups.google.com/d/msgid/
> pretext-dev/CANXmVMBrdunSY3u9Mx4599K-xoo_9C2%2B3XeN-
> jKh6mvGU05%2Bdg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> dev+uns...@googlegroups.com>.
> <https://groups.google.com/d/msgid/pretext-dev/
> CACm44N_QpGySKNzR4hMtiKL%2BV3ZTvE3%2B_v1btR%3DYb7HHfBRCBg%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
> dev+uns...@googlegroups.com>.
> groups.google.com/d/msgid/pretext-dev/
> CAKhX0hDb5T00JZDjuCfGLYPO4MWTngpH6f%2BPZw9OSPngey2Wgw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
My first reaction to Andrew's post is to suggest this is an HTML-centric view of
PreTeXt source. But Enrique's LateX example gives me pause.
@Enrique - your LaTeX code presumes each image has a size in physical units
(inckes, points, etc). No?
We use PDF, PNG, SVG, and JPEG. At least. Sometimes they are converted from
one format (which we generate from source) into other formats.
PDF, with its page orientation must have a physical size. PNG can have a
recommended DPI, and has pixel dimensions, hence you can compute a size. JPEG
are JPEG, we just support this in HTML, LaTeX, EPUB, Kindle, Jupyter as a usable
format for "external" images (e.g. photographs). Do they always have a physical
size. We prefer SVG for HTML and EPUB. I think the notion of a physical size
is even more alien for these. (Of course, the S stands for "scalable".)
Are you able to shed some more light on all this?
Rob
On 5/20/25 13:18, Enrique Acosta wrote:
> I also support this feature. Being able to have consistency of comparable
> elements between figs seems to be a very good feature. I also agree with Andrew
> that having the option to set this as the default behaviour would be very useful.
>
> I currently "hack" my way to get Pretext outputs to do this native image sizing
> by not adding @width specifications and overriding the 100% width as follows:
> width: unset;
> max-width: 100%;
> height: auto;
> and then have the project file load that extra css.
>
> *For LaTeX*, adjust the output .tex file by:
> max-width: 100%;
> height: auto;
> and then have the project file load that extra css.
>
> * Loading \usepackage[export]{adjustbox}
> * Replacing all \includegraphics[width=\linewidth] with \includegraphics[*max
> width*=\linewidth]
> (the adjustbox package is what enables includegraphics to have the option "max
> width", which reproduces the same behaviour as the CSS max-width: 100%)
>
> Happy to share more details if at all useful.
>
> Enrique
>
> On Tue, May 20, 2025 at 1:15 PM Andrew Scholer <andrew....@chemeketa.edu
> <mailto:andrew....@chemeketa.edu>> wrote:
>
> Should intrinsic size be the default? Given that the native behavior of
> adding an image to an HTML page or LaTeX document is to display the image at
> its native size, is that what authoring an <image> with no width should do?
>
> It looks like there is a $docinfo/defaults/image-width that authors could
> use to specify either "native" or "100%". But, to me at least, it feels like
> the out of the box experience should be native.
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649
> computerscience.chemeketa.edu/people/andrew-scholer/ <http://
> width", which reproduces the same behaviour as the CSS max-width: 100%)
>
> Happy to share more details if at all useful.
>
> Enrique
>
> On Tue, May 20, 2025 at 1:15 PM Andrew Scholer <andrew....@chemeketa.edu
> <mailto:andrew....@chemeketa.edu>> wrote:
>
> Should intrinsic size be the default? Given that the native behavior of
> adding an image to an HTML page or LaTeX document is to display the image at
> its native size, is that what authoring an <image> with no width should do?
>
> It looks like there is a $docinfo/defaults/image-width that authors could
> use to specify either "native" or "100%". But, to me at least, it feels like
> the out of the box experience should be native.
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649
> computerscience.chemeketa.edu/people/andrew-scholer/>
>
>
> On Mon, May 19, 2025 at 1:43 PM David Austin <david.a...@gmail.com
> <mailto:david.a...@gmail.com>> wrote:
>
> I support this feature. PreFigure makes math labels with MathJax, and
> ideally the labels would be the same size as in the surrounding text. I
> believe that Andrew's suggestion would make this easier.
>
> David
>
>
> On Mon, May 19, 2025 at 2:47 PM Andrew Scholer
> <andrew....@chemeketa.edu <mailto:andrew....@chemeketa.edu>> wrote:
>
> Currently if you add an image but do not specify a width, it is set
> to 100%. I think there needs to be a way to render images at their
> native size instead of guessing at a width that will render them
> appropriately.
>
> The current options become particularly frustrating when there are
> multiple images that are different size but both have
> comparable elements (especially text) that should be rendered at the
> same size. Below is an example of what I mean (orange added to show
> bounds of images). It looks odd if the text in the two images is
> different sizes because the first image is stretched to the same
> size as the second one.
>
> img1.png
>
>
> On Mon, May 19, 2025 at 1:43 PM David Austin <david.a...@gmail.com
> <mailto:david.a...@gmail.com>> wrote:
>
> I support this feature. PreFigure makes math labels with MathJax, and
> ideally the labels would be the same size as in the surrounding text. I
> believe that Andrew's suggestion would make this easier.
>
> David
>
>
> On Mon, May 19, 2025 at 2:47 PM Andrew Scholer
> <andrew....@chemeketa.edu <mailto:andrew....@chemeketa.edu>> wrote:
>
> Currently if you add an image but do not specify a width, it is set
> to 100%. I think there needs to be a way to render images at their
> native size instead of guessing at a width that will render them
> appropriately.
>
> The current options become particularly frustrating when there are
> multiple images that are different size but both have
> comparable elements (especially text) that should be rendered at the
> same size. Below is an example of what I mean (orange added to show
> bounds of images). It looks odd if the text in the two images is
> different sizes because the first image is stretched to the same
> size as the second one.
>
> img2.png
>
> To fix this, I currently am left to manually fiddle with the % width
> until I get similar sizes. Even then, I may be doing an awkward size
> scale (31%) that doesn't produce exactly the right final pixel size
> and thus ends up with slightly blurry details. (Even an SVG doesn't
> look great if the details end up scaled to non-integer widths).
>
> What about an image@width="intrinsic" that omits creating the %
> width? The max-width would be constrained to 100% to allow graceful
> embedding in things like sidebysides. But there would be no size
> forced on them other than that cap. Left/right margins would be
> forcibly simplified to 0 or auto and default to auto.
>
> For print output, I see table already has some latex to resize down
> if necessary but not resize up. Perhaps the same trick could be
> applied for images with instrinsic width?
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649
> computerscience.chemeketa.edu/people/andrew-scholer/ <http://
>
> To fix this, I currently am left to manually fiddle with the % width
> until I get similar sizes. Even then, I may be doing an awkward size
> scale (31%) that doesn't produce exactly the right final pixel size
> and thus ends up with slightly blurry details. (Even an SVG doesn't
> look great if the details end up scaled to non-integer widths).
>
> What about an image@width="intrinsic" that omits creating the %
> width? The max-width would be constrained to 100% to allow graceful
> embedding in things like sidebysides. But there would be no size
> forced on them other than that cap. Left/right margins would be
> forcibly simplified to 0 or auto and default to auto.
>
> For print output, I see table already has some latex to resize down
> if necessary but not resize up. Perhaps the same trick could be
> applied for images with instrinsic width?
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649
> computerscience.chemeketa.edu/people/andrew-scholer/>
>
> --
> You received this message because you are subscribed to the Google
> Groups "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pretext-dev...@googlegroups.com
> <mailto:pretext-dev...@googlegroups.com>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pretext-dev...@googlegroups.com
> To view this discussion visit https://groups.google.com/d/msgid/
> pretext-dev/
> CACm44N8DL7V24WzA1N1wX0OO52xS3s4MVg2Bbppgza4iEeZ1HA%40mail.gmail.com
> <https://groups.google.com/d/msgid/pretext-dev/
> pretext-dev/
> CACm44N8DL7V24WzA1N1wX0OO52xS3s4MVg2Bbppgza4iEeZ1HA%40mail.gmail.com
> CACm44N8DL7V24WzA1N1wX0OO52xS3s4MVg2Bbppgza4iEeZ1HA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pretext-dev...@googlegroups.com <mailto:pretext-
> --
> You received this message because you are subscribed to the Google
> Groups "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-
> dev/CANXmVMBrdunSY3u9Mx4599K-xoo_9C2%2B3XeN-
> jKh6mvGU05%2Bdg%40mail.gmail.com <https://groups.google.com/d/msgid/
> pretext-dev/CANXmVMBrdunSY3u9Mx4599K-xoo_9C2%2B3XeN-
> jKh6mvGU05%2Bdg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pretext-dev...@googlegroups.com <mailto:pretext-
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CACm44N_QpGySKNzR4hMtiKL%2BV3ZTvE3%2B_v1btR%3DYb7HHfBRCBg%40mail.gmail.com
> <https://groups.google.com/d/msgid/pretext-dev/
> CACm44N_QpGySKNzR4hMtiKL%2BV3ZTvE3%2B_v1btR%3DYb7HHfBRCBg%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com <mailto:pretext-
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CAKhX0hDb5T00JZDjuCfGLYPO4MWTngpH6f%2BPZw9OSPngey2Wgw%40mail.gmail.com <https://
> groups.google.com/d/msgid/pretext-dev/
> CAKhX0hDb5T00JZDjuCfGLYPO4MWTngpH6f%2BPZw9OSPngey2Wgw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
Andrew Scholer
May 21, 2025, 12:18:00 PM5/21/25
to prete...@googlegroups.com
The issue of coherence between sizing of elements within multiple images, or as David A raised, between image based text and the surrounding text, is decidedly cross platform.
Yes, SVG's are scalable. However, they can and often do have an @width or @height. AFAIK common vector editing tools insert dimensions whenever you export/save as SVG (AFAIK there is no way to have Inkscape or Diagrams.Net not include dimensions).
I have no issues with an unsized SVG the author has not specified a size for in PTX getting 100%ed. But if the dimensions are there (possibly because the image author created the image at an explicit size) and they don't override that in PTX, it seems counterintuitive to ignore them.
I have no issues with an unsized SVG the author has not specified a size for in PTX getting 100%ed. But if the dimensions are there (possibly because the image author created the image at an explicit size) and they don't override that in PTX, it seems counterintuitive to ignore them.
Andrew Scholer (he/him/his)
Computer Science Instructor
Chemeketa Community College
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDA0MS5iZWV6ZXI.1747840950%40pnsh.
Enrique Acosta
May 21, 2025, 1:52:53 PM5/21/25
to prete...@googlegroups.com
@Rob, yes, the LaTeX code presumes each image has a size in physical units, but I think this is the case for any image (maybe except for the svg without any dimension attributes Andrew mentions?)
This "default" image size is the size at which latex will display the image if the \includegraphics command has no optional [width=...] attribute, and what allows one to maintain (TikZ built images for example) separately from the main document with consistent font size with the document. One loads the .pdf Tikz output with \includegraphics with no optional [width=] command, and things will just work unless one happens to override the font size in the standalone TikZ files. The [max width=100%] just makes sure in this case to silently scale down images that do not fit within the margins.
This "default" image size is the size at which latex will display the image if the \includegraphics command has no optional [width=...] attribute, and what allows one to maintain (TikZ built images for example) separately from the main document with consistent font size with the document. One loads the .pdf Tikz output with \includegraphics with no optional [width=] command, and things will just work unless one happens to override the font size in the standalone TikZ files. The [max width=100%] just makes sure in this case to silently scale down images that do not fit within the margins.
I may be mistaken, but I think all images have a default image size, which is the one at which they display at 0 zoom level when you open them in some image viewer (think png, jpeg, pdf). I think this also includes svg, since when you open the svg file by itself in a browser (the svg itself, not embedded in an HTML), it displays at a specific size. But admittedly, I do not know what browsers do when one opens and svg with no dimension information, or whether the behaviour in this case is browser dependent.
Enrique
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N8KGbx7K7J-kD5L9pYEEjLvcWE3fGeNNoQ2EWtBitdEng%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages