On Thu, Jul 09, 2026 at 07:55:47AM +0300, Eli Zaretskii wrote: > > Date: Wed, 08 Jul 2026 17:22:15 +0000 > > Cc: [email protected] > > From: Werner LEMBERG <[email protected]> > > > > > One thing is clear to me, this shows the limits of pre-reflowing the > > > text as is done in the Info format. But besides that, I do not have > > > a clear idea on what would be the best output. > > > > AFAIK, the image width is unknown while `makeinfo` is preparing the > > Info file. Both `info` and `emacs` read this Info file; while `info` > > can only display the replacement text, `emacs` is able to show the > > image. > > > > My conclusion is that only the width of the replacement text is known. > > Consequently, I think that for inline images in Info mode only the > > width of the replacement text (or a default value in case the > > replacement text is missing) can be used for pre-formatting a > > paragraph; the replacement text should be handled as if put into a > > `@w{}` box – I think it's better to have too short lines than too long > > ones. > > TBH, I don't quite understand how the image width can be used for > filling the lines, even if known. The width of an image is known in > pixels, but for filling purposes it must be converted to characters, > and that requires to know the size of the font to be used to show the > manual. That's not something makeinfo can do. > > Am I missing something? > > My conclusions from this are: > > . inline images in Texinfo should be avoided at all costs > . if we do want to support inline images _and_ fill the text with > such images, then makeinfo should use the width of the text > alternative for filling, and we should document that the text will > be filled correctly when an image is displayed only if the image > takes on display space that is no wider than the text alternative, > something that the author of the Texinfo source must ensure
I don't agree. The fact that the replacement text is available when makeinfo runs is not a good reason for using it. (It reminds me of the parable of the man searching for his lost keys under a lamppost because that is where it is light, even though he dropped his keys elsewhere.) There is no reason why the replacement text should occupy the same amount of space as the image. As a result, there is simply no way to get perfectly good results in Info output for both the images being displayed (as in Emacs Info) and the the replacement text being displayed (as in standalone Info). The best idea I can come up with to provide some kind of customization variable to select which measure of image width to use: treat then as having zero width (as is done currently), use the width of the replacement text, use the width of the alternative text (that's different to the replacement text), use a fixed value (like 2 or 3), or try to calculate the width of each image in screen columns. The second parameter to @image, if provided, is in fact the width of the image (given in units like points) but this is only used when processing with TeX. As Eli says, this does not transfer directly to a number of characters wide. We could assume 10 pt text to convert this to a number of terminal columns, but this may not produce perfect results. We already suggest assuming 10 pt font size in the manual, in the documentation of the Info format for the output with INFO_MATH_IMAGES, where images are produced for @math and @displaymath in Info output. https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Info-Format-Image.html We designed this feature to allow displaying mathematical notation (formatted with TeX) inline in text, which is a similar problem to the one in Werner's use case. (However, it's different in that dpi (and depth) values are only output for @math and @displaymath images, not for images output with @image.) I have not heard that there has been any support implemented in Emacs for recognising 'dpi' and 'depth'. I would assume that makeinfo does not take into account the width of produced images for INFO_MATH_IMAGES either.
