[groff] 12/14: Replace pseudo slanted characters

deri pushed a commit to branch deri-gropdf-ng in repository groff. commit 5a143514e2f361e87f6187c834a61dd73df7012a Author: Deri James AuthorDate: Mon Jul 3 15:44:29 2023 +0100 Replace pseudo slanted characters * font/devpdf/DESC.in: * font/devpdf/SS: * font/devpdf

[groff] 03/14: Add and document new macro .pdfpagenumbering

deri pushed a commit to branch deri-gropdf-ng in repository groff. commit 004f6fca2d437320270a9a93d9fe9af319f63ca4 Author: Deri James AuthorDate: Sun Apr 16 13:12:17 2023 +0100 Add and document new macro .pdfpagenumbering Allows control of the presentation of page number

[groff] 10/14: Adjust page numbering and margins of groff-man-pages.pdf

deri pushed a commit to branch deri-gropdf-ng in repository groff. commit 496ccd2f1f6016b694a779b3fb8b99ee63f657cf Author: Deri James AuthorDate: Mon May 29 16:11:13 2023 +0100 Adjust page numbering and margins of groff-man-pages.pdf --- doc/GMPfront.t | 3 ++- doc/doc.am | 2 +- 2

[groff] 02/14: Add slim spaces between text '[]'

deri pushed a commit to branch deri-gropdf-ng in repository groff. commit ad718db0c730a2885d6ed3927848ec677a718d59 Author: Deri James AuthorDate: Sun Apr 16 13:03:50 2023 +0100 Add slim spaces between text '[]' * contrib/sboxes/msboxes.ms.in: In pdf '[]' looks like a single

[groff] 13/14: Final cleanup of the new gropdf.

deri pushed a commit to branch deri-gropdf-ng in repository groff. commit 122a761833b8a957a911a9890fdcb87e0ff14e3d Author: Deri James AuthorDate: Mon Jul 3 16:01:15 2023 +0100 Final cleanup of the new gropdf. * src/devices/devpdf/gropdf.pl: Deal with problem if fontforge

[groff] 14/14: Speculative additional request .stringhex.

deri pushed a commit to branch deri-gropdf-ng in repository groff. commit a2b2d5526dca59e93d46019fa8625e6f4c5484d5 Author: Deri James AuthorDate: Mon Jul 3 16:37:17 2023 +0100 Speculative additional request .stringhex. * src/roff/troff/input.cpp: Based on .stringup/down

[groff] 06/14: Fully linked groff-man-pages.pdf

deri pushed a commit to branch deri-gropdf-ng in repository groff. commit 0c0aea4503eb692c5c0dc64c163cb260ae24fe9a Author: Deri James AuthorDate: Wed May 3 17:06:01 2023 +0100 Fully linked groff-man-pages.pdf --- doc/GMPfront.t | 24 doc/doc.am | 8 +++- 2

[groff] 01/14: Changes for groff-man-pages creation.

deri pushed a commit to branch deri-gropdf-ng in repository groff. commit 87f597262635ee274a77d3b22e6de8ea024df8ce Author: Deri James AuthorDate: Fri Apr 14 00:07:47 2023 +0100 Changes for groff-man-pages creation. --- tmac/an.tmac | 71

