Re: [groff] gropdf(1) Has Ugly Thick Lines by Default.

ome more on this. :-( Cheers Deri

[groff] 01/01: Add gropdf new features to NEWS file.

deri pushed a commit to branch master in repository groff. commit a3c62d4396f7ac468d41185e03c0d6cbd20fb3db Author: Deri James Date: Tue Jun 19 12:10:09 2018 +0100 Add gropdf new features to NEWS file. * NEWS: new features. --- ChangeLog | 8 +++- NEWS | 15

Re: [groff] Macron characters in pdf files

On Tuesday, 5 June 2018 16:37:15 BST Peter Schaffter wrote: > Hi, Deri. > > > The results, i.e. failure, are identical for both gropdf and grops. > > Hmm... Processing your file, macron.trf, with -Tps and -Tpdf > produces results different from yours, namely > > Wit

Re: [groff] Macron characters in pdf files

On Mon 04 Jun 2018 23:21:15 Peter Schaffter wrote: > Greetings. > > I've verfied that the problem discussed in the following forwarded > email exists. -Tps has no trouble finding macron characters > composed in vim; -Tpdf does. Deri, I think this is your bailiwick. > >

Re: [groff] hyphen, minus sign and hyphen-minus

d as the dvi route. Cheers Deri

Re: [groff] hyphen, minus sign and hyphen-minus

On Sat 26 May 2018 11:50:31 Ralph Corderoy wrote: > Hi Deri, > > > man -Tpdf will produce what you want. The '\-' (minus) is used as the > > output glyph, but any copy/paste (or searching within document) will > > use '-' (hyphen). > > > > This is similar t

Re: [groff] hyphen, minus sign and hyphen-minus

On Fri 25 May 2018 16:59:50 Pali Rohár wrote: > Happens for: man -Tps and man -Tdvi > > And I think that the best readable output is by grodvi driver. So would > really like to have working copy+paste from the dvi output (converted to > PDF viewer). man -Tpdf will produce what you want. The '\-'

[groff] 01/01: Restrict scaling factors to 3dp and better handle CR/LF in import.

deri pushed a commit to branch master in repository groff. commit 1041a8139d9b872ba0576a4c5dc36fd789c4ed91 Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Tue Apr 24 17:29:40 2018 +0100 Restrict scaling factors to 3dp and better handle CR/LF in import. * src/devices/

[bug #52525] gropdf: Uninitialized variable "$fld"

Follow-up Comment #5, bug #52525 (project groff): Yes it was fixed in that commit. ___ Reply to this item at: ___ Message sent via/by Savannah

Re: [groff] groff as the basis for comprehensive documentation?

On Sat 21 Apr 2018 08:16:36 Nate Bargmann wrote: > Note that I am only working with Groff's man macro package and do > understand that other macro packages may have greater demands on the > HTML generator. You might consider supporting mdoc macros. You may have seen:-

Re: [groff] groff as the basis for comprehensive documentation?

rent state at:- http://chuzzlewit.co.uk/groff_book.pdf Chapter 6 (Preprocessors) is largely man pages. The pdf is built using groff. Is this the sort of thing you were envisaging. I am currently on holiday so minimal email. Cheers Deri

[groff] 01/01: Make PDFPIC behave the same whether -Tps or -Tpdf used.

deri pushed a commit to branch master in repository groff. commit 82630588fc32a5d2e00f257bc79cac7493e7e809 Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Thu Apr 12 19:23:25 2018 +0100 Make PDFPIC behave the same whether -Tps or -Tpdf used. Previously the -Tpdf versi

Re: [groff] PSPIC vs PDFPIC: adjust documentation to reality, or the reverse?

IC already requires it to be run in "unsafe" mode the code to check an environment variable is fairly straight forward. Cheers Deri

Re: [groff] PSPIC vs PDFPIC: adjust documentation to reality, or the reverse?

hich will restore the previous behaviour for all runs. Note that this change has no effect it you were using .PDFPIC with the postscript driver, only if you used it with the pdf driver. ===== Does this sound sensible? Cheers Deri

Re: [groff] PSPIC vs PDFPIC: adjust documentation to reality, or the reverse

On Mon 02 Apr 2018 14:30:51 Doug McIlroy wrote: > > > Would it hence be sensible to change PDFPIC to fit the description > > Yes. This is clearly a bug, even if it's been around for years. > > Doug 100% agreement this should be fixed, although compatibility with previous version will be

Re: [groff] Creating a pdf slideshow

ut the x11 filled the entire screen and no movement when the H and V keys are pressed. When in presentation mode mupdf seems to support the Blinds and Wipe transitions but uses a fade for all the others. If you have it, evince pdf reader, seems to have most support for presentation mode that I have found.

[groff] Creating a pdf slideshow

ut all the wrinkles. Cheers Deri .pl 9c .nr PO 1c .nr LL 14c .nr LT 14c .nr HM 1c .nr FM .5c .RP no .P1 .nr bm 0 1 .nop \!x X papersize=16c,9c .ds PDFHREF.COLOUR 0.0 0.3 0.9 .defcolor pdf:href.colour rgb \\*[PDFHREF.COLOUR] .ds PDFHREF.TEXT.COLOUR pdf:href.colour .OH "'\m[grey]Slides Demo''D

[groff] 01/01: PDF must not open in presentation mode.

deri pushed a commit to branch master in repository groff. commit 7e956851571c06c58770de50b4c6aeffedc629fc Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Fri Mar 9 23:02:14 2018 + PDF must not open in presentation mode. * src/devices/gropdf/gropdf.pl

Re: [groff] [bernhard.fiss...@mail.de: mom: PDF Author, pdfmom: needs C locale?]

--color' So I unaliased it and ran again, with same result, except the "y" was not coloured. I don't know why I don't see the message! Cheers Deri

[groff] 01/01: Dot signifies missing parameter in .pdftransition

deri pushed a commit to branch master in repository groff. commit 24d84d7413ee13a9e92ca7142bf9e3e1602d8e8f Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Fri Mar 9 15:14:07 2018 + Dot signifies missing parameter in .pdftransition * src/devices/gropdf/gropdf

Re: [groff] [bernhard.fiss...@mail.de: mom: PDF Author, pdfmom: needs C locale?]

On Thu 08 Mar 2018 17:06:12 Peter Schaffter wrote: > This seems to be an "on again, off again" bug. We discussed adding > LC_ALL=C to the command string in pdfmom, but I see it's not there. > Deri--any objections to adding it? The alternative is to pass the > -a fla

[groff] 01/01: Place pdf in presentation mode if new commands used.

deri pushed a commit to branch master in repository groff. commit ea2251991d7a80b271b284d5599ec8b06456863e Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Tue Mar 6 11:31:45 2018 + Place pdf in presentation mode if new commands used. * src/devices/gropdf/gropdf: T

[groff] 01/01: Add page transitions to pdfs created with gropdf.

deri pushed a commit to branch master in repository groff. commit f2a92911c552c3995c010f8beb9b89de3612e95a Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Thu Mar 1 15:16:11 2018 + Add page transitions to pdfs created with gropdf. * src/devices/gropdf.pl: Handle n

[bug #52525] gropdf: Uninitialized variable "$fld"

by next Friday, so this fix will be included in that. Cheers Deri ___ Reply to this item at: <http://savannah.gnu.org/bugs/?52525> ___ Message sent via/by Savannah

[bug #52525] gropdf: Uninitialized variable "$fld"

Follow-up Comment #1, bug #52525 (project groff): Afraid I can't duplicate this in 1.22.3.rc1. [derij@pip build (master)]$ ./test-groff -Tpdf ~/gropdf/testing/bug-52525/test.trf >/dev/null this is the t-block [derij@pip build (master)]$ ./test-groff -Tpdf ~/gropdf/testing/bug-52525/test.trf

Re: [groff] Release Candidate 1.22.3.rc1

On Fri 16 Feb 2018 11:42:13 Peter Schaffter wrote: > After the list discussion back in the fall about slides and > gpresent, Deri tinkered with gropdf and I with om.tmac to implement > slides with mom/gropdf. I think the mom side of things is done, but > I'm holding off releasing the

Re: [groff] Something broke embedded fonts in gropdf output (but not grops)

it has chosen its own fonts. You may like to investigate the "install-font.sh" script on Peter Schaffter's mom site:- http://www.schaffter.ca/mom/mom-06.html#install-font This may do what you want. Cheers Deri

[groff] 01/01: Better handle glyphs in font positions > 255

deri pushed a commit to branch master in repository groff. commit 6df65ebdf5f50f3b6619581209adff32e3774831 Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Sun Nov 12 19:48:47 2017 + Better handle glyphs in font positions > 255 * src/devices/gropdf/gropdf.pl

[groff] 01/01: gropdf should load ALL 'download' files

deri pushed a commit to branch master in repository groff. commit 6b2942c79f5dd34883f450a2947f611a11b085d3 Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Sun Nov 12 17:44:37 2017 + gropdf should load ALL 'download' files * src/devices/gropdf/gropdf.pl: only the

[groff] 01/01: Make gropdf reallocate unused character codes

deri pushed a commit to branch gropdfmultiglyph in repository groff. commit 919396ef40ca277b79b0c791e71d73b45d079167 Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Tue Oct 17 14:05:07 2017 +0100 Make gropdf reallocate unused character codes * src/devices/

Re: [Groff] PDFPIC macro

On Sun 08 Oct 2017 20:26:02 Keith Marshall wrote: > You may recall that I did begin to explore possibilities, at the time, > but then life ... explicitly a protracted visit to Australia and New > Zealand, followed by too many other priorities on return ... got in the > way. I've now found a

Re: [Groff] devpdf U-fonts and Russian

till a firm push that I should bite the bullet and go with your suggestion. Cheers Deri

Re: [Groff] pdfmom grep (was parallel text processing)

don't they make special glasses that let > you see code as if for the first time whenever you put them on? > > -- > Peter Schaffter I can't actually recreate the problem, i.e. grep does not spit out the "binary" error. I've tried with a en_GB.UTF-8 and a en_GB environment, neither show the message. The version of grep I'm using is:- grep (GNU grep) 2.20 The double escaping of the "." in the grep pattern used to be there:- grep \"^\\.ds\" but got changed. Cheers Deri

Re: [Groff] parallel text processing ; vertical and horizontal mode

ain the > grep(1) line. Any ideas what's going on? No files attached, but I suspect this may be the grep in pdfmom, will have a look when we see the files. Cheers Deri

Re: [Groff] Elegant -ms and -mpdfmark documents

On Tue 05 Sep 2017 23:49:26 Kristaps Dzonsons wrote: > For example, the colouring of links You could insert these lines at the top of the .ms file:- \# These lines set link text and border colours to rgb 0.0 0.3 0.9 .ds PDFHREF.COLOUR 0.0 0.3 0.9 .defcolor pdf:href.colour rgb \*[PDFHREF.COLOUR]

[bug #44903] mom 2 column output is misplaced

Follow-up Comment #2, bug #44903 (project groff): I believe this bug has been fixed. The test mom document no longer shows the error in 2 column output. ___ Reply to this item at:

[bug #50989] Incorrect generation of typesetting.pdf

Follow-up Comment #15, bug #50989 (project groff): I have committed the patch. I have not committed my CheckType1.pl script since it is unlikely to be of use to anyone, apart from testing the new font loading code. If gropdf fails to load a particular font the utility is not going to help find

[groff] 01/01: 'gropdf' does not correctly load new ghostscript fonts

deri pushed a commit to branch master in repository groff. commit fe51e3b63753f9c4b139b609329e211b1e7ca6e2 Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Mon Aug 21 15:14:54 2017 +0100 'gropdf' does not correctly load new ghostscript fonts See bug at:

[bug #51568] gropdf: Bug when string '\e014' is in the input

Follow-up Comment #7, bug #51568 (project groff): Oh dear! I think I have nailed the octal character problem now, about to check in the fix. I spotted the undefined warning yesterday, and it was included in the patch attached to bug 50989. I will be including it also in the fix I upload today.

[bug #50989] Incorrect generation of typesetting.pdf

Follow-up Comment #13, bug #50989 (project groff): I have rewritten the font loading code, it seems to handle both old and new ghostscript supplied fonts. However, before I commit the change I have supplied a patch for testing, since it is significantly different from the old version! I have also

[groff] 01/01: See bug at: https://savannah.gnu.org/bugs/?51568

deri pushed a commit to branch master in repository groff. commit 6a241192be60d0cc1a2ab5464281e297b2c0243d Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Mon Jul 31 17:02:02 2017 +0100 See bug at: https://savannah.gnu.org/bugs/?51568 * src/devices/gropdf/gropdf: pr

[bug #51568] gropdf: Bug when string '\e014' is in the input

Follow-up Comment #4, bug #51568 (project groff): Yes, the fix needs to be more generic. However, in some situations the driver itself uses the octal \nnn markup. When a named glyph is sent, if it occurs in the first 32 font positions, or it occurs after position 255 and is then remapped to a

[groff] 01/01: If input text contained string which could be interpreted as escaped octal (\ddd) a pdf viewer would interpret as an octal character. See bug at: https://savannah.gnu.org/bugs/?51568

deri pushed a commit to branch master in repository groff. commit 67c3d46d452ce05082839920a8058091a8797583 Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Tue Jul 25 16:43:54 2017 +0100 If input text contained string which could be interpreted as escaped octal

[bug #51568] gropdf: Bug when string '\e014' is in the input

Follow-up Comment #2, bug #51568 (project groff): Looking inside the pdf (groff -Tpdf -P-d test | less) I see:- 0.000 Tw [(Octal character code "\014" for a form feed. Alternati)] TJ So gropdf has passed through the text "as is". The PDF Reference says:-

Re: [Groff] mom : unicode in .INCLUDE'd files

e U- fonts should be part of > the standard 1.22.3 version of Groff. > > Just a thought. > > --Dale > Hi Dale, It ought to work if you include:- -P-yU On the pdfmom command line. This should tell gropdf to use the U- foundry, so you don't have to alter the actual mom document. Cheers Deri

[bug #50989] Incorrect generation of typesetting.pdf

Follow-up Comment #9, bug #50989 (project groff): I am intending to rewrite the font loading code in gropdf to handle the situation where the 3 "chunks" of a type 1 font are treated separately for binary/ascii loading. It would help if I could find where the actual official file format is

[bug #50989] Incorrect generation of typesetting.pdf

Follow-up Comment #4, bug #50989 (project groff): It looks like only the first block header is missing, there is one immediately after the "eexec" which gives the length of the main block which is then followed by another block which is the trailing "0"s. So it looks likely I can do a sort of

[bug #50989] Incorrect generation of typesetting.pdf

data on the front of the file which define the length of the first block. The new CenturySchoolbook fonts from ghostscript are raw binary but do not have this binary header. So the problem is in gropdf, I'm working on a solution. :-) Cheers Deri

[bug #50786] Font generation in font/devpdf broken with ghostscript 9.21

Follow-up Comment #8, bug #50786 (project groff): The patch does not take into account that the total directories searched includes the output from "gs -h" which on my system is:- Search path: /home/derij/.fonts : /usr/share/ghostscript/9.14/Resource/Init : /usr/share/ghostscript/9.14/lib

[bug #50770] .PSPIC macro at bottom of page causes unwarranted page break

Follow-up Comment #10, bug #50770 (project groff): Humble apologies! I've been wrong all along! I've now done some playing and THIS is how it works. The default point size is 10 and the vertical size is 12, the page length is 792 (11 inches) so exactly 66 lines fit on a page. After .sp 64 the

[groff] 01/01: Fixes for gropdf

deri pushed a commit to branch master in repository groff. commit 5d052395efcfd260ce0a42481fbf87c810184ee3 Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Thu May 4 22:45:31 2017 +0100 Fixes for gropdf * src/devices/gropdf/gropdf.pl: Escape '(' and ')' if

[bug #50770] .PSPIC macro at bottom of page causes unwarranted page break

Follow-up Comment #8, bug #50770 (project groff): > Sorry if I was unclear. I am referring to the case where an image fits at > the bottom of a page, but PSPIC insists on moving it to the next page > anyway, because +1v. This move only results in an empty space that could > have been filled

[bug #50770] .PSPIC macro at bottom of page causes unwarranted page break

Follow-up Comment #6, bug #50770 (project groff): The problem with changing it is that it breaks backward compatibility, which is important for software which has been around for a long time. A document created 15 years ago should render the same now as it did then. This is an aspiration, it is

Re: [Groff] Nesting font macros in man pages

On Thu 27 Apr 2017 23:48:29 Steffen Nurpmeso wrote: > Terrible, see the spacing errors surrounding the command list > before the "Substitution" heading! Not your fault of course, but > gr... > > --steffen Well, turns out it WAS my fault! Bug in gropdf, will commit after more testing.

Re: [Groff] Nesting font macros in man pages

On Thu 27 Apr 2017 20:12:09 Ingo Schwarze wrote: > Does that still apply to > > view-source:http://man.openbsd.org/ksh compared with a PDF version:- http://chuzzlewit.co.uk/WebManPDF.pl/man:/1/ksh

[bug #50786] Font generation in font/devpdf broken with ghostscript 9.21

Follow-up Comment #3, bug #50786 (project groff): The first section of Foundry.in duplicates exactly the same fonts as the grops driver, the U-* fonts are intended for the URW versions of the same fonts. The difference is that the grops versions only have 255 glyphs defined in the font, while the

[bug #50786] Font generation in font/devpdf broken with ghostscript 9.21

whichever version of ghostscript is installed. Cheers Deri ___ Reply to this item at: <http://savannah.gnu.org/bugs/?50786> ___ Message sent via/by Savannah http://savannah.g

[groff] 01/01: Remove duplicate '-e' from gropdf manual.

deri pushed a commit to branch master in repository groff. commit 0c0860207ad96ededb5ee3394eb091c74a977129 Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Thu Dec 29 12:20:53 2016 + Remove duplicate '-e' from gropdf manual. * src/devices/gropdf/gropdf.1.man:

Re: [Groff] Colors with gropdf

On Fri 25 Nov 2016 16:47:26 Robert Marks wrote: > I have recently had to embed a PDF image in a groff document and so have > been using > groff -Tpdf > to do so. > But I find that my \m[red] etc color commands are not recognised (and there > are error messages.. > Some work on Google led me to the

Re: [Groff] pdfmom question

On Tue 01 Nov 2016 15:56:49 Peter Schaffter wrote: > This is a question for Deri James. > > Is there some reason why, in pdfmom, the system() call to groff at > line 125 does not include '$preconv' in the first pass? > > I've been working on flexible vertical whitespace

[groff] 02/02: gropdf remaps characters to position 13 (#48986)

deri pushed a commit to branch master in repository groff. commit 4b980242c26d6369cf988a9bd4694efdd50320ec Author: Deri James <d...@chuzzlewit.myzen.co.uk> Date: Tue Nov 1 23:05:33 2016 + gropdf remaps characters to position 13 (#48986) * src/devices/gropdf/grop

[bug #48986] gropdf remaps characters to position 13

Update of bug #48986 (project groff): Open/Closed:Open => Closed ___ Follow-up Comment #1: I have accepted your patch, thank you. It will shortly be included in the repository.

[bug #48835] preformatted text does not retain adjacent spaces using ps, pdf, html output devices

Follow-up Comment #1, bug #48835 (project groff): In regards to ps and pdf, (I don't know anything about html), spaces are not "printed" they are just measured gaps between items which are printed. In your example you are using the proportional Times Roman font - the default. The width of a space

Re: [Groff] Times-Roman v. Nimbus Roman No9 L Regular.

On Thu 05 May 2016 15:13:34 Ralph Corderoy wrote: > Hi Deri, > > > One way to add the URW fonts post groff install is to run the > > BuildFoundries program after you have cd'd into the devpdf font > > directory. Within this directory you should find a file called > >

Re: [Groff] .if !dTS - GNU extension?

ith a little arm chip running in it. Its much faster on my main server. You can get a very crude index of all the man pages on this little server with:- http://chuzzlewit.co.uk/ Cheers Deri

Re: [Groff] Times-Roman v. Nimbus Roman No9 L Regular.

e the parameter of a full stop). This should regerate the download file and add new fonts which start U-*, so Werners "-P-y -P-U" should work. Hope this helps. Cheers Deri BuildFoundries Description: Perl program

Re: [Groff] Using Make with pdfmom

gt; there. Is this the only way I can do this, or am I missing some option I > could use instead? In the current git log you should see:- == commit 0fd1ab8c1c07c7c9bfadd30042a617e7f855d13e Author: Deri James <d...@ch

Re: [Groff] Groff command-line argument strangeness

It needs to pass the switch to grops because it affects the searching for eps files, which gropdf does not accept. I will add code to ignore the switch in future, or use it to search for pdfs which are to be imbedded. Thanks for the heads up. Cheers Deri

Re: [Groff] Tbl - repeating column titles

etrieve the pdf with "clickable links", here:- <http://chuzzlewit.co.uk/utp_book-1.1.pdf> It is the same content but updated be more easily viewed as a pdf. Cheers Deri

Re: [Groff] Mission statement PDF

using current groff tools (particularly current gropdf) to see if the error is repeated. Deri

Re: [Groff] Mission statement PDF

from original source with current tools? Cheers Deri

Re: [Groff] How remove title?

, or even if the title given is simply a space. I've fixed the issue with the title coming out as LS(1) by removing the quotes, so it is LS(1) now, but I don't think that's what you want. Cheers Deri

Re: [Groff] How remove title?

On Tue 16 Jun 2015 11:49:23 Steffen Nurpmeso wrote: Anyway i finally have to say that it is a pity that, instead of (making the engine as such multi-pass and) instrumenting the macros for different output formats that need meta-information, and extending the macros sets to include more

Re: [Groff] How remove title?

On Fri 12 Jun 2015 23:23:14 Peng Yu wrote: Hi, I use the following command to generate a pdf file from a manpage. But the pdf file has title Untitled. I want to unset it via groff. But I don't see an option to set title to be null. Would you please let me know how to unset the title with

Re: [Groff] How remove title?

need to use a decompressor as well: Cheers Deri pdfman Description: Perl program

Re: [Groff] can't translate character code 229 to special character `oa' in transparent throughput

On Wed 10 Jun 2015 17:51:23 mikkel meinike wrote: Deri you talk about an error in the source code of pdfmom? Anyway I made this work. I found and old document almost simular that did not make that mistake. Than I copy/pasted and edite the contet of the old doc to look like the new doc

Re: [Groff] can't translate character code 229 to special character `oa' in transparent throughput

document (udspil)!! Cheers Deri

Re: [Groff] Business Graphics

On Sun 24 May 2015 12:53:07 Ralph Corderoy wrote: Hi Deri, Its purpose is to provide inline business type graphs for groff. I know we have grap which seems to be aimed at the more mathematical end of graphs, I'm aiming for the sort of graphs which a typical office spreadsheet might

Re: [Groff] Business Graphics

ps as well as -T pdf. Cheers Deri

[bug #44891] gropdf use of Compress::Zlib is not documented as a dependency

Follow-up Comment #3, bug #44891 (project groff): I have pushed a fix to git please can you test on Solaris. ___ Reply to this item at: http://savannah.gnu.org/bugs/?44891 ___ Message sent

[groff] 01/01: Fix Savannah bug #44891.

deri pushed a commit to branch master in repository groff. commit cc4e05054c93177b0574154cc78af06a1b4cc7a6 Author: Deri James d...@chuzzlewit.myzen.co.uk Date: Wed Apr 22 15:13:06 2015 +0100 Fix Savannah bug #44891. * src/devices/gropdf/gropdf.pl: If module Compress::Zlib

[bug #44903] mom 2 column output is misplaced

Follow-up Comment #1, bug #44903 (project groff): I've sent Peter an email with further information. ___ Reply to this item at: http://savannah.gnu.org/bugs/?44903 ___ Message sent via/by

[bug #44891] gropdf use of Compress::Zlib is not documented as a dependency

Follow-up Comment #2, bug #44891 (project groff): Gropdf uses Zlib in two places, once when writing a stream, and again when reading a stream (happens when you insert a graphic which is a pdf file). In both cases I don't think it is absolutely necessary, if you use the -d flag pdfs are not

[groff] 01/01: Fix Savannah bug #44890. Patch by Peter Bray.

deri pushed a commit to branch master in repository groff. commit a989e8d4562b6395753661b3e5836b528e8aa9e6 Author: Deri James d...@chuzzlewit.myzen.co.uk Date: Tue Apr 21 21:16:48 2015 +0100 Fix Savannah bug #44890. Patch by Peter Bray. * font/devpdf/devpdf.am: Don't

[bug #44890] [git@2015_04_10] find's -maxdepth option is not portable

Update of bug #44890 (project groff): Open/Closed:Open = Closed Planned Release:None = 1.22.4 ___ Follow-up Comment #2: Patch installed. Many

Re: [Groff] Problem with tables changing setting.

. If you drop the -mspdf it behaves better. If you need the ms macro then Tadziu has given the answer. Cheers Deri

[groff] 01/01: * src/devices/gropdf/gropdf.pl: Was not handling the final glyph correctly in the standard fonts which are not embedded. They actually have 257 glyphs (0-256) not 256 as I'd assumed,

deri pushed a commit to branch master in repository groff. commit 96b1a1b0c9840f5922baf3e6e9f28f1dea6e3dc6 Author: Deri James d...@chuzzlewit.myzen.co.uk Date: Wed Mar 11 17:09:55 2015 + * src/devices/gropdf/gropdf.pl: Was not handling the final glyph correctly in the standard

Re: [Groff] gropdf ellipsis (u+2026) breaks with several fonts

. The attached patch should update gropdf 1.22.2 to the latest. Please can you test. Cheers Deri diff --git a/src/devices/gropdf/gropdf.pl b/src/devices/gropdf/gropdf.pl index 9a8288c..8103914 100644 --- a/src/devices/gropdf/gropdf.pl +++ b/src/devices/gropdf/gropdf.pl @@ -467,7 +465,7 @@ sub GetObj

[groff] 01/01: * src/devices/gropdf/gropdf.pl: Fix problem remappiing ellipsis (affects all glyphs 255).

deri pushed a commit to branch master in repository groff. commit 8d510f0ddf224547dcc0200fc313ce97e78dde3a Author: Deri James d...@chuzzlewit.myzen.co.uk Date: Wed Mar 11 11:56:31 2015 + * src/devices/gropdf/gropdf.pl: Fix problem remappiing ellipsis (affects all glyphs 255

Re: [Groff] ASCII dash in UTF-8 locale

On Fri 23 Jan 2015 08:39:20 Anthony J. Bentley wrote: Heirloom troff and groff both render \- as en dash, not minus sign, in PDF output. If you use groff's native pdf driver (-Tpdf) I believe minus is rendered, can be searched for and copy/pasted. The postscript driver also outputs a minus

Re: [Groff] Introduction to groff in french

. Your example is UTF-8 so does need the -k flag. Cheers Deri Attached my original .mom file. Thanks for your help, Regards, mon_premier_doc.mom -- Bertrand Garrigues

[groff] 01/01: Regression in commit '3fe78135c9'

deri pushed a commit to branch master in repository groff. commit feb7bacca140c0d7127e4dbe77d36082fcbf6f67 Author: Deri James d...@chuzzlewit.myzen.co.uk Date: Tue Nov 18 23:37:36 2014 + Regression in commit '3fe78135c9' Introduced problem in subroutine TextWid. Octal char

[bug #43555] gropdf: invalid format of creation/modification date in PDF metadata

Follow-up Comment #2, bug #43555 (project groff): Thanks for catching this. Change has been committed. ___ Reply to this item at: http://savannah.gnu.org/bugs/?43555 ___ Message sent via/by

[bug #43532] groff handles long .TH as overlaping in header and footer

Follow-up Comment #1, bug #43532 (project groff): I noticed this patch fixes the space at 4.3 inches, but groff_man specifies that the title line length can be changed by setting -rLT (or -rLL) to a different width, so should not this patch take this into account. (NB I have not actually tested

Re: [Groff] release ready

disagree.) Deri can certainly give more details why spaces are not allowed, contrary to grops. Axel The reason is because the gropdf download file can include directory/filenames which may include spaces (this is especially true for windows installation). So it does not make a good choice

Re: [Groff] PDFPIC macro

in a pdf document can be a different size. So to be sure of the correct MediaBox to use it is necessary to parse the complete document, find the page you are interested in (page 1 in the case of PDFPIC) and then search for the MediaBox in the page object or any of its ancestors. Cheers Deri

Re: [Groff] PDFPIC macro

that. I'd be happy to send you the same email I sent to Ulrich but the email address;- Keith Marshall keithmarsh...@users.sourceforge.net Bounces my emails and I don't think it would be of much interest to many if I sent it to the list. Cheers Deri -- Regards, Keith.

Re: [Groff] PDFPIC macro

On Sun 21 Sep 2014 20:50:37 Keith Marshall wrote: On 21/09/14 20:04, Deri James wrote: I'm glad that Ulrich has answered you, it was not my place to identify the person as they contacted me privately, Sure, but we must strenuously discourage such private communications; how on earth can

Re: [Groff] PDFPIC macro

On Thu 18 Sep 2014 09:42:23 Peter Schaffter wrote: On Thu, Sep 18, 2014, Keith Marshall wrote: On 17/09/14 22:22, Peter Schaffter wrote: Yes. The way groff stands now, I'm uneasy relying on external tools and .sy for anything but local, user-written macros. There's precedent,

Re: [Groff] PDFPIC macro

used in a windows environment and I have no reason to believe the subset of the code used to retrieve the MediaBox of a pdf document would not work equally well. I'd be very happy to give assistance in understanding the perl code, if you want to give it a go in C++. Deri

<    2   3   4   5   6   7   8   >