Re: removing the .IX macro from the ms package in 1.23 breaks old documents

tadziu, I missed your mail/suggestion regarding reinsertion of the `.ll -8n' request in .XA and only today became aware of it due to the reverted commit (so too late to confirm that indeed this fixes the main issue perfectly -- you know that already ;)). thanks a whole lot for pointing this o

Re: removing the .IX macro from the ms package in 1.23 breaks old documents

[replying only to the lists since you're clearly subscribed, or otherwise following them] Hi Joerg, At 2024-10-13T12:36:23+0200, joerg van den hoff wrote: > On 13.10.24 11:24, G. Branden Robinson wrote: > it seems it would probably be best to just agree to disagree and move > on, but ... Where w

[bug #66328] [ms] restore TOC line length alteration used in groff 1.22.4

Update of bug #66328 (group groff): Status:None => In Progress Assigned to:None => gbranden Summary: [ms] restore .ll to .XA (revert commit a6e09ca7fb88fcba8f4b0b5af11f5b51353e4bcb) =

[bug #66328] [ms] restore TOC line length alteration used in groff 1.22.4

Follow-up Comment #1, bug #66328 (group groff): I checked the output of 4.2BSD and 4.3BSD-Reno _ms_, and _groff_ 1.22.4 was indeed more consistent with them than 1.23.0 was, in this respect. (For the purpose of the specimen below, 4.2BSD and 4.3BSD-Reno implementations of _ms_ appear to produce i

Re: removing the .IX macro from the ms package in 1.23 breaks old documents

On 13.10.24 11:24, G. Branden Robinson wrote: Hi Joerg, hi branden, it seems it would probably be best to just agree to disagree and move on, but ... At 2024-10-13T11:03:52+0200, joerg van den hoff wrote: but I really believe the line should never have been deleted in the first place (

Re: removing the .IX macro from the ms package in 1.23 breaks old documents

Hi Joerg, At 2024-10-13T11:03:52+0200, joerg van den hoff wrote: > but I really believe the line should never have been deleted in the > first place (I think the working hypothesis should better be "even if > I do not see why it is there and even if it seems superfluous to me, > it is there for a

Re: removing the .IX macro from the ms package in 1.23 breaks old documents

On Sun, Oct 13, 2024 at 8:31 AM G. Branden Robinson wrote: > It isn't, yet. What you have seen is a Savannah bug report about it.[2] > It was filed anonymously. ("Who _was_ that masked man?" Dave Kemper, I > reckon.) Guilty. I (sometimes) anonymously file tickets in which I have no personal i

Re: removing the .IX macro from the ms package in 1.23 breaks old documents

On 13.10.24 15:31, G. Branden Robinson wrote: [replying only to the lists since you're clearly subscribed, or otherwise following them] Hi Joerg, hi branden, At 2024-10-13T12:36:23+0200, joerg van den hoff wrote: On 13.10.24 11:24, G. Branden Robinson wrote: it seems it would probably b

[bug #66322] [mom] Git HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore

Update of bug #66322 (group groff): Summary: [mom]: groff HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore => [mom] Git HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore

[bug #66322] [mom]: groff HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore

Update of bug #66322 (group groff): Status:None => Fixed Open/Closed:Open => Closed Planned Release:None => 1.24.0 __

[bug #66322] [mom] Git HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore

Follow-up Comment #5, bug #66322 (group groff): (bookworm 1.22.4-10 of course) ___ Reply to this item at: ___ Message sent via Savannah https://savannah

[bug #66322] [mom] Git HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore

Follow-up Comment #4, bug #66322 (group groff): Don't think this is fixed. Compare good-gaming.ps (8740fa141) with good-gaming-24.ps (bookworm 1.24). Beside the pages being different sizes(?), and the colours being different(?), page 2 doesn't have a bottom margin at all, and pages 3 and 4 don't h

[bug #66322] [mom] Git HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore

Follow-up Comment #6, bug #66322 (group groff): Assuming 'good-gaming' and 'good' are identical (I don't have the source for 'good-gaming'), and that the recently committed om.tmac on the master branch is used pdfmon -Tps -Kutf8 -P-pa4 good.mom > good.ps produces clean output. See attached 'go

[bug #66322] [mom] Git HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore

Follow-up Comment #10, bug #66322 (group groff): Addressing each: 1. What "supposed requirement for -Tps"? Do you mean the requirement that papersize be given on the command line? That has always been the case. Or is it some other supposed requirement for -Tps that I've missed in this thread?

[bug #66322] [mom] Git HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore

Follow-up Comment #11, bug #66322 (group groff): Apparently Debian carries d/p/papersize-config.patch that replaces the constant default with reading /etc/papersize, hence why I was getting the A4 w/o config on previous releases, but not on HEAD. My b. ___

[bug #66322] [mom] Git HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore

Follow-up Comment #7, bug #66322 (group groff): Well, considering that bookworm (1.22.4-10) and sid (1.23.0-5) groff's "pdfmom -Tps -K utf-8 good.mom" both produce a 1123/793≈1.41=correct ratio postscript and groff HEAD (same as before) yields a 1056/816≈1.29=wrong ratio postscript, I'm included t

[bug #66322] [mom] Git HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore

Follow-up Comment #8, bug #66322 (group groff): Me no understand. What is the antecedent for the "this" you describe as "not real"? And since I am getting clean results with the master branch pdfmom and om.tmac, what has regressed? ___ R

[bug #66322] [mom] Git HEAD doesn't have any bottom margins(?) and doesn't output page numbers anymore

Follow-up Comment #9, bug #66322 (group groff): The supposed requirement for -Tps and the output page size no longer being correct by default, resp. ___ Reply to this item at: