Hi Oliver,
On 10/05/2025 09:02, Oliver Corff via GNU roff typesetting system
discussion wrote:
> I want to write a macro which uses its argument to define a register:
>
> .mso s.tmac \" Load ms
>
> .de pageno
> \\$1:\c \" displayed as intended
> .nr xx \\$1 \" register is not se
Hi Luis,
On 27/04/2025 08:26, Luis Rivera wrote:
> Il giorno mer 16 apr 2025 alle ore 05:41 Keith Marshall
> ha scritto:
>> I don't yet know where pdfroff/pdfmark may be hosted; FSF Savannah is a
>> likely candidate. Wherever it does end up, it will be hosted as an hg
>
Hello Luis,
Apologies for delayed reply -- I have been on vacation.
On 25/03/2025 23:26, Luis Rivera wrote:
> I've been using your pdfmark macros and pdfroff shell script for groff
> for some time now, and I've just learned that they will not be+
> distributed along with groff anymore, as of the
On 01/11/2021 13:19, G. Branden Robinson wrote:
> gbranden pushed a commit to branch master
> in repository groff.
>
> commit a0ec5ffd258b9f54daa46b88471ec837e8213ad1
> Author: Bjarni Ingi Gislason
> AuthorDate: Sun Oct 31 00:42:09 2021 +
>
> tbl(1): Say decimal "separator", not "point".
On 01/11/2021 14:01, G. Branden Robinson wrote:
> At 2021-10-24T18:53:52-0700, Larry McVoy wrote:
>> On Mon, Oct 25, 2021 at 11:58:55AM +1100, G. Branden Robinson wrote:
>>> Since I am now accused four times over of rewriting history, and
>>> moreover of violating an "absolute taboo", I must insist
On 24/10/2021 03:16, G. Branden Robinson wrote:
> [Here's another long email; Ralph may want to skip it.]
> At 2021-10-23T22:07:27+0100, Keith Marshall via Groff-commit wrote:
>> Well, I pulled, and updated my local tree, to capture Brandon's most
>> recent commits, t
Ref: https://savannah.gnu.org/bugs/index.php?55107
On 01/10/2021 01:10, Deri wrote:
> I did try to help Keith with this previously, but I was mildly "told
> off" (on list) for sending my help off list. I've learned my lesson.
Thanks, Deri.
IIRC, the reason for the "mild telling off" was that, by
On 06/10/2021 15:03, G. Branden Robinson wrote:
> At 2021-10-05T08:56:24+0100, Keith Marshall wrote:
>> Why do you waste your time, indulging in such asinine whimsy? Why
>> introduce a commit which contributes absolutely zero value?
>
> I object to your characterization
Seriously, Branden?
On 03/10/2021 14:20, G. Branden Robinson wrote:
> gbranden pushed a commit to branch master
> in repository groff.
>
> commit fc6989ae19146294bcf27d08453c6005a8b363c5
> Author: G. Branden Robinson
> AuthorDate: Sun Oct 3 22:48:48 2021 +1100
>
> ChangeLog: Wrap long lines
Hi Branden,
On 02/10/2021 19:14, G. Branden Robinson wrote:
> gbranden pushed a commit to branch master
> in repository groff.
>
> commit 256d165f40d8a630dacc8bcfc749088fa65152fb
> Author: G. Branden Robinson
> AuthorDate: Sat Oct 2 15:33:18 2021 +1000
>
> groff_ms(7): Update table of conte
On 21/09/2021 13:34, Heinz-Jürgen Oertel wrote:
I did some more research. The result, it's not "pdfinfo" it is
Imagemagick "convert". I mostly use jpg file converted to pdf by
"convert".
Since your graphic originates as JPG, is there any particular reason why
you cannot convert to EPS, and use
On 20/09/2021 19:22, Dave Kemper wrote:
Hi Heinz-Jürgen,
Thanks for debugging and submitting a fix for this problem!
Except that it's not really the most appropriate solution; that was
proposed four years ago...
In general, when proposing changes to the groff code base, it's best
to open a
On 05/09/2021 18:34, Ingo Schwarze wrote:
> Keith Marshall wrote on Sun, Sep 05, 2021 at 04:49:41PM +0100:
>
>> If you would like my proposal, then it would be that we make one final
>> commit, for each extant ChangeLog file, in which we add a log message to
>> the e
On 05/09/2021 14:42, G. Branden Robinson wrote:
> At 2021-09-05T14:25:14+0200, Ingo Schwarze wrote:
>> Keith Marshall wrote on Sat, Sep 04, 2021 at 10:32:05PM +0100:
>>> I see a complete lack of consistency in this. Some commits
>>> duplicate the entire ChangeLog entry
I see a complete lack of consistency in this. Some commits duplicate
the entire ChangeLog entry in the ChangeLog file, and in the Git log
message; some update the ChangeLog file, but use only a summary line as
the Git log message, while some place the entire ChangeLog entry into
the Git log messag
On 28/08/2021 17:14, Douglas McIlroy wrote:
> A small anomaly. Consider
>
> .de .
> .tm Hi
> ,..
> ..
I'm guessing that the comma, before the first ".." is an unintended
introduction?
> The second .. emits "Hi". This fragment also emits "Hi":
>
> .de end end
> .tm Hi
>
ent the
issue by using a macro such as in the attached sanitize.tmac, but is
there a more elegant alternative?
--
Regards, Keith.
.ig
sanitize.tmac
Copyright (C) 2021 Free Software Foundation, Inc.
Written by Keith Marshall (keith.d.marsh...@ntlworld.com)
This file is part of groff.
grof
Hi Branden,
On 29/07/2021 10:45, G. Branden Robinson wrote:
> I just pushed the following commit--I've got a problem I'm having a
> devil of a time figuring it out.
>
> As noted below, I caused a regression a couple of days ago, but one that
> was hard to see since it didn't break the build. The
On 20/07/2021 15:19, James K. Lowden wrote:
> [...snip...]
>
> A question came up on reddit that might act as a tie-breaker for
> you. (!) It was: how to automatically increment a list with letters?
> I don't use the style much, but if you want
>
> 1. foo
> a) bar
>
On 16/07/2021 20:50, James K. Lowden wrote:
> On Fri, 16 Jul 2021 04:48:03 +1000
> "G. Branden Robinson" wrote:
>
>> XN is not a part of any _ms_ implementation I'm aware of, not even
>> groff's. It does not appear in 4.2BSD ms or Version 10 Research Unix,
>> either.
>>
>> In the groff system, X
On 14/06/2021 19:32, G. Branden Robinson wrote:
> [...snip...]
> diff --git a/src/preproc/tbl/tbl.1.man b/src/preproc/tbl/tbl.1.man
> index 370f384..5f981cd 100644
> --- a/src/preproc/tbl/tbl.1.man
> +++ b/src/preproc/tbl/tbl.1.man
> @@ -1025,6 +1025,20 @@ should always be called before
> .RI ( gr
Apologies for any confusion, which this may have caused:
On 09/06/2021 23:28, I wrote:
> he should have:
>
>.de SOLUTION
>. if (\\n[s] == 0) .ig SOLEND
>. br
>..
>.de ENDSOL
>. \" Any clean-up required, at end of solution.
>..
Of course, my ENDSOL macro should,
On 09/06/2021 19:35, Oliver Corff wrote:
> All .dot requests MUST be at the beginning of the line; in your code
> example, the dot is not recognized.
No, that is not so. The issue with Hans' example, (apart from the under
escaping of register references within his macro definitions, as Peter
has
On 19/04/2021 09:47, Peter Schaffter wrote:
> On Mon, Apr 19, 2021, Bjarni Ingi Gislason wrote:
>> Bug #60403 (closed) unified the writing of "point-size" to "point
>> size".
>>
>> The problem is,
>> that this coinage does not make sense.
>>
>> The "point" in this compound,
>> is a name of a
On 17/12/2020 14:37, Dorai Sitaram via wrote:
> Wow, this (Oliver's suggestion) actually works. ...
I don't know why I even bother!
https://lists.gnu.org/archive/html/groff/2020-12/msg00053.html
On 15/12/2020 20:52, Dorai Sitaram via wrote:
> Thanks, Oliver. I'm using
>
> GNU groff version 1.23.0.rc1.69-8e09f
>
> Tried your exact same file, and it just whizzes to completion without
> prompting for my input. Also on groff 1.22.4.
It works for me, on Manjaro's (Arch) groff-1.22.4, but on
On 09/12/2020 22:42, G. Branden Robinson wrote:
> We can probably just switch to using GW, and I think we should. MINGW
> is too easy to read incorrectly (as "Ming W"), and to confuse with
> "Minimalist GNU for Windows". (I'll be annoyed if the semantics
> of GW and MINGW differ, but I suspect it
On 29/09/2020 16:27, James K. Lowden wrote:
> That would work, but IMO wouldn't be very convenient. I was thinking
> along the lines of
>
> .SH id=foo class=bar
> Your title here
That would conflict with groff's existing SH usage; from groff_ms(7):
> .SH [xx]
> Unnumbered subheading.
On 22/06/2020 06:56, B 9 wrote:
> Oh, thank goodness. So, I'm not the only one. So, I guess that brings
> me back to my original question: Can groff make links clickable when
> rendering to PDF? And, I guess the answer is, No, not at the moment.
Actually, it can ... and it does! (You can see that
Hi Jeff,
On 24/02/19 01:04, Jeff Conrad wrote:
> I’m getting strange behavior with devutf8 on Windows.
I notice that Eli has already offered some useful insight; I may be able
to add some more, but I won't have time before the end of this month.
--
Regards,
Keith.
On 13/02/19 21:00, Doug McIlroy wrote:
> I run groff on windows a lot, but via cygwin, which emulates
> Unix. I am inclined to think that if you like the groff toolset,
> you are likely to want other Unix capability, too, and thus
> gravitate towards facilities like cygwin.
>
> I take it that Keit
On 12/02/19 23:19, Eric S. Raymond wrote:
> Keith Marshall:
>>> There has been no work on that support since 2005, 12 years ago.
>>
>> So, it has been stable for 12 years (actually 14 years); that does
>> *not* mean that it is no longer relevant, yet you want to
On 12/02/19 21:32, Eric S. Raymond wrote:
> Having further examined the groff sources, I see that there is one
> thing the POSIX/C99 cleanup would have to drop: MS Visual C support.
Which, in consequence, would utterly break support on MS-Windows; an
excellent strategy for branding yourself as "pu
On 22/08/18 17:42, Heinz-Jürgen Oertel wrote:
> I'm using groff and -Tpdf and pictures included with .PDFPIC.
> PDFPIC always crashes. The reason is, that pdfinfo has in its stdout
> text not only text but also a '\0' char. The effect is, that pdfinfo
> | grep gives an error message instead of the
On 26/06/18 14:27, G. Branden Robinson wrote:
> Can someone tells me why this happens? And, more mysteriously, why it
> only _sometimes_ happens?
I guess its the placement of padding space, when formatting fully
justified ASCII, that's puzzling you? AIUI, to avoid rivers of padding
space, groff
On 05/05/18 12:40, G. Branden Robinson wrote:
> At 2018-05-05T11:51:00+0100, Keith Marshall wrote:
>> On 05/05/18 10:48, G. Branden Robinson wrote:
>>> (Incidentally, I share your preference for putting type qualifiers
>>> [as opposed to storage classes] _after_ the type
On 05/05/18 10:48, G. Branden Robinson wrote:
> (Incidentally, I share your preference for putting type qualifiers
> [as opposed to storage classes] _after_ the type name itself. It
> makes complex declarations easier to understand.)
Personally, I consider that to be a poor choice ... especially
On 20/04/18 19:19, John Gardner wrote:
> And as if that weren't enough, the renderer includes first-class
> support for Deri Jame's pdfmark macros ...
Begging your pardon ... who's pdfmark macros?
On 10/01/18 22:02, Stephanie Björk wrote:
> Huh? Why does it look so different?
https://www.logaster.com/blog/att-logo/
On 20/11/17 11:35, Ralph Corderoy wrote:
> Hi Branden,
>
>> Are you familiar with the U.K. practice[3] that says an abbreviation
>> doesn't get a period if the abbreviation ends with the final letter of
>> the abbreviated word?
>
> Nothing has been brought to a stop, unlike, say, Prof. Moriarty.
Hi Deri,
I have what appears to be a working build, now; (see below).
On 11/10/17 10:09, Keith Marshall wrote:
> On 09/10/17 23:44, Deri James wrote:
>> The attached archive holds some samples of two types of pdfs, either
>> produced by gropdf or produced by cairo software.
On 09/10/17 23:44, Deri James wrote:
> On Mon 09 Oct 2017 09:10:18 Keith Marshall wrote:
>> Perhaps, you could:
>>
>> $ make clean
>> $ make CFLAGS=-DDEBUGGING
>>
>> and check your failing PDFs again, so we can see whatever
>> unexpected token se
Hi Deri,
Thanks for trying it out.
On 09/10/17 01:21, Deri James wrote:
> Some pdfs I have tried fail with "syntax error".
That's yacc's default behaviour, when the sequence of tokens returned
by the lexer doesn't conform to its notion of a valid grammar -- either
the order isn't as expected,
Resurrecting a three year old thread ...
On 21/09/14 05:38, Werner LEMBERG wrote:
>>> A good starting point may be to implement a C/C++ library function,
>>> to extract the MediaBox properties; that would open the gate to a
>>> possible pdfbb request, which gtroff.exe could process internally.
>>
On 05/10/17 20:40, Tadziu Hoffmann wrote:
>> Another strange thing is that, in case of using mixed
>> Russian/Latin symbols in pic and tbl objects, the Latin
>> letters and numbers become mis-positioned.
>> I wonder what I am possibly do wrong. The GROFF version is 1.22.2
>> on Ubuntu 14.04. The c
Kristaps,
On 08/09/17 00:01, Kristaps Dzonsons wrote:
> Deri, thanks for the note! I'll switch the examples and notes to use
> pdfroff for pdf output. This also solves for the PSPIC problem, where I
> could use PSPIC for -Tps, but not for -Tpdf. Was "-mspdf" intentional,
> by the way? I can't
Hi Mikkel,
On 24/08/17 17:52, mikkel meinike wrote:
> The eps I used was generated with
>
> sam2p
That's the same tool that was the subject of the Debian bug report, to
which Ralph pointed you (indirectly) earlier; it embeds a malformed:
%%BeginData:
record into the generated EPS file.
> N
Hi Ralph,
On 24/08/17 13:43, Ralph Corderoy wrote:
> It seems the macro .PSPIC is present without asking for it. I don't see
> groff_tmac(5) pointing this out.
It appears to me that it does:
$ man 5 groff_tmac
...
pspic
A single macro is provided in this file, PSPIC, to include a
On 23/07/17 13:39, Ralph Corderoy wrote:
>> What's the rationale for choosing UTF-16 in the first place?
>
> History. Microsoft plumped for UCS-2, both UCS-2BE and UCS-2LE
> I think.
That's not as I recall it: UCS-2, yes, but always UCS-2LE, (since their
focus was on Intel x86 -- a little-endia
On 23/07/17 12:49, Ralph Corderoy wrote:
>> The simple reality is that, if we wish to preserve groff's current
>> utility on MS-Windows, insistence on UTF-8 only as an input encoding
>> is not a viable option.
>
> I understand the Windows API has moved to UTF-16, but does that mean
> text file on
On 22/07/17 11:44, Ralph Corderoy wrote:
>> If the order of the groff pipeline is responsible for Erich's problem
>> (soelim needs to come before preconv), is this something to change or
>> something to document?
>
> Change has been mooted in the past, including by Werner.
> Some old relevant thre
On 22/07/17 21:17, Ted Harding wrote:
> On Sat, 2017-07-22 at 15:32 -0400, Mike Bianchi wrote:
>> On Sat, Jul 22, 2017 at 06:19:29PM +0100, Keith Marshall wrote:
>>> On 22/07/17 15:06, John Gardner wrote:
>>>> ... Can I semi-seriously implore the world to only use
On 22/07/17 15:06, John Gardner wrote:
> I was bitten by preconv(1) quite recently, actually. Gonna back Ingo
> here. Can I semi-seriously implore the world to only use UTF-8, and
> pretend other encodings don't exist?
Not really going to happen, for as long as MS-Windows remains the
dominant OS
On 29/11/16 22:26, mikkel meinike wrote:
> Can anyone find out what is causing the little "... /2" in the lower
> right corner of page one in this mom-generated document?
Mom's default letter style?
http://www.schaffter.ca/mom/momdoc/letters.html
It indicates that your letter continues on to page
On 26/02/16 15:56, Anton Shterenlikht wrote:
> I've a document that is built with pdfroff.
> I use mspdf macro package and also PSPIC.
>
> This results in a document with 3 extra
> pages after the cover page, where all PostScript
> files, mentioned in PSPIC requests are shown:
>
> https://sourcef
On 29/01/16 12:50, Anton Shterenlikht wrote:
> With pdfroff I get
>
> macro error: RP is not allowed after the first page has started
>
> even when RP is used before TL, AU, etc.
>
> If I don't use RP, then the title info appears
> after TOC and references, which is not great.
> How can I make
On 27/01/16 18:46, Larry Kollar wrote:
>
>> Anton Shterenlikht wrote:
>>
>> I discovered pdfmark macro today.
>> I like it, and would like to use it's
>> facilities for hyperlinking and automatic
>> table of contents.
>>
>> However, pdfmark.pdf included in groff-1.22.2
>> stops just at this point
On 17/12/15 22:10, Werner LEMBERG wrote:
>>> Well, the authors don't matter in a copyright notice. The
>>> important bit is the copyright holder, and this is the FSF,
>>> regardless of the license.
>>
>> That seems like a decidedly U.S.-centric viewpoint to me, in clear
>> violation of the Berne
On 26/10/15 13:12, Dorai Sitaram wrote:
> Incidentally, is there a way to tell from inside a document whether
> it is being processed by pdfroff or groff -Tps? In both cases, the
> string register .T is 'ps'.
Not really; pdfroff is just a shell script, which runs groff -Tps
multiple times, (to re
[adding the list back in cc -- please keep it there]
On 26/10/15 05:44, Koz Ross wrote:
> Thanks Keith - good to know I'm already finding bugs. :P
>
> What does the '-P-pa4' do here? I assume it's to do with paper sizing?
Yes. It's to ensure that both troff and its grops postprocessor agree
on
On 26/10/15 04:28, Koz Ross wrote:
> I've just discovered groff, and am quite impressed! However, for some
> reason, I'm having an odd issue. I have a folder called 'src' where I
> plan to store chapters of my book, and I want to add it to the search
> path for stuff to include into the final docum
Hi Ralph, Grégoire,
On 24/10/15 11:12, Ralph Corderoy wrote:
> Hi Grégoire,
>
> Keith wrote:
>>> OK, I reinstalled groff-base 1.22.3-1 and groff 1.22.3-1 with dpkg
>>> -i.
>>
>> Those are binary packages.
>>
>>> The patch is made for /contrib/glilypond/glilypond.pl The new groff
>>> works fine,
On 23/10/15 10:13, Grégoire Babey wrote:
> OK, I reinstalled groff-base 1.22.3-1 and groff 1.22.3-1 with
> dpkg -i.
Those are binary packages.
> The patch is made for /contrib/glilypond/glilypond.pl The new groff
> works fine, but now, I cannot find the /contrib directory:
You need the source p
On 16/10/15 23:55, Grégoire Babey wrote:
> gregexp@greg-desktop:~/.local/share/Trash/files/groff-1.22.3$ patch -p0
> < /home/gregexp/Bureau/patch1glilypond
> can't find file to patch at input line 5
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
>
On 24/09/15 18:47, Ralph Corderoy wrote:
>> As Nigel mentioned this is e.g. documented in "Unix Text
>> Processing", Dale Dougherty & Tim O'Reilly page 224 (available
>> at http://www.oreilly.com/openbook/utp/).
>
> It may pre-date your time on this list, but some of us here
> re-entered the book
On 15/09/15 18:49, Colton Lewis wrote:
> I've included a diff of the standard s.tmac and my changes.
Unfortunately, your submitted diff is not in a suitable format;
it needs to be patch compatible, generated by 'diff -u ...' (for
preference), or if your diff doesn't support that, 'diff -c ...'.
On 14/08/15 14:56, Ralph Corderoy wrote:
>>> man1_MANS += $(PREFIXMAN1)
>>> man1_MANS += $(PREFIXMAN5)
>>> man1_MANS += $(PREFIXMAN7)
>>>
>>> are incorrect, it should be of course
>>>
>>> man1_MANS += $(PREFIXMAN1)
>>> man5_MANS += $(PREFIXMAN5)
>>> man7_MANS += $(PREFIXMAN7)
>>
>> S
On 13/08/15 22:19, Bertrand Garrigues wrote:
> ... The only thing is that after the 'else' the 3 lines
>
> man1_MANS += $(PREFIXMAN1)
> man1_MANS += $(PREFIXMAN5)
> man1_MANS += $(PREFIXMAN7)
>
> are incorrect, it should be of course
>
> man1_MANS += $(PREFIXMAN1)
> man5_MANS += $(P
On 08/07/15 19:30, Peter Schaffter wrote:
> Hi, all.
>
>>> Are you aware that somenthing has happened to the mission statement
>>> PDF and that it is totally undreadable?
>>>
>>> http://www.gnu.org/software/groff/groff-mission-statement.pdf
>>
>> Uh, oh, no, this is new to me. Thanks for the repo
On 10/06/15 15:55, mikkel meinike wrote:
>> What were the page structure errors? I'm guessing that you may need a
>> --no-toc-relocation somewhere among the pdfroff command options?
>
> Just tried: Well table of content is still left ind end of the doc
That could be because mom doesn't provide s
On 10/06/15 15:19, mikkel meinike wrote:
> With this command
>
> $ pdfroff -mom -mpdfmark udspil.mom >udspil.pdf
>
> I am able to compile the doc without the error massages. But now there are
> some mistakes in the page structure.
What were the page structure errors? I'm guessing that you may n
On 11/04/15 00:07, Bertrand Garrigues wrote:
> Note that the problem could be reproduced on any environment
> by forcing the use of gnulib's replacement function, by passing the
> option:
>
> gl_cv_func_wcwidth_works=no
>
> to configure.
Indeed, since it is a library linking order error.
It
On 03/02/15 12:05, Anton Shterenlikht wrote:
> In the "UNIX processing handbook", 1988, there is a mention of .NP
> macro for ms macros.
I assume you mean the reference on page 105, (in the PDF version of UTP,
as produced by various subscribers to this list)? Whilst it could have
been more clearl
On 22/11/14 10:47, Werner LEMBERG wrote:
>
>> Out of curiosity, why did you prefer this:
>>
>> +#if defined(__MSDOS__) || (defined(_WIN32) && !defined(__CYGWIN__))
>> +void normalize_for_lf (string &fn)
>> +{
>> + int fnlen = fn.length();
>> + for (int i = 0; i < fnlen; i++) {
>> +
On 20/11/14 18:47, Werner LEMBERG wrote:
>>> Sorry for the delayed answer. Your patch looks fine, and I'm going
>>> to apply it soon. Thanks a lot.
>>
>> Great, thanks. Now I can publish the binary with that patch and
>> claim that it was accepted upstream.
>
> Now committed, with minor fixes.
On 12/11/14 21:51, Carsten Kunze wrote:
> Hello,
>
> the mdoc macros display for
>
> .Ex -std uuencode uudecode b64encode b64decode
>
> EXIT STATUS
> The uuencode, uudecode, b64encode, and b64decode utilities [...]
>
> I think the "," before "and" is not intended.
It is both intended, and
On 11/11/14 19:20, Ralph Corderoy wrote:
> Hi Eli,
>
> Thanks for the explanation.
>
>>> Am I right in thinking that Windows' API is as happy with a/b/c as
>>> a\b\c
>>
>> That's correct.
>>
>>> and so wrappers around the code that's cooking up the a\b\c in the
>>> first place could transliterate
On 08/11/14 20:43, Eli Zaretskii wrote:
>> Any chance to have some code in `nonposix.h' to avoid this?
> Please suggest how. do_file more often than not accepts strings given
> by 'const char *', so it is not possible to modify the string itself.
> What else can I do?
Maybe make the *implementati
On 06/11/14 17:37, Anthony J. Bentley wrote:
> Should nroff render `` '' as typographical double quotes instead of
> literal ASCII values?
No, definitely not, IMO. It should render them exactly as what the
input says is intended, i.e. two grave accents and two apostrophes. If
a typographic repre
On 06/11/14 13:57, Werner LEMBERG wrote:
> groff uses different quotes depending on -Tascii or -Tutf8:
Naturally. UTF-8 is a multibyte character encoding; ASCII is strictly
single byte (using only seven bits).
> devascii: lq "
Which is ASCII code 34 (0x22)
> devlatin1: lq "
Again,
On 06/11/14 12:30, Anthony J. Bentley wrote:
> By ASCII I meant specifically ASCII output. I use UTF-8 terminals and
> the patch was intended to improve how the nroff output looks in that case.
That you use UTF-8 terminals is completely irrelevant; you are confusing
two distinct concepts here -- a
On 03/11/14 20:16, Dale Snell wrote:
> On Mon, 03 Nov 2014 16:36:04 +
> Ralph Corderoy wrote:
>> BTW, your mombog.mom had a blank line at the start and the comments
>> were lines starting `\#' rather than `.\#'. One or the other might
>> have an affect on your attempt at A3 in mom, I don't kno
Hi Peter,
On 19/10/14 22:36, Peter Schaffter wrote:
> PTPi pushed a commit to branch master
> in repository groff.
>
> commit 5c011f038148ae521254057179032e69c7c08217
> Author: Peter Schaffter
> Date: Sun Oct 19 17:33:28 2014 -0400
>
> Add shipped_htmldoc stuff to configure
Did you edit
On 14/10/14 05:01, Werner LEMBERG wrote:
> with current git I get the following error while running a normal
> build:
>
> [...]
>
> /usr/bin/sed: -e Ausdruck #1, Zeichen 29: Nicht beendeter `s'-Befehl
Oops! Sorry about that. I really don't know how I missed it; what I
committed seems not t
On 12/10/14 19:37, Werner LEMBERG wrote:
>> I too have a couple of trivial patches for pdfroff: [...]
>>
>> I guess it would be good to get these into the release, but I'll
>> need a day or two to finalize them.
>
> No problem :-)
I've now pushed my changes, and updated NEWS accordingly.
--
Reg
On 11/10/14 20:45, Peter Schaffter wrote:
> Werner --
>
> On Sat, Oct 11, 2014, Werner Lemberg wrote:
>> After Bernd's commits to fix the IPC issue, I can do `make dist' and
>> distribute it. Before doing this, however, I want to wait a few days
>> so that you can test and check whether everythin
On 30/09/14 07:34, Werner LEMBERG wrote:
>
>>> This is very nice, thanks! For my taste, the comments are a bit
>>> excessive, but I guess this is probably only me who thinks so :-)
>>
>> I've always favoured a verbose commenting style, since I learned to
>> write FORTRAN-66, way back in the early
On 29/09/14 21:20, Werner LEMBERG wrote:
>
>> I've refactored the appropriate code, in src/roff/troff/input.cpp,
>> with a view to accommodating this; see patch attached. While I've
>> not yet progressed any implementation for PDF handling, I have
>> indicated the point at which it should be invo
On 21/09/14 15:29, Keith Marshall wrote:
> On 21/09/14 11:52, Deri James wrote:
>> On Sun 21 Sep 2014 06:38:42 Werner LEMBERG wrote:
>>>>> A good starting point may be to implement a C/C++ library
>>>>> function, to extract the MediaBox properties; that
y
logging it as a significant change; (it is no such thing of course, for
all you've actually done is reflow existing text to a slightly shorter
line length, which IMO...
> +
> 2014-09-24 Keith Marshall
>
> Refactor psbb line input function; avoid a buffer overrun
On 25/09/14 10:51, Werner LEMBERG wrote:
>
>> keithmarshall pushed a commit to branch master
>> in repository groff.
>
> Thanks!
You're welcome. There's still more to do, of course.
>> -??-?? Keith Marshall
Yeah. I noticed this myself, but n
On 24/09/14 17:28, Werner LEMBERG wrote:
> Honestly, I would like it to be
>
> // ps_get_line(): collect an input record from a PostScript file.
> // ...
> //
> static
> int ps_get_line(char *buf, ...
>
Okay. That's how I'll do it, then. (FWIW, for MinGW I normally put the
comment b
On 24/09/14 10:41, Werner LEMBERG wrote:
>>> What is `+ve'?
>>
>> I've always understood it to be universally accepted -- at least in
>> mathematical, scientific, and engineering circles -- as an
>> abbreviation for "positive".
>
> I'm quite firm in reading such stuff, and up to now I've *never* s
On 24/09/14 10:41, Werner LEMBERG wrote:
>> Should I also s?\*?/?g, on the lead-in to the function header
>> comment block, (in addition to introducing each subsequent line with
>> the C++ style '//')?
>
> Even after reading it twice I'm not exactly sure what you mean :-)
> Please show an example.
On 24/09/14 05:57, Werner LEMBERG wrote:
>> I believe I've matched the existing style of code layout, (which
>> isn't entirely to my personal taste), but is the comment style
>> acceptable? (I've annotated my changes considerably more
>> comprehensively than the original).
>
> I don't really mind
geset patch
# Parent 7fde8642cc78b42ba10b622cbfdff7a6737c5412
ChangeLog:
-??-?? Keith Marshall
Refactor psbb line input function; avoid a buffer overrun.
* src/roff/troff/input.cpp (ps_get_line): Refactor, to avoid the
overhead of character look-ahead and push-back on CR stream input.
Add new `d
On 21/09/14 20:50, Keith Marshall wrote:
>> I'd be happy to send you the same email I sent to Ulrich but the
>> email address;-
>>
>> Keith Marshall
>>
>> Bounces my emails
>
> Strange. It is working, but may be faulting intermittentl
gt; as in gropdf, and I assumed you already had that.
I will have, if it's in the groff repository, but since I don't know
perl, I'll need some help to locate the pertinent code.
> I'd be happy to send you the same email I sent to Ulrich but the
> email address;-
>
>
On 21/09/14 11:52, Deri James wrote:
> On Sun 21 Sep 2014 06:38:42 Werner LEMBERG wrote:
A good starting point may be to implement a C/C++ library function,
to extract the MediaBox properties; that would open the gate to a
possible pdfbb request, which gtroff.exe could process intern
On 20/09/14 16:54, Keith Marshall wrote:
> A good starting point may be to implement a C/C++ library function, to
> extract the MediaBox properties; that would open the gate to a possible
> pdfbb request, which gtroff.exe could process internally.
Alternatively, we could modify the
1 - 100 of 454 matches
Mail list logo
