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
45 matches
Mail list logo
