[bug #65910] [pic] some dashed ellipse sizes produce irregular dashes

Follow-up Comment #2, bug #65910 (group groff): I've spent some time on this but I don't think I have got very far. I have written some debug code in gropdf to try and show what is happening. Attached are examples. I hope the patterns may mean something to someone more mathematical than I.

[bug #65901] [gropdf] unable to render ellipse with dashed/dotted atribute

Follow-up Comment #5, bug #65901 (group groff): I don't think bug #44530 is related, that seems to be a misunderstanding what ".PS 1i" does to picture. You may have specified a certain space/dashwid but the inclusion of .PS 1i has the effect of scaling the whole picture down to 1 inch so

[bug #65910] Some dashed ellipse sizes produce irregular dashes

: None ___ Follow-up Comments: --- Date: Sat 22 Jun 2024 07:52:18 PM UTC By: Deri James The attached two pdfs are for an 8x3 inch and a 4x1.5 dashed ellipses, i.e. one is half the size of the other. One looks lovely and one

[bug #65901] [gropdf] unable to render ellipse with dashed/dotted atribute

fixed now:- commit dd63af83c106a6a44dbb15ab36d5f3e211515ca5 Author: Deri James Date: Sat Jun 22 18:33:49 2024 +0100 Fix invalid pdf when using certain sizes of dashed ellipse in pic. * src/devices/gropdf/gropdf.pl: For short dashes on flat part of ellipse some v. small n

[bug #65901] [gropdf] unable to render ellipse with dashed/dotted atribute

Follow-up Comment #2, bug #65901 (group groff): Morton wrote on the bug list:- > Odd. The pdf on my end is simply broken. It doesn't show in > mupdf either. Please could you run the dotted ellipse example again but adding this flag "-P-d", and post the resulting pdf. This adds some debug data

[bug #65901] [gropdf] unable to render ellipse with dashed/dotted atribute

Follow-up Comment #1, bug #65901 (group groff): After changing elipse to ellipse in the two code examples, I can't recreate the first problem. The dots are visible in zathura. The issue with dashed is real and is down to my appalling ability with maths. For dashed ellipse/circles groff outputs

[bug #65619] [afmtodit] want a default value for space width if unspecified

Follow-up Comment #8, bug #65619 (group groff): [comment #7 comment #7:] > As a refresher, I'm wondering what should be done about some of the space glyphs identified in comment #5. > So, check for "space", "uni0020", and "uni00A0" in that order? Yes. > sterlingmonospace;FFE1 This is not a

[bug #64005] [ms] fix for Savannah #62688 suppresses page breaks between displays

Update of bug #64005 (group groff): Status: Fixed => Need Info Open/Closed: Closed => Open ___ Follow-up Comment #7: I think there may be a

[bug #65788] gropdf: warning: PDF Dict Key 'User' does not start with '/'

commit b8038971a3cc51cd3981af49092dbdb493f76c06 (HEAD -> master) Author: Deri James Date: Sat May 25 13:40:21 2024 +0100 [gropdf] Deal better with invalid destination names. Bookmark destinations (supplied by -T to .pdfbookmark) are "Name Objects" in pdf terms, as su

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #31, bug #63018 (group groff): I have been investigating the AFMs Branden found with a view to using them as a way to recreate the grops fonts, particularly in situations where there have been changes to the maps, encoding files and afmtodit itself. Since the last release

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #29, bug #63018 (group groff): Dave. I think the implied question is: When it is a separate make target (bug #65698), if we wish to retain the epsilon kerns the make target must either re-apply the shell script after the font generation, or these "gold" AFMs should have the

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #26, bug #63018 (group groff): I have been investigating the AFMs contained in the tar files Branden referenced in comment #15. Using the 229 versions it is possible to generate the 35 fonts for grops. The only difference is that our fonts include kerning data for the ellipsis

[bug #65716] We don't seem to be using the "latest" glyphlist.txt to generate the tables for afmtodit.

ed Release: None ___ Follow-up Comments: --- Date: Wed 08 May 2024 11:47:44 PM UTC By: Deri James As an example current glyphlist.txt has:- bqsquare;33C3 braceex;F8F4 braceleft;007B but our

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #22, bug #63018 (group groff): Speaking about afmtodit only. If vintage afm files are not forthcoming, then (2 - makefile target) is moot. Only (1) is not dependent and that will be done when I rejig afmtodit to:- Look for different 'spaces' to set 'spacewidth'. Implement -ww

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #20, bug #63018 (group groff): This might be a bit previous! Whether we should regenerate the grops font files is rather dependent on whether Branden is successful in locating afm files of a suitable vintage so that running current afmtodit will generate fonts with compatible

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #17, bug #63018 (group groff): It is a bit moot now. If Branden does have the original afms for the grops fonts, which produce identical meta-data as currently, then much better to run afmtodit on all of them as a refresh.

[bug #64155] [troff] specifying -fZD on command line generates warnings

Follow-up Comment #35, bug #64155 (group groff): [comment #34 comment #34:] > > > Well, when you're prepared to discuss it, it would be good to know if/how Dave's original report in comment #0 was invalid > > > > I think I can answer this - it is certainly not invalid, it just has nothing to do

[bug #63018] [PATCH] make glyphs in ZD font accessible via their Unicode spellings

Follow-up Comment #14, bug #63018 (group groff): [comment #9 comment #9:] > Hi Dave, > > [comment #8 comment #8:] > > To clarify: my objection isn't the stale afmtodit version > > It is nevertheless a legitimate one. We should be dogfooding the font description files that _afmtodit_

[bug #64155] specifying -fZD on command line generates warnings

Follow-up Comment #29, bug #64155 (group groff): > Well, when you're prepared to discuss it, it would be good to know if/how Dave's original report in comment #0 was invalid I think I can answer this - it is certainly not invalid, it just has nothing to do with ZD not being a "proper" family

[bug #65619] [afmtodit] want a default value for space width if unspecified

Follow-up Comment #3, bug #65619 (group groff): Afmtodit has always used the width of the space glyph (if defined in the font), what your change did was enable this to be overridden on the command line, which is probably wrong. If the intention was to provide a fallback value when a spacewidth

[bug #65601] [troff] bogus 'bogus composite' errors introduced by commit 6008b6b7aa

Follow-up Comment #5, bug #65601 (group groff): > It would help if you didn't assume autocratic motives behind my code changes. But I'm unsure how to achieve that. By autocratic I am simply meaning that you seem to assume that your ideas are automatically better than your inferiors. In this bug

[bug #65601] [troff] bogus 'bogus composite' errors introduced by commit 6008b6b7aa

Update of bug #65601 (group groff): Status: Need Info => Confirmed ___ Follow-up Comment #3: It is very simple! [derij@pip build (master)]$ echo "This is the arabic alef with a madda above ->

[bug #63018] font/devps/ZD: make glyphs accessible via their Unicode spellings

Follow-up Comment #5, bug #63018 (group groff): Probably the best way of doing this is by adding to dingbats.map, a suitable one is attached (to replace the one in font/devps/generate). Also attached is a replacement ZD file to be placed in fonts/devps. Doing make will propagate the changes to

[bug #62300] [preconv] does not handle U+00A0 (NBSP) as it should

Follow-up Comment #6, bug #62300 (group groff): \[u00A0] is meaningful if you are using a font which defines the glyph. (I appear to have about 67 fonts which define the glyph, some even define kern pairs for the glyph, and one tibetan font defines composites using it). Groff does not convert it

[bug #65619] Provide a default value for afmtodit(1) -w, when unspecified

Follow-up Comment #1, bug #65619 (group groff): If no -w is given afmtodit uses the width of the space glyph as the value. This is ideal since this is the value which the font designer has chosen as most appropriate for particular font. The various values for the URW fonts are:-

[bug #65601] Bogus 'bogus composite' errors introduced by commit 6008b6b7aa

Update of bug #65601 (group groff): Assigned to:None => gbranden ___ Follow-up Comment #1: Assigning to Branden as the expert on this, since it seems to be his new code causing the issue.

[bug #65601] Bogus 'bogus composite' errors introduced by commit 6008b6b7aa

: None ___ Follow-up Comments: --- Date: Tue 16 Apr 2024 11:21:28 AM UTC By: Deri James If preconv produces a valid composite character groff should not reject it. Of course if the composite is not available in any availabl

[bug #65585] [gropdf] problems introduced by commit cd9fde325f

Follow-up Comment #5, bug #65585 (group groff): I am getting this with 'shadow':- derij@raspberrypi5:~/linuxman/man-pages $ make -B build-book MANDIR=../build/man make: *** No rule to make target 'build-book'. Stop. Which used to work before git pull --rebase. So I can't reproduce your page

[bug #65585] [gropdf] problems introduced by commit cd9fde325f

Follow-up Comment #2, bug #65585 (group groff): Hi Branden, All the issues raised in this bug have now been fixed in the release I've just done, one regression is outstanding, can't convert "rs" to unicode, but I will fix that. Alex is not screaming because the "special sauce" I gave him to

[bug #65585] Problems introduced by commit cd9fde325f

: None ___ Follow-up Comments: --- Date: Fri 12 Apr 2024 03:51:08 PM UTC By: Deri James I have been looking at the current state of pdf.tmac and have found a few issues. The changes which have been committed are:- Introduction of

[bug #64155] specifying -fZD on command line generates warnings

Update of bug#64155 (group groff): Assigned to:deri => gbranden ___ Follow-up Comment #21: Hi Branden, I've worked it out. This is the problem, I had a corrupt copy of U-TR in my build

[bug #64155] specifying -fZD on command line generates warnings

Follow-up Comment #19, bug#64155 (group groff): Further testing shows that test-groff works but after a make install it fails!! test-groff [pid 3056312] openat(AT_FDCWD, "/home/derij/groff-git/groff/build/font/devpdf/U-TR", O_RDONLY) = 3 [pid 3056312] newfstatat(3, "", {st_mode=S_IFREG|0644,

[bug #64155] specifying -fZD on command line generates warnings

Update of bug#64155 (group groff): Severity: 2 - Minor => 3 - Normal Status: Fixed => Need Info Open/Closed: Closed => Open

[bug #65246] grops download file does not handle .pfa filenames which contain spaces

: None ___ Follow-up Comments: --- Date: Sat 03 Feb 2024 01:39:01 PM UTC By: Deri James Truncates name. ___ Reply to this item at:

[bug #61434] [man] want support for hyperlinked paragraph tags

Follow-up Comment #4, bug#61434 (group groff): [comment #3 comment #3:] > This was an important follow-up commit. > commit 52a5a89c0da9f90c83441b8eb8020344a8468686 > Author: G. Branden Robinson > Date: Thu Feb 1 23:23:45 2024 -0600 > ... > Unfortunately, "pdf.tmac" doesn't > expose a

[bug #65231] Improve our groff-man-pages.pdf

: None ___ Follow-up Comments: --- Date: Tue 30 Jan 2024 04:54:29 PM UTC By: Deri James To bring it more into line with the LinuxManBook.pdf add clickable links to navigate between separate man entries in the volume, and add a front cover

[bug #65215] .MT/.ME and .UR/.UE should result in hyperlink for pdf output

Update of bug#65215 (group groff): Status: In Progress => Fixed ___ Follow-up Comment #1: Fixes committed. commit d71f9264f8c187aee1161f27cda7d42c4ad7065e Author: Deri James AuthorD

[bug #65215] .MT/.ME and .UR/.UE should result in hyperlink for pdf output

: None ___ Follow-up Comments: --- Date: Fri 26 Jan 2024 01:27:39 PM UTC By: Deri James These macros are meant to produce hyperlinks (according to groff

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

ces.) The pdfmark API was around well before I wrote gropdf, so I just had to support it. What about embedded calls to macros (i.e. \*[macro arg]) I deal with that as well. Here's an example from mom-pdf.mom again:- .AUTHOR "Deri James" "\*[UP .5p]and" "Peter Schaffter&quo

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

Follow-up Comment #12, bug#64285 (group groff): [comment #10 comment #10:] > I see very little difference between PS and PDF output for your input exhibit in comment #9, using bleeding-edge _groff_. I agree. > Regarding the topic at issue, I propose that the first and second paragraphs should

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

Follow-up Comment #24, bug#63074 (group groff): Bug #64484 is marked as fixed. I already have a reliable way to pass byte sequences in device control commands, .stringhex. This bug was previously named "warning messages when using special characters in TITLE or AUTHOR" and the attached

[bug #65097] gropdf: one 'ps:' tag is now not processed

Update of bug#65097 (group groff): Status: Need Info => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #4: Yes. Bjarni's else

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

Follow-up Comment #22, bug#63074 (group groff): Whew, rather a lot to cover! First the original "bug" was "fixed" by including -f U-T in the command. Next it became a wish to include non-latin character in the bookmarks. This is now working on my branch, waiting for Branden's integration. Then

[bug #65115] [PATCH] BMI and BMR definitions are switched in Foundry.in for the U foundry

Update of bug#65115 (group groff): Status: Fixed => Need Info Assigned to:deri => gbranden Open/Closed: Closed => Open

[bug #65115] [PATCH] BMI and BMR definitions are switched in Foundry.in for the U foundry

Follow-up Comment #4, bug#65115 (group groff): > I can push this fix with others later today if Deri doesn't beat me to it. I'm unlikely to win that race. I did take part in the UK National Spastic Games, in my youth, representing the South-East region. Well before paralympics. Won 3 golds and

[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

Update of bug#65112 (group groff): Status:None => In Progress Assigned to:None => gbranden ___ Follow-up Comment #10: No, it was not

[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

Update of bug#65112 (group groff): Status: In Progress => None Assigned to:gbranden => None ___ Follow-up Comment #8: On Bookworm I did

[bug #65115] BMI and BMR definitions are switched in Foundry.in for the U foundry

Update of bug#65115 (group groff): Status:None => Fixed Summary: U-BMI and U-BMR show switched font names in fonts_{n,x}.pdf => BMI and BMR definitions are switched in Foundry.in for the U foundry

[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

Follow-up Comment #6, bug#65112 (group groff): Apologies for the brevity, it was one of those "go to bed and wake up bolt upright with the answer", just wanted you to confirm the fix was good. Now the explanation:- Type 1 fonts have a section of numbered subroutines which can be called from the

[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

Follow-up Comment #5, bug#65112 (group groff): Try this. diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl index e26bc6b43..d55bc1e00 100644 --- a/src/devices/gropdf/gropdf.pl +++ b/src/devices/gropdf/gropdf.pl @@ -4733,7 +4733,11 @@ sub subs_call my

[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

Follow-up Comment #3, bug#65112 (group groff): Ooh, a proper bug. Please can you look in font/devpdf/download file and send me whichever file is assigned to the Symbol font. I can't duplicate the problem with three different versions of the Symbol font file but you may have a fourth. I have a

[bug #65112] [gropdf] glyphs missing from groff_char(7) but not warned about

Follow-up Comment #1, bug#65112 (group groff): Please can you attach the pdf produced, but first could you try the run with -P-e. Without this, all the fonts used (except symbol slanted) are base fonts so no fonts are embedded (so no subsetting either), and its pot luck if your pdf viewer picks a

[bug #65111] [gropdf] "warning: Using nospace mode for font 'EURO'"

Follow-up Comment #1, bug#65111 (group groff): As I have documented elsewhere gropdf has to behave a little differently if a particular font does not define a space glyph. This is because it can use a slightly more compact format if the font defines "space" or "u0020" as a glyph. In a "Hello

[bug #65098] merge branch deri-gropdf-ng to master

Follow-up Comment #4, bug#65098 (group groff): Red Tree I assume you have built my branch at some point, any Titian hues? Special Pleading (MR) = You were correct I was bending a general case to try to fit a special case. For Iterator I can see many

[bug #65098] merge branch deri-gropdf-ng to master

Follow-up Comment #2, bug#65098 (group groff): Dealing with gropdf.pl separately, I have cobbled together a document which may help you in the task. It is a list of all the diffs with a following comment which describes what the changes accomplish. One way of handling this is to introduce each

[bug #65095] gropdf, hdtbl: files "fonts_{n,x}.pdf" almost empty

Update of bug#65095 (group groff): Status:None => Invalid Assigned to:None => deri Open/Closed:Open => Closed

[bug #65098] Merging branch deri-gropdf-ng with master

: None ___ Follow-up Comments: --- Date: Sat 30 Dec 2023 11:01:14 PM UTC By: Deri James I thought it might be helpful to have a place where we can see progress on this. I have noticed some cherry picking from the branch happening so I'm h

[bug #65097] gropdf: one 'ps:' tag is now not processed

Follow-up Comment #1, bug#65097 (group groff): If I look at the output produced by:- pdfmom ../doc/automake.mom -P-d | less I can see:- % x X ps: exec 0 setlinejoin %% V12000 0 j % V12000 % H72000 % x X ps: exec 0 setlinecap %% wh2500 0 J So the "0 j" has been emitted in response to the 0

[bug #65094] gropdf: hdtbl, picture "gnu.eps" is now missing in "mixed_pickles.pdf"

Follow-up Comment #1, bug#65094 (group groff): EPS files are not supported in pdf files, and gropdf only supports embedding pdf files (in the same way as grops only supports embedding eps files). There is a macro PDFPIC which does a similar job as PSPIC. I changed the mixed-pickles.roff to this

[bug #65095] gropdf, hdtbl: files "fonts_{n,x}.pdf" almost empty

Follow-up Comment #1, bug#65095 (group groff): I used this command:- ./test-groff -Tpdf -mhdtbl -U -dfontpath=font/ -dsopath=../contrib/hdtbl/ contrib/hdtbl/examples/fonts_x.roff In the build directory. Seems to work. (I'm using the deri-gropdf-ng branch, don't know about 1.23.0)

[bug #62830] [PATCH] [grops] support CJK fonts encoded in UTF16

Follow-up Comment #12, bug#62830 (group groff): Just a note to point out that gropdf (in the deri-gropdf-ng git branch) already handles CJK documents. The attached pdf is an example, you should see CJK in the pdf bookmarks as well. (file #55489)

[bug #65052] [troff] `cf` behavioral anomalies

Follow-up Comment #1, bug#65052 (group groff): The test you are using is a bit strange. The only proper use for these commands are to include files which are independently movement agnostic. What I mean is they contain grout which does something completely independent of the document which calls

[bug #64592] [troff] registers .m and .M contain no initial value

Follow-up Comment #11, bug #64592 (project groff): After the change I ran the code in comment #1 and now the second line works fine (the first line will never work properly because we don't stack colour changes). Interestingly the call to \m[\*[curcol]] where curcol contains the word "default",

[bug #64592] [troff] registers .m and .M contain no initial value

Follow-up Comment #8, bug #64592 (project groff): Sorry, my fault, I was not clear. My reference to the registers in comment #3 was intended to show that your statement "registers .m and .M don't behave like other registers (containing the default values)" was the problem. I'm not sure (2) can be

[bug #64592] [troff] registers .m and .M contain no initial value

Follow-up Comment #6, bug #64592 (project groff): [comment #5 comment #5:] > Is the problem that registers .m and .M don't behave like other registers (containing the default values), or that the roff language offers no way to retrieve these defaults? See comment #3 which mentions two registers

[bug #64728] diversion widths reported when using eqn mark/lineup feature inconsistent with Heirloom

Follow-up Comment #4, bug #64728 (project groff): > Heirloom nroff reports the same zero width, so if this is indeed a bug, it's a widespread one. If you consider the width of a diversion is the horizontal displacement of the longest line in the diversion, then the horizontal displacement in

[bug #64592] [troff] registers .m and .M contain no initial value

Follow-up Comment #3, bug #64592 (project groff): Hi Branden, Just a few thoughts really, I agree the registers are behaving as currently documented, the question is whether the current behaviour makes sense. Groff currently has no concept of opacity, gropdf allows pdfs included by pdfpic to

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

Follow-up Comment #8, bug #64576 (project groff): > Incidentally, and to motivate my frustration with the `pdfhref` approach, the following works terribly. The hotspots don't know where to end, going nuts and electrifying everything after them even without a page break to screw them up by not

[bug #64612] consider an environment variable for general resources/inclusions

Follow-up Comment #4, bug #64612 (project groff): I was not aware that a change proposed to forbid paths in .fp third parameter and the "name" written by afmtodit, had also (unintentionally) prevented paths in the grops download file, with no diagnostic message. The proposed "fix" seems to be

[bug #64612] consider an environment variable for general resources/inclusions

Follow-up Comment #2, bug #64612 (project groff): Just checking if I am understanding this correctly. GROFF_FONT_PATH will still point to a directory containing groff font resources for each post-processor. Individual directories for each output driver contain groff stuff (DESC, download, groff

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

Follow-up Comment #7, bug #64576 (project groff): Apologies, the t.pdf file had a problem. It worked fine with okular and evince, but some other viewers did not make the links clickable. I have fixed the issue and t-new.pdf should be working with all viewers. (file #55090)

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

Follow-up Comment #6, bug #64576 (project groff): I've just lost half a days typing, my fault, closed the wrong firefox window! Not all is lost, phew, found snippets in my clipboard history as I copied text from Dasher to the savannah page, but it has not got everything, because some I typed

[bug #64592] Registers .m and .M contain no initial value

: None ___ Follow-up Comments: --- Date: Thu 24 Aug 2023 09:35:37 PM UTC By: Deri James This code illustrates the issue:- .ds curcol \n[.m] .ds a \m[red]D\m[]eri .ds b \m[blue]\*a James\m[] \*b is black .\" Fails - no colour stacking

[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 #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

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

Follow-up Comment #1, bug #64572 (project groff): 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-hyperlink. I think you need to

[bug #64360] [PATCH] [gropdf] does not correctly handle white space after 'w' command

Follow-up Comment #32, bug #64360 (project groff): Again a long reply will be required since you've again extended the scope bringing in heirloom, dwb, libdriver. whereas i tried to limit the scope to examine whether gropdfs grout parser was cnformant to our current docs. You may consider our

[bug #63544] [troff] generate "grout" that is more easily lexically analyzed

Follow-up Comment #2, bug #63544 (project groff): Yes, See other discussion. ___ Reply to this item at: ___ Message sent via Savannah

[bug #63074] [troff] need a way to embed non-Basic Latin glyphs in device control commands

Follow-up Comment #17, bug #63074 (project groff): The new gropdf handles this by not asciifying device parameters any more. ___ Reply to this item at:

[bug #64421] [mom] the word "black" spuriously appears in output

Follow-up Comment #21, bug #64421 (project groff): Its probably not relevant but I noticed that your pie version is not stripped. The extra guff can sometimes hide memory overwrites, because the overwrite occurs on part of the program memory which is not critical.

[bug #64484] [troff] .device and \X don't behave the same

Update of bug #64484 (project groff): Severity: 3 - Normal => 2 - Minor Assigned to:deri => gbranden ___ Follow-up Comment #2: There are 4 separate

[bug #64421] [mom] the word "black" spuriously appears in output

Follow-up Comment #19, bug #64421 (project groff): I might have got a little bit further. I have managed to duplicate the issue and have tied it down to the particular troff executable in arch linux. If you replace /usr/bin/troff with the one here:- http://chuzzlewit.co.uk/bad.troff.tgz And

[bug #64421] [mom] the word "black" spuriously appears in output

Follow-up Comment #17, bug #64421 (project groff): You can recreate the -Z output from a pdf produced with -P-d. I use the attached script. You will see the "tblack" at the point it should be "mr 0 0 0". This could happen with:- .gcolor black if 'gcolor' was aliased to nop, or the mom macro

[bug #64421] [mom] the word "black" appears in output

Follow-up Comment #11, bug #64421 (project groff): It may help have a copy of the pdf showing the problem, produced with the -P-d flag set. ___ Reply to this item at:

[bug #64438] [ms] validation of `PS` macro arguments too strict

Follow-up Comment #4, bug #64438 (project groff): One use for the extra parameters may be for captioning, i.e. .PS "An example" The user could then use .am PS to add captioning code to the picture and a pdf bookmark. I'm in favour of silently ignoring excess parameters.

[bug #64353] [PATCH] [troff,drivers] deprecate 'f' drawing command

Follow-up Comment #7, bug #64353 (project groff): No ticket. The earliest reference to the "new features" are in the last paragraph in original TODO file in the gropdf directory. I think they are all done (or irrelevent) now, only took me 10+ years! A new TODO would contain the aspiration to

[bug #64285] [troff] \D't' (set line thickness) drawing command alters drawing position

Update of bug #64285 (project groff): Assigned to:deri => gbranden ___ Follow-up Comment #9: Did you test the code snippet I suggested against grops and gropdf? It would be helpful to see

[bug #64353] [PATCH] [troff,drivers] deprecate 'f' drawing command

Follow-up Comment #5, bug #64353 (project groff): This is fine, but it should wait until gropdf has been cherry picked from my branch to master, when Branden is ready. I hope I won't have to maintain two different versions for long, for example, Colin Watson's reproducible build patch would not

[bug #64417] [pdfmom] should support --help

Update of bug #64417 (project groff): Status: Confirmed => Fixed Assigned to:None => deri Open/Closed:Open => Closed Planned Release:

[bug #64417] [gropdf,pdfmom] should support --help

Update of bug #64417 (project groff): Status:None => Unreproducible ___ Follow-up Comment #1: I think Branden added it previously! [derij@pip ~]$ grops --help usage: grops [-glm] [-b

[bug #64360] [PATCH] [gropdf] does not correctly handle white space after 'w' command

Follow-up Comment #27, bug #64360 (project groff): First I'd like to try to reduce the scope of this discussion, since it seems to have grown in multiple directions. Am I correct in the assumption that the grout files for any given input would not be identical when produced by different roff

[bug #57506] Suspicious "slant" values in devps/TI, devlbp/HI, devlbp/HBI

Follow-up Comment #13, bug #57506 (project groff): I wanted to find out why the position of the diaeresis was so different between Tinos and Libertine, given that the Z files were identical and the font entries are similar, both have a zero width. So, it must be something different in the type 1

[bug #57506] Suspicious "slant" values in devps/TI, devlbp/HI, devlbp/HBI

Follow-up Comment #11, bug #57506 (project groff): Your utf8 example has the diacritical mark above the n. If I run it as a pdf using Tinos fonts the mark is above the a! [derij@pip build (new-gropdf)]$ echo '\fIThis is Spin\[u0308]al Tap' | ./test-groff -Tpdf -fTINO -ms -P-e -Z x T pdf x res

[bug #64354] [troff] discourage or reject use of 'F' drawing command

Follow-up Comment #3, bug #64354 (project groff): Not using \D'F' only useful for fills not strokes, but a little example which converts various embroidery machine formats (exp/dst/pes) to pes or svg or troff. Maybe I should send it to Linus. :-) (file #54900)

[bug #64360] [PATCH] [gropdf] does not correctly handle white space after 'w' command

Follow-up Comment #24, bug #64360 (project groff): For your delectation I recorded me writing the last message, to give you a rough idea how long it will take. Try:- vlc http://chuzzlewit.co.uk/screen.mp4 I'd classify it as a PG rather than a U. :-)

[bug #64360] [PATCH] [gropdf] does not correctly handle white space after 'w' command

Follow-up Comment #23, bug #64360 (project groff): Please can you give me a few days to answer this. It will take me a lot of hours. ___ Reply to this item at:

[bug #64360] [gropdf] does not correctly handle white space after 'w' command

Follow-up Comment #14, bug #64360 (project groff): Exactly, it is not a word gap its a horizontal move. Please can you explain the practical benefit for this change. Perhaps on the list given that it is a change the current api between groff and the output drivers.

[bug #64360] [gropdf] does not correctly handle white space after 'w' command

Follow-up Comment #10, bug #64360 (project groff): Yes, I have seen multiple "w", but never one followed by a space. I thought commands and arguments with a known fixed length (such as the w command) aren't separated by syntactical space. Well, that was true until now. Previously, before you

[bug #64360] [gropdf] does not correctly handle white space after 'w' command

Follow-up Comment #9, bug #64360 (project groff): Yes, I have seen multiple "w", but never one followed by a space, can you work out why? I thought commands and arguments with a known fixed length (such as the w command) aren't separated by syntactical space. Well, that was true until now.

[bug #64360] [gropdf] does not correctly handle white space after 'w' command

Follow-up Comment #3, bug #64360 (project groff): Just move this line:- $lin=~s/^\s+//; to before the while loop. How did you get groff to plant the space? ___ Reply to this item at:

  1   2   3   >