[bug #63827] withdraw contrib/pdfmark

Follow-up Comment #4, bug #63827 (project groff): [comment #3 comment #3:] > * "all arguments" interpolation escape sequence \* I mistyped \$* here. ___ Reply to this item at: __

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #49, bug #63808 (project groff): [comment #41 comment #41:] > Savannah won't upload the fonts archive, so I have put it here:- > > http://chuzzlewit.co.uk/gs-fonts.tgz The size limit is meant to be 16mb for an attachment, but it seems to be lower. Unless it is simplistic virus

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #50, bug #63808 (project groff): [comment #49 comment #49:] > > [comment #41 comment #41:] > > Savannah won't upload the fonts archive, so I have put it here:- > > > > http://chuzzlewit.co.uk/gs-fonts.tgz > > The size limit is meant to be 16mb for an attachment, but it seems t

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #51, bug #63808 (project groff): Hi Branden, [comment #48 comment #48:] > Hi Deri, > [...] > On Debian, the libgs9-common package ships this empty directory: > > /usr/share/ghostscript/9.53.3/Resource/Font > > Your suggestion is I think to dump the fonts from the git repo URL

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #52, bug #63808 (project groff): Done. It appears that the search still fails. checking for URW fonts in Type 1/PFB format... none found [...] GNU roff version 1.23.0.rc3.23-5712 -- installation directory pre

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #53, bug #63808 (project groff): > But the search failed anyway. I'm not sure why. I'll instrument the macro in m4/groff.m4 that searches and see if I can turn something up. I'm open to your suggestions as well. Hold the phone. This looks straightforward. for _font_fil

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #54, bug #63808 (project groff): ding ding ding ding ding ding ding ding checking for URW fonts in Type 1/PFB format... found in /usr/share/ghostscript/9.53.3/Resource/Font checking that generated files are newer than configure... done configure: creating ./config.status config

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #55, bug #63808 (project groff): However the build later fails... BuildFoundries: notice: copied grops font EURO BuildFoundries: error: cannot locate AFM file for font 'U-AB' make[1]: *** [Makefile:14915: font/devpdf/download] Error 2 make[1]: *** Waiting for unfinished jobs...

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #56, bug #63808 (project groff): Deri, What should we do about this? Is it worth gating 1.23.0 final over? ___ Reply to this item at: __

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #57, bug #63808 (project groff): [comment #56 comment #56:] > Deri, > > What should we do about this? Is it worth gating 1.23.0 final over? I note that if I un-contrive the test scenario and put things back the way Debian had them, I get a successful build. checking for URW

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #58, bug #63808 (project groff): Your first attempt has the correct configure messages, this one is wrong. In scenario 01 (ghostscript only) gropdf will be in standard mode with the default foundry only populated, so it is correct to say that the U- foundry will not be available

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #59, bug #63808 (project groff): [comment #58 comment #58:] > Your first attempt has the correct configure messages, this one is wrong. So comment #54 looks good and comment #57 does not. > In scenario 01 (ghostscript only) gropdf will be in standard mode with the default found

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #60, bug #63808 (project groff): [comment #57 comment #57:] > > [comment #56 comment #56:] > > Deri, > > > > What should we do about this? Is it worth gating 1.23.0 final over? > > I note that if I un-contrive the test scenario and put things back the way Debian had them, I

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #61, bug #63808 (project groff): [comment #58 comment #58:] > A message from configure the URW fonts are not found. > No warnings from BuildFoundries. > Only the default foundry groff fonts (base-35 plus EURO). > check-default-foundry has passed. > check-urw-foundry is not run/sk

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #62, bug #63808 (project groff): Okay. I changed _nothing_ about my test environment (outside of the home directory I use to house the build tree). I changed groff code as follows. diff --git a/ChangeLog b/ChangeLog index c387e885b..9b8e3 100644 --- a/ChangeLog +++ b/Chan

[bug #63827] withdraw contrib/pdfmark

Follow-up Comment #5, bug #63827 (project groff): [comment #3 comment #3:] > [comment #2 comment #2:] > > ... > > More importantly, my simple implementation relies on the '!d' > > conditional, which I suspect may be groff-specific, (is it?), > > Yes. Subsection "Conditional expressions" of groff

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #63, bug #63808 (project groff): I think a see a way now to produce gropdf tests that can be skipped depending on parameters determined at configuration time. We can use the _existing_ AC_SUBSTed "$GHOSTSCRIPT" and "$urwfontsdir" shell variables to generate the two test scripts

Re: [PATCH] src/libs/libxutil/XFontName.c(utoa): non-GNU stdlib.h conflict

On 2023-02-23 20:17, G. Branden Robinson wrote: Hi Brian, At 2023-02-23T10:04:41-0700, Brian Inglis wrote: On 2023-02-23 09:07, G. Branden Robinson wrote: At 2023-02-23T00:46:45-0700, Brian Inglis wrote: gcc 11.3 build failure when static utoa definition in XFontName.c conflicts with extern u

[bug #63827] withdraw contrib/pdfmark

Follow-up Comment #6, bug #63827 (project groff): [comment #3 comment #3:] > ... > groff's man pages all have that logic at the top and bottom that > takes the body of the page out of compatibility mode, ... As already noted in bug #63133 comment #1 ,

[bug #63827] withdraw contrib/pdfmark

Follow-up Comment #7, bug #63827 (project groff): [comment #5 comment #5:] > [comment #3 comment #3:] > > [comment #2 comment #2:] > > > ... > > > More importantly, my simple implementation relies on the '!d' > > > conditional, which I suspect may be groff-specific, (is it?), > > > > Yes. Subsec

[bug #58162] unicode.tmac re-enables compatibility mode

Follow-up Comment #5, bug #58162 (project groff): commit 1474eebe1f83c439dd6d422a311c1c39417fac40 Author: G. Branden Robinson Date: Sun Apr 19 15:24:24 2020 +1000 **/*.{man,tmac}: Save compatibility mode robustly. Use new \n[.cp] register to save compatibilty mode. Use r

[bug #63827] withdraw contrib/pdfmark

Follow-up Comment #8, bug #63827 (project groff): [comment #6 comment #6:] > [comment #3 comment #3:] > > ... > > groff's man pages all have that logic at the top and bottom that > > takes the body of the page out of compatibility mode, ... > As already noted in bug #63133 comment #1

[bug #63831] src/libs/libxutil/XFontName.c(utoa) conflicts with stdlib.h utoa in non-GNU libc

Follow-up Comment #1, bug #63831 (project groff): [Email thread about this begins at http://lists.gnu.org/r/bug-groff/2023-02/msg00210.html] ___ Reply to this item at:

[bug #63789] pre-html.cpp: add a space after "nullptr" in a comment

Follow-up Comment #1, bug #63789 (project groff): sed 's#0 */\* *nullptr *\*/#nullptr#g' does the substitution regardless of how much space, including none, is between the 0 and the open-comment sequence, the open-comment and the word "nullptr," and that word and the close-comment. To be extra

[bug #63808] configure gives incorrect information regarding pdf generation

Follow-up Comment #64, bug #63808 (project groff): With the changes discussed in comment #63... $ git show --reverse origin..HEAD commit 5b1d47e4fe4f15fc2b7249b34d1e94d190a1539f Author: G. Branden Robinson Date: Fri Feb 24 06:37:19 2023 -0600 m4/groff.m4: Improve URW font check.