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. Inside the two
>> sub
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 sequence is leading to the "syntax error"; only
>
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,
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 bit
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.
>>
Hi Keith,
First off, thanks for putting the effort in; you're one of the few
who's doing that and code wins over codeless argument. That said, I've
some complaints that may sway your style. :-)
In general, I dislike the verbose comments, both in number and
wordiness. Also, vertical space is p
>> // Private method functions facilitate implementation of
>> // the class constructor.
>>
>> I consider as completely unnecessary, since it is basic C++
>> knowledge how data in the `private' section works.
>
> In this case, the intent is to emphasize that there is no user,
> besides the c
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
>> 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 1970s. Today, with my failing
> 60+ year old m
I agree with Keith. I've often over the years found my plentiful
comments very helpful in going back and reviewing or modifying code.
I even comment a lot of my HTML/XHTML work as well as CSS files so
I can readily skim what I've created and refresh my memory before
attempting useful modificatio
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
Hello Keith,
Keith Marshall 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 invoked. Okay
> 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 invoked. Okay to commit,
> thus far?
This is very
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 would open
> the gate to a possible pdfbb
> Strictly speaking, in PostScript also each page can be a
> different size (though there is nothing built-in to groff to
> arrange this).
This is correct, but because it is not clear what it would mean
to include a multi-page document as a graphic, let's simply
agree it should not be done. For
On Thu, Sep 18, 2014, Keith Marshall wrote:
> On 18/09/14 14:42, Peter Schaffter wrote:
> > Would an addition to the warning emitted by the macro be sufficient
> > to alert users to the potential dangers of -U?
>
> Perhaps, but it's so much better if it can be avoided altogether. FWIW,
> in my fo
On Mon, Sep 22, 2014, Deri James wrote:
> 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 d
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 eart
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 intermittently; I'll log an
> issue with SourceForge.
https://sourc
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 we expect to effectively co-ordinate development, if
pot
On Sun 21 Sep 2014 15:29:18 Keith Marshall wrote:
> >> Good idea!
> >
> >
> >
> > Yes, it is. Someone on the list has contacted me, with a view to writing
> > the code,
>
> Who might that be? If it was off-list, then we have a problem -- we all
> need to be kept in the picture, with this sort o
On Sun, Sep 21, 2014 at 03:29:18PM +0100, Keith Marshall wrote:
> >
> > Yes, it is. Someone on the list has contacted me, with a view to writing
> > the
> > code,
>
> Who might that be? If it was off-list, then we have a problem -- we all
> need to be kept in the picture, with this sort of stu
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 21-Sep-2014 10:52:38 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 proces
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 internally.
> >
> >
> > Alternatively, we c
>> 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 existing implementation of .psbb,
> such that it
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 existing implem
Many times I've wished for a Groff Restricted Shell. Something similar
to Sendmail's smrsh. Instead of calling .sy, one could could call .grsh and
utilise a site dependent, limited set of executables in a resonably safe
environment.
On 18/09/14 23:24, Deri James wrote:
> I think that perl projects which rely on complex module interrelationships,
> do
> struggle on windows platforms, particularly where there are underlying C
> libraries with perl bindings, but if you are just using perl as a scripting
> language with no ext
Keith Marshall wrote:
|On 18/09/14 14:42, Peter Schaffter wrote:
|> Are there any tools that can be used in place of pdfinfo that are
|> Windows safe?
|
|None that I know of. Even pstopdf isn't well supported ... because it's
ImageMagick should be available even there.
The problem with usi
On Thu 18 Sep 2014 19:13:44 Keith Marshall wrote:
> Hmm. Perl. I've always shied away from it, particularly on MS-Windows.
> I know there are implementations available, but my experience of
> attempting to deploy them has always been extremely unpleasant and
> discouraging.
>
> I'd much rather
On 18/09/14 16:32, Deri James wrote:
> I do have a perl program which extracts the relevent MediaBox ArtBox TrimBox
> BleedBox CropBox, it uses the same code as the gropdf driver uses to actually
> action the:-
>
> \X’pdf: pdfpic file alignment width height line-length’
>
> So it has a similar
On 18/09/14 14:42, 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,
>>> though, in
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,
On 18/09/14 14:37, Peter Schaffter wrote:
> On Wed, Sep 17, 2014, Ralph Corderoy wrote:
>> Can't argue with a post that uses `whence'. Would be nice to see a bit
>> more `{,t,w}hither'.
>
> :)
>
>>> . sy pdfinfo @$1 | \
>>> grep "Page *size" | \
>>> sed -e 's/Page *size: *\\([[:digit:].]*\\) *x
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,
> > though, in www.tmac (PIMG), and this seems to be the be
On Wed, Sep 17, 2014, Ralph Corderoy wrote:
> Can't argue with a post that uses `whence'. Would be nice to see a bit
> more `{,t,w}hither'.
:)
> > . sy pdfinfo @$1 | \
> > grep "Page *size" | \
> > sed -e 's/Page *size: *\\([[:digit:].]*\\) *x *\\([[:digit:].]*\\).*$/\
> > .nr pdf-wid (p;\\1)\\
Keith Marshall wrote:
|On 17/09/14 21:47, Steffen Nurpmeso wrote:
|> In general it is a pity that it is impossible to generate a complete
|> document with TOC, index etc. in "safe" mode. But this is way
|> off-topic.
|
|It may be off-topic, but FWIW, it is perfectly feasible to do all of
Keith Marshall wrote:
|On 17/09/14 22:22, Peter Schaffter wrote:
|> On Wed, Sep 17, 2014, Steffen Nurpmeso wrote:
|>> I'm not in the position to say something to PDFPIC today (direct
|>> support would be pretty cool!), but there should be general tools
|>> for sh(1) (perl(1)...) that can be i
Hi Peter,
> whence processing is passed over to PSPIC.
Can't argue with a post that uses `whence'. Would be nice to see a bit
more `{,t,w}hither'.
> . sy pdfinfo @$1 | \
> grep "Page *size" | \
> sed -e 's/Page *size: *\\([[:digit:].]*\\) *x *\\([[:digit:].]*\\).*$/\
> .nr pdf-wid (p;\\1)\\n\
On 17/09/14 21:47, Steffen Nurpmeso wrote:
> In general it is a pity that it is impossible to generate a complete
> document with TOC, index etc. in "safe" mode. But this is way
> off-topic.
It may be off-topic, but FWIW, it is perfectly feasible to do all of the
above entirely in safe mode, by
On 17/09/14 22:22, Peter Schaffter wrote:
> On Wed, Sep 17, 2014, Steffen Nurpmeso wrote:
>> I'm not in the position to say something to PDFPIC today (direct
>> support would be pretty cool!), but there should be general tools
>> for sh(1) (perl(1)...) that can be included in a defined way and
>> u
On Wed, Sep 17, 2014, Steffen Nurpmeso wrote:
> I'm not in the position to say something to PDFPIC today (direct
> support would be pretty cool!), but there should be general tools
> for sh(1) (perl(1)...) that can be included in a defined way and
> used. I.e., roff "libraries".
>
> And the very
Hello,
Peter Schaffter wrote:
|Attached is a proposal for a general use PDFPIC macro. It's
|modelled after and takes exactly the same arguments as PSPIC.
|Comments and suggestions, please.
I'm not in the position to say something to PDFPIC today (direct
support would be pretty cool!), but t
> Von: "Peter Schaffter"
> Attached is a proposal for a general use PDFPIC macro. It's
> modelled after and takes exactly the same arguments as PSPIC.
>
> Since there's no groff pdf equivalent to .psbb, an external
> program is used to get the image dimensions (pdfinfo(1) from the
> poppler-uti
Attached is a proposal for a general use PDFPIC macro. It's
modelled after and takes exactly the same arguments as PSPIC.
Since there's no groff pdf equivalent to .psbb, an external
program is used to get the image dimensions (pdfinfo(1) from the
poppler-utils package). The alternative is to req
46 matches
Mail list logo
