On Sunday, 15 December 2024 23:54:08 GMT G. Branden Robinson wrote: > Crudely, it _looks_ like the baseline might be getting shifted upward by > the vertical dimension of the image, as if placement of the image-based > character "knew" it needed to compensate for the implicit vertical > motion caused by inlining it. If so, I will be relieved, because we can > now regard that fixup as a kludge, and take it out. If I can find it. > > But I could be wrong, and there's no policy around any of this, just a > bunch of things that happened to work together, never got specced, and > never got unit-tested. :(
Hi Branden, The string register "gnu" contains this:- Move up : Output image from separate environment : Move right. Comparing the difference in the grout from 1.23.0 and current, you can see two differences:- @@ -73,10 +71,9 @@ tGNU wh2500 thead -wh2500 +wx X pdf: pdfpic EXPERIMENTS/GNU-head-small.pdf +wh30000 V86000 -x X pdf: pdfpic EXPERIMENTS/GNU-head-small.pdf -wh27500 timage. n12000 0 V132000 The space after the word "head" is dropped and two spaces are added after the image instead. Also the "move up" now occurs after the call to pdfpic. I think this is related to your changes to \X and decisions of when to flush changes. The fundamental requirement for \X is that it remains in the chronology of the output stream. If there is a colour change before \X it needs to occur first, if there are word gaps before the \X, they should be output first. This is true for any action which changes the output, the chronological order of actions in a users document must be preserved in the grout. Conversely .output and \! do not follow chronologically, they pass data to grout as soon as they are actioned, even if a partial line is being constructed by groff. Cheers Deri