[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

Re: italic corrections on synthesized slanted lowercase Greek letters on the pdf device (was: Using -Tpdf rather than -Tps and then ps2pdf)

On Friday, 30 June 2023 16:26:51 BST G. Branden Robinson wrote: > Hi Deri, > > At 2023-06-30T16:09:55+0100, Deri wrote: > > On Friday, 30 June 2023 15:43:49 BST Dave Kemper wrote: > > > Are any of the solutions put forth in this thread suitable for > > &g

Re: italic corrections on synthesized slanted lowercase Greek letters on the pdf device (was: Using -Tpdf rather than -Tps and then ps2pdf)

ting, and means gropdf will produce the closest output to grops. Cheers Deri

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

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

Follow-up Comment #1, bug #64354 (project groff): I like this feature and have used it in my software which generates troff output from other sources. It's advantage is that it does not clutter up name space for a colour which may be used only once. Also, it seems to be used in our own

[bug #62264] [troff] string iteration handles escape sequences inconsistently (want `for` request)

Follow-up Comment #5, bug #62264 (project groff): As you may be aware one of the goals for the new version of gropdf I have been working on is to make it "friendlier" for unicode support. To do this I had to drop using asciify and pass the original string to gropdf since the special chars such as

[bug #64319] [gropdf] migrate back to 'L<' template for unpack

Follow-up Comment #3, bug #64319 (project groff): Yes. ___ Reply to this item at: ___ Message sent via Savannah https://savannah.gnu.org/

[bug #64319] [gropdf] migrate back to 'L<' template for unpack

Follow-up Comment #1, bug #64319 (project groff): The new gropdf bumps perl requirement to 5.8 so I'm Ok with 5.9. ___ Reply to this item at: ___

Re: italic corrections on synthesized slanted lowercase Greek letters on the pdf device (was: Using -Tpdf rather than -Tps and then ps2pdf)

On Wednesday, 14 June 2023 03:57:01 BST G. Branden Robinson wrote: > At 2023-06-14T00:53:42+0100, Deri wrote: > > This is using a real font, deleted pdf:SS. > > Looks great! It's not led astray by the superscripts or anything. > > Regards, > Branden Hi Branden, Thes

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

Follow-up Comment #5, bug #64285 (project groff): The list message to which you refer contained a snippet of code intended to show that the changes to pre-processors and troff would not be sufficient, some changes to post processors would be required as well. (It's a one line change in gropdf,

Re: italic corrections on synthesized slanted lowercase Greek letters on the pdf device (was: Using -Tpdf rather than -Tps and then ps2pdf)

provocative of glyph collisions in mathematical typesetting, and by > limiting myself to adjustments in increments of 1/12th em. > > Here is the result. Really trying to not forget the attachments this > time. > > Regards, > Branden This is using a real font, deleted pdf:SS. Cheers Deri oversized-greek.pdf Description: Adobe PDF document

Re: Using -Tpdf rather than -Tps and then ps2pdf

. The pdf shows the difference between using my SS font, using Tadziu's fix to pdf.tmac and using grops and the type 3 SS font. Cheers Deri pdf:SS.pdf Description: Adobe PDF document .ig pdf.tmac Copyright (C) 2011-2018 Free Software Foundation, Inc. Written by Deri James This file i

Re: Using -Tpdf rather than -Tps and then ps2pdf

ndard Symbol font, but I prefer your solution. Cheers Deri

Re: Using -Tpdf rather than -Tps and then ps2pdf

formedFont And if you compare the character width/height given in the SS font the figures are .89 of the equivalent figures in the S font. Cheers Deri

Re: drawing commands in groff(7) (was: undiagnosed pic error)

First attempt truncated, try this. :-( On Friday, 9 June 2023 17:04:56 BST G. Branden Robinson wrote: > Hi Deri, > > At 2023-06-09T12:26:00+0100, Deri wrote: > > On Thursday, 8 June 2023 23:33:25 BST G. Branden Robinson wrote: > > > It was there until literally d

Re: drawing commands in groff(7) (was: undiagnosed pic error)

On Friday, 9 June 2023 17:04:56 BST G. Branden Robinson wrote: > Hi Deri, > > At 2023-06-09T12:26:00+0100, Deri wrote: > > On Thursday, 8 June 2023 23:33:25 BST G. Branden Robinson wrote: > > > It was there until literally days ago. It seemed like such a subtle > >

Re: drawing commands in groff(7) (was: undiagnosed pic error)

alter the behaviour now. Have you done the equivalent changes to the output drivers? Cheers Deri

Re: aliasing fonts (was: Computer Modern Font)

inary fields at the start of the file. Gropdf can use either. Cheers Deri

Re: drawing commands in groff(7) (was: undiagnosed pic error)

the arc! I don't know how relevant this is to the documentation, I am definitely not a maths savant, the special school I went to saw little point in giving us an academic education. Cheers Deri

Re: bitmaps in groff documents

, size of viewer window on the screen. So the short answer is that I don't think it can be done. If possible it is better to use vector graphics if at all possible for diagrams or figures in a document. Cheers Deri

Re: Mission statement and Knuth-Plass reconsidered

eThanh-Dissertation-2000.pdf Cheers Deri

[bug #64232] stop assigning `*[a-ik-uw-z]` special characters to italic fonts

Follow-up Comment #1, bug #64232 (project groff): I believe the behaviour changes in 1.23.0 (for pdf). If the lowercase Greek characters are found in the current (text) font they are no longer forced to italics, see commit d58625a25f2c1732b863d64a259d04a4e61c829d. This could be further refined to

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

Follow-up Comment #9, bug #64155 (project groff): I don't think CJK fonts have I or BI variants (but they can have R and B). To view Japanese man pages something like this is used:- groff -Tpdf -man -dHF=MB -kt -mja -fM -dpaper=a4 -P-pa4 groff.7 > groff.7.pdf So it probably would be better to

Re: [groff] 14/23: gropdf(1), pdfmom(1): Update authorship credits.

d? > > Regards, > Branden Hi Branden, I'm quite happy with your text, it just tickled my fancy. Cheers Deri

Re: Mission statement and Knuth-Plass reconsidered

ve that would make doing K-P this way more > difficult than it needs to be. If you are interested in micro typography there was an interesting discussion some years ago, not K-P:- https://lists.gnu.org/archive/html/groff/2002-02/msg1.html The thesis to which they are referring can found here:- https://www.tug.org/TUGboat/Articles/tb21-4/tb69thanh.pdf It seems good to me. Cheers Deri

Re: [groff] 14/23: gropdf(1), pdfmom(1): Update authorship credits.

= > +.SH Authors > +.\" ==== > +. > +.I gropdf > +was written and is maintained by > +.MT deri@\:chuzzlewit\:.myzen\:.co\:.uk > +Deri James > +.ME . >

Re: [groff] 14/23: gropdf(1), pdfmom(1): Update authorship credits.

= > +.SH Authors > +.\" ==== > +. > +.I gropdf > +was written and is maintained by > +.MT deri@\:chuzzlewit\:.myzen\:.co\:.uk > +Deri James > +.ME . >

[bug #64061] pdfpic.tmac requires non-standard sed feature

Follow-up Comment #16, bug #64061 (project groff): The switch from using grep to sed, which seems to have caused issues, may well have been unnecessary, given that the example pdf provided in bug #58206 was in fact an invalid pdf, which is why pdfinfo did not handle it correctly. The pdf

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

Follow-up Comment #1, bug #64155 (project groff): I suspect this is related to bug #64144 (errors when setting -f to a font which does not contain a full latin-1 character set). It occurs when using .if ''' in a macro so a construct such as .if '\*[.T]'html' will fail when troff generates the

[bug #64144] [man] problems with fonts with no /space glyph and no hyphen glyph

Update of bug #64144 (project groff): Assigned to:deri => gbranden ___ Follow-up Comment #2: Hi Branden, Yes, it ought to be two issues, sorry, I just found both with one test. Your pa

[bug #64144] Problems with fonts with no /space glyph and no hyphen glyph

URL: <https://savannah.gnu.org/bugs/?64144> Summary: Problems with fonts with no /space glyph and no hyphen glyph Group: GNU roff Submitter: deri Submitted: Thu 04 May 2023 12:10:56 AM UTC Category: Mac

Re: choosing a default font family for Chinese and Japanese (was: an.tmac with Japanese man page)

anguage user the profile could export something like "-fM -mja". Cheers Deri

[bug #64130] an.tmac does not honour -f family for headings - assumes T family.

URL: <https://savannah.gnu.org/bugs/?64130> Summary: an.tmac does not honour -f family for headings - assumes T family. Group: GNU roff Submitter: deri Submitted: Sun 30 Apr 2023 08:57:25 PM UTC Category:

an.tmac with Japanese man page

, for headings, you have to set the HF register to the Japanese bold font. It seems that an.tmac sets the font family to T (for headings), even if the user has changed the default family with the -f flag. Should I open a savannah issue, or is this change in behaviour intended? Cheers Deri

Re: Multi-columns in ms

e addtxt .ev add .nf .boxa keep \\$* .boxa .unformat keep .ev .. .addtxt A long line consists of \fBmany\fP words, .addtxt and can be split over many lines. .addtxt Even more words added. .fi .ll 5i .keep .sp .ll 3i .keep .sp .ll 1.5i .keep Cheers Deri

Re: Questions concerning hyphenation patterns for non-Latin languages, e.g. Russian

provement on the > 1 MB. :-) Cheers Deri russ.pdf Description: Adobe PDF document

Re: Chinese texts. (Was: A new ignoramus question about user-installed fonts)

On Saturday, 22 April 2023 11:07:08 BST Ralph Corderoy wrote: > Hi Deri, > > > The problem is probably not ghostscript, current gropdf moans about > > "too many glyphs" when it can't allocate all used to 8 bit code > > points. This too will be addressed in the

[bug #64060] [gropdf] pdfmom should support --help option

Follow-up Comment #2, bug #64060 (project groff): Yes, I'm interested in a patch, thank you. ___ Reply to this item at: ___ Message sent via Savannah

Re: A new ignoramus question about user-installed fonts

pdf moans about "too many glyphs" when it can't allocate all used to 8 bit code points. This too will be addressed in the next version of gropdf, which addresses problems of very large fonts with thousands of different glyphs. Cheers Deri

Re: Definitely positive font installation experience, but not without caveats

"at the moment", watch this space, but it won't be in the upcoming 1.23.0. Cheers Deri

Re: A new ignoramus question about user-installed fonts

ver, I believe this was fixed in commit d58625a25f2c1732b863d64a259d04a4e61c829d which is in the upcoming release. If you can't wait just change one line in pdf.tmac:- .de pdf:SS . char \\$1 \\S'16'\\$1\\S'0' .. Near the top of the file, becomes:- .de pdf:SS . fchar \\$1 \\S'16'\\$1\\S'0' .. Cheers Deri

Re: 1.23.0rc4 .sp and .bp backward compatibility issues

thor (partially you) intended section 8 to start on a new page if run under troff:- .if t \{\ . br . bp .\} But it no longer does. Deri > Regards, > Branden > > [1] > https://git.savannah.gnu.org/cgit/groff.git/commit/?h=branden-2023-04-07 > =72820ac3e1fd4c3421486b80c6b791503ae268a7

Re: Greek and Russian in Groff

y to tell troff to use the U foundry is to use tricks such as -f U-T on groff command line, or .fam U-T or .ft U-TR in your document. Incidentally, using any of these "tricks" makes the use of -P-yU redundant since groff will pass the full font name "U-TR" in the groff_out(5) stream passed to gropdf. Cheers Deri

Re: Greek and Russian in Groff

f > ATTIC/ makhnovshchina.pdf Seems to work fine (no hyphens seen, but visible if line length reduced to 4i). Cheers Deri

Re: Greek in email

ton to view "html version" (the multi-part in quoted printable) the message includes my comment at the bottom. When kmail sends the message the text in both parts should be the same, but in this case it was not. It is my fault too, in that I should have switched off html before replying. :-( Cheers Deri

Re: Greek in Groff

On Thursday, 23 March 2023 21:03:22 GMT G. Branden Robinson wrote: > At 2023-03-18T11:09:16+, Ralph Corderoy wrote: > > > The encoding of choice would probably be ISO 8859-7 in order to > > > remain within the 8 bit character encoding space. > > > > ... > > > > > 4. Write your documents in

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

Follow-up Comment #74, bug #63808 (project groff): [comment #73 comment #73:] > [comment #71 comment #71:] > > Hello again Deri, > > > > You can find it in this folder: > > > > https://www.dropbox.com/sh/17ftu3z31couf07/AAC_9kq0ZA-Ra2ZhmZFWlLuva?dl=0 >

[groff] 01/01: Make pdfmom more versatile.

deri pushed a commit to branch master in repository groff. commit 0290924f05f823039c546f5b14422af7eef70644 Author: Deri James AuthorDate: Thu Mar 9 17:39:07 2023 + Make pdfmom more versatile. * src/devices/gropdf/pdfmom.pl: Add flag -roff which severs hardcoded link

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

Follow-up Comment #69, bug #63808 (project groff): [comment #67 comment #67:] > Hi Deri, > > Regarding the %rom% issue, it looks likely to me that the "rom filesystem built into the executable" <https://ghostscript.com/docs/9.54.0/Use.htm> isn't really in the exec

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

Follow-up Comment #68, bug #63808 (project groff): [comment #64 comment #64:] > > ...things look much better in the contrived "scenario 01" (gs present, urw absent). It is only contrived for debian based distros, others include the ghostscript fonts as supplied from github. I think you may have

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

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

[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

Re: groff for epub/e-books (was: groff 1.22.4 mandb 2.11.2 man -H tbl not rendered)

suit the kindle screen and my eyesight! The text file is from gutenberg.org then I run a script to turn it into a troff file. This is an example (you need to transfer to the reader):- http://chuzzlewit.co.uk/The%20Murder%20on%20the%20Links%20(Kindle).pdf Cheers Deri

[bug #63824] revert recent change to skip tests at configuration time

e 1 fonts it can embed in the documents it generates. (Locating them is a _complex_ process.) And Deri are still wrangling with testing issues anyway (see bug #63808). > > In the long run (groff 1.23.1?), maybe what we want to do is something Deri wanted to do a long time ago, which is bust

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

Follow-up Comment #44, bug #63808 (project groff): Many thanks for the typescript. It looks like a successful groff build, make succeeded and make check successfully reported that ghostscript fonts were not found. Can you tell whether the groff-man-pages.pdf was Ok, apart from the missing fonts.

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

Follow-up Comment #41, bug #63808 (project groff): Savannah won't upload the fonts archive, so I have put it here:- http://chuzzlewit.co.uk/gs-fonts.tgz ___ Reply to this item at:

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

Follow-up Comment #40, bug #63808 (project groff): > Then you are saying "urw absent, gs present" is not a supported groff configuration scenario. No I am certainly not! Maybe representing the logic as a truth table may help you:- *Detab gropdf-font-checks C Is Ghostscript available Y -

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

Follow-up Comment #37, bug #63808 (project groff): > Here's what I need to know. > A) Is it even valid to try to test gropdf with 'gs' available but "no URW fonts"? You explained in comment #7 that URW fonts were donated to Ghostscript. That they might be forked or separately maintained in

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

Follow-up Comment #35, bug #63808 (project groff): [comment #29 comment #29:] > Hi Deri, > > My diagnosis in comment #28 appears to have been correct. > > There is a problem with checking all 35 fonts in the default foundry for gropdf in the "urw absent, gs present"

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

Follow-up Comment #26, bug #63808 (project groff): These changes don't appear in master when I do a git pull so I can't do any investigations. Also, because you do make check rather than make -j; make check if there is a failure in the build phase we don't get to see the result of the tests. For

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

Follow-up Comment #19, bug #63808 (project groff): [comment #18 comment #18:] > Hi Deri, > > Thank you very much--I think I may want to put much of this into a text file in the gropdf source directory. > > [comment #17 comment #17:] > > To be clear the major problem occurs

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

Follow-up Comment #17, bug #63808 (project groff): I am glad you have said that, starting to run out of hair! To be clear the major problem occurs when configure is run and it finds the URW fonts but not ghostscript, a minor problem is the check tests. First some definitions:- Standard gropdf

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

Update of bug #63808 (project groff): Status: Fixed => Need Info Open/Closed: Closed => Open ___ Follow-up Comment #12: I have had to

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

Follow-up Comment #7, bug #63808 (project groff): The URW postscript fonts were donated to ghostscript. [1]. If we look at helvetica, for example, it is actually owned by linotype and licensed to adobe, microsoft and apple. When adobe developed postscript they included the licensed font as one of

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

Follow-up Comment #5, bug #63808 (project groff): Incidentally, why do you have a static list for urw check but a dynamic list (from devps) for basic check. They are equivalent except urw check is looking for the name with U- at the beginning?

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

Update of bug #63808 (project groff): Status: Need Info => In Progress ___ Follow-up Comment #3: It should be:- if gs or urw run basic check if urw run urw check end end

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

URL: <https://savannah.gnu.org/bugs/?63808> Summary: configure gives incorrect information regarding pdf generation Project: GNU roff Submitter: deri Submitted: Wed 15 Feb 2023 04:34:40 PM UTC Category: G

Re: [groff] 01/05: [gropdf]: Skip a test if gs unavailable.

ce requires either ghostscript or the URW fonts to be installed. Cheers Deri > However, perhaps some of the commentary around the skipping, and around > the absence of the 'gs' command reported by our configure script, could > be fruitfully amended. Maybe I could add "fully"

Re: [groff] 01/05: [gropdf]: Skip a test if gs unavailable.

ce requires either ghostscript or the URW fonts to be installed. Cheers Deri > However, perhaps some of the commentary around the skipping, and around > the absence of the 'gs' command reported by our configure script, could > be fruitfully amended. Maybe I could add "fully"

Re: [groff] 01/05: [gropdf]: Skip a test if gs unavailable.

he pdf documentation in groff may be missing, but only those which use fonts other than the base-14. What is your understanding? Cheers Deri ___ Groff-commit mailing list Groff-commit@gnu.org https://lists.gnu.org/mailman/listinfo/groff-commit

[groff] 01/01: [BuildFoundries]: Fails if neither ghostcript nor URW fonts are installed.

deri pushed a commit to branch master in repository groff. commit 398ab1c7722724586f97e3a7ca20714e1d465452 Author: Deri James AuthorDate: Sat Feb 11 13:01:34 2023 + [BuildFoundries]: Fails if neither ghostcript nor URW fonts are installed. * font/devpdf/util

Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure

On Saturday, 11 February 2023 03:17:53 GMT Bruno Haible wrote: > Deri wrote: > > > GEN font/devpdf/download > > > > > > Can't use string ("") as an ARRAY ref while "strict refs" in use at > > > /Users/haible/groff-1.23.0.rc2.22-55

Re: macOS 12.6.3, static_assert, and vasnprintf compilation failure

d get further. If it does, please also attach the build/font/devpdf/download file. I'd like to see line 334 because it should contain the ghostscript program name, gs, but I can duplicate the error if ghostscript is not installed. The change to line 335 will stop the error in this circumstance. Ch

[bug #63757] [gropdf] doesn't handle "papersize" directive as other drivers do

Update of bug #63757 (project groff): Status: Confirmed => Fixed Open/Closed:Open => Closed Planned Release:None => 1.23.0

[groff] 01/01: Fixes

deri pushed a commit to branch master in repository groff. commit 7fb6e3ffd06c0ad8058e5de2325eef55f178ef67 Author: Deri James AuthorDate: Thu Feb 9 15:27:56 2023 + Fixes <https://savannah.gnu.org/bugs/?63757> * src/devices/gropdf/gropdf.pl: Parse papersize

[bug #63757] [gropdf] doesn't handle "papersize" directive as other drivers do

Follow-up Comment #4, bug #63757 (project groff): Both patches seem fine but the gropdf one will need a slight massage. Since groff_font specifies that the papersize entry in the DESC file may contain multiple entries of 3 types (paper name, file path or x,y dimension). The current code only

Re: Fullpage Image Using PDFPIC/PSPIC

On Wednesday, 11 January 2023 07:31:14 GMT Alexis wrote: > On Tue, Jan 10, 2023 at 11:52:28PM +0000, Deri wrote: > > On Tuesday, 10 January 2023 22:46:00 GMT Alexis wrote: > > > Can someone think of a way to place an image as fullpage image > > > using groff with the

Re: Fullpage Image Using PDFPIC/PSPIC

If you do:- .vs 0 .PDFPIC ... .vs it should work. Also groff -Tpdf -U -P-p465p,465p full-page-pdfpic.roff > full-page-pdfpic.pdf is a bit faster in this case. Cheers Deri > If not, would people be open to possibly add another argument > to the `.PDFPIC` and `.PSPIC` macros, e.g.

[bug #63581] "nroff -mom sample_docs.mom" causes infinite loop

Follow-up Comment #18, bug #63581 (project groff): The reason it hangs is because there is an infinite loop. The infinite loop is in the while statement in line 18123 when START is called for the second time in the collated document. The reason it loops is because #DOC_LEAD has a zero value on

Re: Viewing PDFs. (Was: Happy new Sun)

On Tuesday, 27 December 2022 14:11:11 GMT Ralph Corderoy wrote: > > Hi Ralph, > > Deri means you. > > > Since this was produced by gropdf you don't need -mpdfmark since it > > contains its own versions, however, I thought there was a test to stop > > both bein

Re: man(7), hyphen, and minus

tal. (Which led to me writing gropdf). I was producing millions of pages quarterly, and rather than selling the software to the companies (which would have required manuals and a helpdesk), I sold it as a service, charging a click license based on the number of pages produced. Cheers Deri

Re: Viewing PDFs. (Was: Happy new Sun)

tion > Hi Ralph, Since this was produced by gropdf you don't need -mpdfmark since it contains its own versions, however, I thought there was a test to stop both being loaded, so may not be the cause. Any chance of seeing the source file. Cheers Deri > etc etc. This is wrong, of cour

Re: Viewing PDFs. (Was: Happy new Sun)

On Saturday, 24 December 2022 09:06:07 GMT Ralph Corderoy wrote: > Hi Deri, > > > You may need to open the outline pane on the left, which acts like a > > table of contents. > > Is it mandatory that a PDF viewer must supply this mechanism to be > worthy of the name

<    1   2   3   4   5   6   7   8   >