[bug #64576] [pdf.tmac] pdf*href option handling insufficiently flexible

URL: Summary: [pdf.tmac] pdf*href option handling insufficiently flexible Group: GNU roff Submitter: gbranden Submitted: Mon 21 Aug 2023 09:50:40 AM UTC Category: Macro - othe

[bug #64577] [grops] can't embed/download fonts from a subdirectory

URL: Summary: [grops] can't embed/download fonts from a subdirectory Group: GNU roff Submitter: gbranden Submitted: Mon 21 Aug 2023 09:58:32 AM UTC Category: Driver grops

Re: Type 1 fonts not downloading

On Monday, 21 August 2023 06:47:37 BST Phil Chadwick wrote: > Hi, > > I have just discovered that as of GNU grops (groff) version 1.23.0 > groff no longer downloads and encodes PostScript fonts into documents. > > This is the method by which I create fully self-contained PostScript > documents th

[bug #64577] [grops] can't embed/download fonts from a subdirectory

Update of bug #64577 (project groff): Status:None => Need Info Assigned to:None => gbranden ___ Follow-up Comment #1: Hi Phil, Thank you f

[bug #64577] [grops] can't embed/download fonts from a subdirectory

Follow-up Comment #2, bug #64577 (project groff): Proposed patch for diagnostic issue. Swept up related cases with it. diff --git a/src/devices/grops/ps.cpp b/src/devices/grops/ps.cpp index 33fce911c..a8cdd2f11 100644 --- a/src/devices/grops/ps.cpp +++ b/src/devices/grops/ps.cpp @@ -788,8 +788,

[bug #64576] [pdf.tmac] pdf*href option handling insufficiently flexible

Follow-up Comment #1, bug #64576 (project groff): [comment #0 original submission:] > An immense amount of code in _pdf.tmac_ seems to be dedicated to an exploration of the question "hey, what if we chucked established _roff_ programming idioms out the window and re-implemented _getopt_long_(3) i

[bug #64576] [pdf.tmac] pdf*href option handling insufficiently flexible

Follow-up Comment #2, bug #64576 (project groff): I reiterate that stuff like this: . while dpdf:href.opt\\$1 \{\ . pdf:href.opt\\$1 \\$@ . shift \\n[pdf:href.argc] . \} is too clever by half--by three quarters, maybe, if you're neither doing sanitization (which wi

[bug #64572] [man] UR, MT with no link text misrender on PDF when -rU1

Follow-up Comment #2, bug #64572 (project groff): [comment #1 comment #1:] > Our documentation says that -rU1 is only relevent to grotty and grohtml. The reason the text is missing is because you set an*can-hyperlink for pdf output, but there is no code to handle the pdf hyperlink in an*end-hyper

[bug #64577] [grops] can't embed/download fonts from a subdirectory

Follow-up Comment #3, bug #64577 (project groff): Thank you for your very prompt attention. I have confirmed that if the postscript font to be downloaded is in the devps directory (and I modify the download file to reflect that), groff works correctly. If I set the GROFF_FONT_PATH to the directo

[bug #64577] [grops] can't embed/download fonts from a subdirectory

Follow-up Comment #4, bug #64577 (project groff): The reason why -F and GROFF_FONT_PATH failed is because groff expects this to point to a directory containing a directory called devps which contains the fonts for postscript. So it should work if you create a symlink in the Type1Fonts directory ca

[bug #64577] [grops] can't embed/download fonts from a subdirectory

Follow-up Comment #5, bug #64577 (project groff): >From a design perspective, this does seem like the situation -U was meant for: telling groff "I'm not processing some random file from sketchy-web-site.com, but something I wrote myself, so I know it's not doing anything nefarious." Still, if Der

[bug #64575] [PATCH] doc/pic.ms: document .PY

Update of bug #64575 (project groff): Summary: doc/pic.ms: document .PY => [PATCH] doc/pic.ms: document .PY ___ Reply to this item at:

[bug #64577] [grops] can't embed/download fonts from a subdirectory

Follow-up Comment #6, bug #64577 (project groff): Deri's comment #4 makes the environment variable work: [strand.144] $ grep -i groff $HOME/.profile groff_fp=/usr/local/share/fonts/Type1Fonts/devps [ -d "$groff_fp" ] && GROFF_FONT_PATH="$groff_fp" && export GROFF_FONT_PATH [strand.145] $ ls -lad

[bug #64579] deprecate driver-specific `internalname` member variable

URL: Summary: deprecate driver-specific `internalname` member variable Group: GNU roff Submitter: barx Submitted: Mon 21 Aug 2023 06:09:29 PM CDT Category: General

[bug #64577] [grops] can't embed/download fonts from a subdirectory

Follow-up Comment #7, bug #64577 (project groff): I just realised that GROFF_FONT_PATH needs to contain a directory called devps. What I did worked because of the circular sym link to devps, but a better setting is: GROFF_FONT_PATH=/usr/local/share/fonts/Type1Fonts __

[bug #61423] [libgroff] document change in handling of font "name" directives

Follow-up Comment #25, bug #61423 (project groff): [comment #9 comment #9:] > A lot of this comment will need to be copied to a Savannah ticket, Bug #64579, at your service. If other things in this epic comment need to be separate tickets, you'll have to help me tease out what they are. __

[bug #64577] [grops] can't embed/download fonts from a subdirectory

Follow-up Comment #8, bug #64577 (project groff): You said you were using;- > [strand.202] $ export GROFF_FONT_PATH=/usr/local/share/fonts/Type1Fonts > [strand.203] $ groff -F $GROFF_FONT_PATH -Tps e.nr >/dev/null No need to alter it, just add the symlink, I should have been clearer. _

[bug #62916] [hdtbl] consider deprecating

Follow-up Comment #5, bug #62916 (project groff): [comment #4 comment #4:] > [comment #3 comment #3:] > > besides hdtbl there are deprecation proposals in at least bug > > #63142, bug #64337, bug #64353, and... bug #59425. > > and now bug #64515. and now bug #64579 (though the proposal itself wa

[bug #64577] [grops] can't embed/download fonts from a subdirectory

Update of bug #64577 (project groff): Status: Need Info => In Progress ___ Follow-up Comment #9: [comment #6 comment #6:] > Problem solved. I'm grateful and impressed. Please close the issue.