[bug #64561] [mom] using BOX inside QUOTE messes up inline CODE macro

Follow-up Comment #4, bug #64561 (project groff): The initial report was from me. I've read through bug #64421 and would be happy to provide further information about the binaries that come with the homebrew package. What I didn't gather from your comments is if you could reproduce this? BTW: I

[bug #64561] [mom] using BOX inside QUOTE messes up inline CODE macro

Follow-up Comment #5, bug #64561 (project groff): Inspired by bug #64421, I reran the sample on an older 1.22.4 version I had on my banana pi, and there this behavior was absent (see attached file out-1.22.4-P-d.pdf). I also add the -P-d flags (see out-P-d.pdf), but to me the diff of the two file

[bug #64561] [mom] using BOX inside QUOTE messes up inline CODE macro

Follow-up Comment #6, bug #64561 (project groff): And, I ran groff with -Z and compared the two grout files (sorry, the diff is rather lengthy for some reason): diff -u out.grout out-1.22.4.grout --- out.grout 2023-08-16 20:01:00 +++ out-1.22.4.grout2023-08-16 20:01:32 @@ -57,122 +57,15 @

[bug #64597] Spurious newline after image label

low-up Comments: --- Date: Fri 25 Aug 2023 01:22:37 PM UTC By: Sven Schober I am using groff 1.23.0 installed via homebrew on MacOS Ventura 13.5 on a M1 machine. Given this minimal example (image is appended to this issue): .PRINTSTYLE T

[bug #64597] [mom] spurious newline after image label

Follow-up Comment #2, bug #64597 (project groff): Hi Branden! Thank you for correcting the title and other meta data of the issue. I hit submit too fast and could not find a way to correct it later. I just took a look at the PDF_IMAGE source code in mom, but I think it would take me a week of in

[bug #64597] [mom] spurious newline after image label

Follow-up Comment #6, bug #64597 (project groff): Hey Peter, I tried to look at this myself during the last day. I was in way over my head, _but_ I found this sentence in the gnu troff reference manual [1] under "interpolating registers" along the way: > If the register is undefined, it is creat

[bug #66143] build of current master (c9b3c99) fails on MacOS 14.6.1

: None ___ Follow-up Comments: --- Date: Thu 29 Aug 2024 06:49:22 PM UTC By: Sven Schober Hi! I am currently trying to build the HEAD/master (c9b3c99) on my MacOS 14.6.1 machine using a lot of homebrew installed deps (s

[bug #66143] build of current master (c9b3c99) fails on MacOS 14.6.1

Follow-up Comment #2, bug #66143 (group groff): > I've not aware of uchardet library detection being broken anywhere else, and there are no recent reports of such breakage that I can remember. I do not think it's 'broken' -- it's more like too exact, or specific? $ rg uchardet config.stat

[bug #66143] build of current master (c9b3c99) fails on MacOS 14.6.1

Follow-up Comment #4, bug #66143 (group groff): > Just a quick note, an "XFAIL" is an expected failure... Aha! Oh man, this is a bit embarassing.. I thought it meant execution failure or something... and I did not take the time to investigate the calling code. Sorry for wasting your time on that

[bug #66143] build of current master (c9b3c99) fails on MacOS 14.6.1

Follow-up Comment #5, bug #66143 (group groff): I did some googling and it seems there is a poppler version of pdftotext (probabely also pdfimages?), which _does_ support reading from stdin (who am I telling this, you wrote the test :)) and a version from xpdfreader.com, which does not (see [1,2])

[bug #66143] build of current master (c9b3c99) fails on MacOS 14.6.1

Follow-up Comment #6, bug #66143 (group groff): For my uchardet header include problem: My package config file reads like this: cat /opt/homebrew/lib/pkgconfig/uchardet.pc libdir=/opt/homebrew/Cellar/uchardet/0.0.8/lib includedir=/opt/homebrew/Cellar/uchardet/0.0.8/include Name: uchardet Descri

[bug #66155] test suite should confirm functionality of pdftotext

Follow-up Comment #1, bug #66155 (group groff): > two packages, xpdf and poppler, provide a command named "pdftotext". They have the same basic functionality but use some incompatible syntax. In addition to "pdftotext", both packages provide "pdfimages", which also deviate in syntax. The one pr

[bug #66143] build of current master (c9b3c99) fails on MacOS 14.6.1

Follow-up Comment #11, bug #66143 (group groff): So, I now installed a debian bookworm distribution in a VM and checked: pkg-config is behaving the same on that system: grep -IR UCHARDET_CFLAGS Makefile UCHARDET_CFLAGS = -I/usr/include/uchardet preconv_CPPFLAGS = $(AM_CPPFLAGS) $(UCHARDET_CFLAGS

[bug #66143] build of current master (c9b3c99) fails on MacOS 14.6.1

Follow-up Comment #10, bug #66143 (group groff): > The dueling-pdftotexts problem should likely be a separate bug report. Sorry for the mess - but, in my defense, I was a bit hesitant in the beginning.. :) > Solving (2) is a matter of, I think, having the test scripts check the program behavior

[bug #66155] test suite should confirm functionality of pdftotext and pdfimages

Follow-up Comment #2, bug #66155 (group groff): Concerning pdfimages and the mom test: the poppler version emits: pdfimages -list contrib/mom/examples/typesetting.pdf page num type width height color comp bpc enc interp object ID x-ppi y-ppi size ratio ---

[bug #66143] build of current master (c9b3c99) fails on MacOS 14.6.1

Follow-up Comment #14, bug #66143 (group groff): Hi Branden! To answer your questions first: grep UCHARDET_ config.status S["UCHARDET_LIBS"]="-L/opt/homebrew/Cellar/uchardet/0.0.8/lib -luchardet" S["UCHARDET_CFLAGS"]="-I/opt/homebrew/Cellar/uchardet/0.0.8/include/uchardet" and pkg-config --

[bug #66143] build of current master (c9b3c99) fails on MacOS 14.6.1

Follow-up Comment #16, bug #66143 (group groff): Hi Branden! Thank you for your long answer and background information on C and C++! > To be honest, I didn't try, I am a bit sad - but I fully understand your hesitancy. I will try and channel my emotional energy into trying to find out, why a

[bug #66143] build of current master (c9b3c99) fails on MacOS 14.6.1

Follow-up Comment #20, bug #66143 (group groff): Hi Branden! Sorry to keep you so busy with my strange problem and or setup. But at least _I_ am learning new stuff! I did not know about: make V=1 preconv That is great, and there are many situations, where I wish I had known this. So, I wen

[bug #66143] build of current master (c9b3c99) fails on MacOS 14.6.1

Follow-up Comment #21, bug #66143 (group groff): So, me again: I found the problem! I called make with CPPFLAGS=-v, which displays the exact command line that is executed, in both my environments (homebrew and outside). Inside the homebrew environment, there is a single additional include path ad

[bug #66143] build of current master (c9b3c99) fails on MacOS 14.6.1

Follow-up Comment #23, bug #66143 (group groff): Hi Branden! Thanks again for your very long and elaborate answer! >> But, I ask myself, why this is not necessary in the homebrew env. >> >> I found the following: >> >> >> env | grep include >> HOMEBREW_INCLUDE_PATHS=/opt/homebrew/opt/readline/in

[bug #66143] build doesn't find Homebrew uchardet on macOS 14.6.1

Follow-up Comment #30, bug #66143 (group groff): Hi Branden, hi Dave! Thanks for bringing this issue to a close. I was wondering what I could contribute any further to not let all these words go to waste. :) I agree a notice in the repo probably is the best resolution. Cheers Sven ___

[bug #66332] [mom] image caption not centered when set to render after label

Follow-up Comment #13, bug #66332 (group groff): [comment #3 comment #3:] > Mom places labels below images and captions above unless CAPTION_AFTER_LABEL IMG (or ALL), in which case the label and the caption are joined and set below the image. If you have CAPTION_AFTER_LABEL but don't provide a la

[bug #66332] [mom] Image caption not centered when set to render after label

: None ___ Follow-up Comments: --- Date: Mon 14 Oct 2024 12:44:52 PM UTC By: Sven Schober Hi! I am using groff 1.23.0 and the mom macro package that comes with it. When I try to embed an image with a ce

[bug #66332] [mom] Image caption not centered when set to render after label

Follow-up Comment #1, bug #66332 (group groff): I now tried to render the same document with the latest om.tmac from groff git HEAD (ae54c13de00f28fae87adee48f14553d2fd56dee). That brought, at least for me, surprising results: the image was moved to a second page and the caption is located below

[bug #66438] configure fails in since 180d665d19fea419235ea173dce8b4f4e8a5cf65

: None ___ Follow-up Comments: --- Date: Wed 13 Nov 2024 08:16:54 PM UTC By: Sven Schober Hi! Since commit 180d665d19fea419235ea173dce8b4f4e8a5cf65: commit 180d665d19fea419235ea173dce8b4f4e8a5cf65 Author: G. B

[bug #66479] [PATCH] failing tests on macos on HEAD (2562cf237)

Follow-up Comment #2, bug #66479 (group groff): Hi Branden! Here you are: ../src/roff/groff/tests/dvi-device-smoke-test.sh checking 'groff -Kutf8 -Tdvi -Z' checking 'groff -Kutf8 -Tdvi' 000f7 02 00 03 e0 30 00 00 e1 d8 00 00 03 e8 00 8b 02000 00 00 01 00 00 0

[bug #66438] configure fails on macOS since 180d665d19

Follow-up Comment #5, bug #66438 (group groff): Great! I just checked: matches again. Thank you very much! ___ Reply to this item at: ___ Message sent v

[bug #66438] configure fails on macOS since 180d665d19

Follow-up Comment #8, bug #66438 (group groff): @Branden: Out of curiosity and eagerness to learn: Why do you wrap the range expressions into bracket expressions, like this? [[0-9]][[0-9]]*\.[[0-9]][[0-9]]*\.[[0-9]][[0-9]]* It seems a bit redundant to me, as this shorter version also matches f

[bug #66479] [PATCH] failing tests on macos on HEAD (2562cf237)

Follow-up Comment #5, bug #66479 (group groff): Hi Branden! Sorry for comming back to you on this so late, I caught a cold and was unable to respond earlier. Unfortunately, your fix does not work for me, see the attached test-suite.log. I figure from the output, that `expr` is not able to perfo

[bug #66438] configure fails on macOS since 180d665d19

Follow-up Comment #2, bug #66438 (group groff): > Unfortunately, the `\{1,\}` solution you propose is also not a POSIX BRE. Hmm, okay, I did not read the POSIX spec/standard (yet?). But this whole basic vs extended RE business is really unfortunate in my opinion. I always struggle, everytime I w

[bug #66438] configure fails on macOS since 180d665d19

Follow-up Comment #10, bug #66438 (group groff): > To quote the brackets the shell command needs to see. Thank you for clearing that up to me! I did not think about the m4 context, _and_ I did not think of `[`and `]` being m4's quote characters. > I don't remember if POSIX character classes are

[bug #66479] [PATCH] failing tests on macos on HEAD (2562cf237)

Follow-up Comment #7, bug #66479 (group groff): Instead, I fount the following sh arithmetic expression to work: git diff diff --git a/contrib/hdtbl/examples/test-hdtbl.sh.in b/contrib/hdtbl/examples/test-hdtbl.sh.in index 3b5088db6..097b96640 100644 --- a/contrib/hdtbl/examples/test-hdtbl.sh.i

[bug #66479] [PATCH] tests using wc(1) fail on macOS on HEAD (2562cf237)

Follow-up Comment #10, bug #66479 (group groff): Works like a charm now (96147b643): Testsuite summary for GNU roff 1.23.0.2536-cb42f # TOTAL:

[bug #66479] failing tests on macos on HEAD (2562cf237)

: None ___ Follow-up Comments: --- Date: Sat 23 Nov 2024 03:59:59 PM UTC By: Sven Schober Hi all! It's me again, your (hopefully) friendly macos build tester. :) Today, and on the latest HEAD (2562cf237), I found 5 failing tests on macos. I'