pdfedit-support — Mailing list for pdfedit users and support for them (only for list members)

[Pdfedit-support] Fw: Different formatting with Preview

[André K. <and...@ym...>]

Hi!
I recently edited a PDF with PDFedit and it displays perfectly using Adobe Reader or Document Viewer. But when I use Mac's Preview the formatting is totally messed up.
Can you please help me handle this?
Thanks,
André.

Re: [Pdfedit-support] Newbie question:Adding text which spans +5 lines

[Southern H. <sou...@gm...>]

Correction:
Pop-up feature described earlier was a feature of Scribus. Sorry for the
confusion.

On Wed, Mar 28, 2012 at 12:11 AM, Southern Hemisphere <
sou...@gm...> wrote:

> Hello,
>
> This is my first time using Pdfedit. I need to add several lines of text
> to and an existing pdf file.
>
> Problem/Issue:
> I can add text however it runs on a continues line, eventually off the
> page. Meanwhile part of the text needs to bolded and italic. Which I can't
> do.
>
> When downloading pdfedit came across a youtube video which showed that
> text can be added via a pop-up window which also allows part of the text to
> be made bold and italic. Had a trial run and it worked. However cannot get
> it to work again (forgot how to do it) nor can I relocate that youtube
> video. Hope this makes sense.
>
> Do you have any recommendations?
>
> Regards,
> N
>

[Pdfedit-support] Newbie question:Adding text which spans +5 lines

[Southern H. <sou...@gm...>]

Hello,

This is my first time using Pdfedit. I need to add several lines of text to
and an existing pdf file.

Problem/Issue:
I can add text however it runs on a continues line, eventually off the
page. Meanwhile part of the text needs to bolded and italic. Which I can't
do.

When downloading pdfedit came across a youtube video which showed that text
can be added via a pop-up window which also allows part of the text to be
made bold and italic. Had a trial run and it worked. However cannot get it
to work again (forgot how to do it) nor can I relocate that youtube video.
Hope this makes sense.

Do you have any recommendations?

Regards,
N

Re: [Pdfedit-support] MSVCP100.dll

[Jozef M. <mis...@ho...>]

Thanks guys for answering this issue. I will try to do something about 
it in the installer later.

Cheers,
jm
> Thank you for your help. This has solved the issue now!
>
> On 29 February 2012 23:34, Jeffrey Walton <nol...@gm... 
> <mailto:nol...@gm...>> wrote:
>
>     On Wed, Feb 29, 2012 at 4:14 PM, Alister  Hood
>     <Ali...@sy... <mailto:Ali...@sy...>>
>     wrote:
>     > That's from the "standard c++ redistributables" that the home
>     page mentions
>     > aren't included.
>     >
>     > They are from Microsoft.  IIRC the installer will be called vcredist
>     > something.  They have a number of versions, and I'm not sure
>     which version
>     > that one is from, but Google will know ;)
>     Probably easier to offer a link.
>
>     x86: http://www.microsoft.com/download/en/details.aspx?id=5555
>     x64: http://www.microsoft.com/download/en/details.aspx?id=14632
>
>     > From: Dave Sobey [mailto:sob...@gm...
>     <mailto:sob...@gm...>]
>     > Sent: Wednesday, 29 February 2012 8:21 p.m.
>     > To: Pdf...@li...
>     <mailto:Pdf...@li...>
>     > Subject: [Pdfedit-support] MSVCP100.dll
>     >
>     >
>     >
>     > Hi,
>     >
>     >
>     >
>     > I have searched your archives but can't find anything.
>     >
>     >
>     >
>     > I have installed the latest pdf.edit Win32 version. When I try
>     running it I
>     > get this error:
>     >
>     > "The program can't start because MSVCP100.dll is missing from
>     your computer.
>     > Try reinstalling the program fo fix this problem."
>     >
>     > I have tried re-installing it but same problem. Is there
>     something I can do
>     > to solve this?
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Virtualization & Cloud Management Using Capacity Planning
>     > Cloud computing makes use of virtualization - but cloud computing
>     > also focuses on allowing computing to be delivered as a service.
>     > http://www.accelacomm.com/jaw/sfnl/114/51521223/
>     > _______________________________________________
>     > Pdfedit-support mailing list
>     > Pdf...@li...
>     <mailto:Pdf...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/pdfedit-support
>     >
>
>     ------------------------------------------------------------------------------
>     Virtualization & Cloud Management Using Capacity Planning
>     Cloud computing makes use of virtualization - but cloud computing
>     also focuses on allowing computing to be delivered as a service.
>     http://www.accelacomm.com/jaw/sfnl/114/51521223/
>     _______________________________________________
>     Pdfedit-support mailing list
>     Pdf...@li...
>     <mailto:Pdf...@li...>
>     https://lists.sourceforge.net/lists/listinfo/pdfedit-support
>
>
>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
> _______________________________________________
> Pdfedit-support mailing list
> Pdf...@li...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-support

Re: [Pdfedit-support] MSVCP100.dll

[Dave S. <sob...@gm...>]

Thank you for your help. This has solved the issue now!

On 29 February 2012 23:34, Jeffrey Walton <nol...@gm...> wrote:

> On Wed, Feb 29, 2012 at 4:14 PM, Alister  Hood
> <Ali...@sy...> wrote:
> > That’s from the “standard c++ redistributables” that the home page
> mentions
> > aren’t included.
> >
> > They are from Microsoft.  IIRC the installer will be called vcredist
> > something.  They have a number of versions, and I’m not sure which
> version
> > that one is from, but Google will know ;)
> Probably easier to offer a link.
>
> x86: http://www.microsoft.com/download/en/details.aspx?id=5555
> x64: http://www.microsoft.com/download/en/details.aspx?id=14632
>
> > From: Dave Sobey [mailto:sob...@gm...]
> > Sent: Wednesday, 29 February 2012 8:21 p.m.
> > To: Pdf...@li...
> > Subject: [Pdfedit-support] MSVCP100.dll
> >
> >
> >
> > Hi,
> >
> >
> >
> > I have searched your archives but can't find anything.
> >
> >
> >
> > I have installed the latest pdf.edit Win32 version. When I try running
> it I
> > get this error:
> >
> > "The program can't start because MSVCP100.dll is missing from your
> computer.
> > Try reinstalling the program fo fix this problem."
> >
> > I have tried re-installing it but same problem. Is there something I can
> do
> > to solve this?
> >
> >
> >
> ------------------------------------------------------------------------------
> > Virtualization & Cloud Management Using Capacity Planning
> > Cloud computing makes use of virtualization - but cloud computing
> > also focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > _______________________________________________
> > Pdfedit-support mailing list
> > Pdf...@li...
> > https://lists.sourceforge.net/lists/listinfo/pdfedit-support
> >
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Pdfedit-support mailing list
> Pdf...@li...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-support
>

Re: [Pdfedit-support] MSVCP100.dll

[Jeffrey W. <nol...@gm...>]

On Wed, Feb 29, 2012 at 4:14 PM, Alister  Hood
<Ali...@sy...> wrote:
> That’s from the “standard c++ redistributables” that the home page mentions
> aren’t included.
>
> They are from Microsoft.  IIRC the installer will be called vcredist
> something.  They have a number of versions, and I’m not sure which version
> that one is from, but Google will know ;)
Probably easier to offer a link.

x86: http://www.microsoft.com/download/en/details.aspx?id=5555
x64: http://www.microsoft.com/download/en/details.aspx?id=14632

> From: Dave Sobey [mailto:sob...@gm...]
> Sent: Wednesday, 29 February 2012 8:21 p.m.
> To: Pdf...@li...
> Subject: [Pdfedit-support] MSVCP100.dll
>
>
>
> Hi,
>
>
>
> I have searched your archives but can't find anything.
>
>
>
> I have installed the latest pdf.edit Win32 version. When I try running it I
> get this error:
>
> "The program can't start because MSVCP100.dll is missing from your computer.
> Try reinstalling the program fo fix this problem."
>
> I have tried re-installing it but same problem. Is there something I can do
> to solve this?
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Pdfedit-support mailing list
> Pdf...@li...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-support
>

Re: [Pdfedit-support] MSVCP100.dll

[Alister H. <Ali...@sy...>]

That's from the "standard c++ redistributables" that the home page mentions aren't included.
They are from Microsoft.  IIRC the installer will be called vcredist something.  They have a number of versions, and I'm not sure which version that one is from, but Google will know ;)

From: Dave Sobey [mailto:sob...@gm...]
Sent: Wednesday, 29 February 2012 8:21 p.m.
To: Pdf...@li...
Subject: [Pdfedit-support] MSVCP100.dll

Hi,

I have searched your archives but can't find anything.

I have installed the latest pdf.edit Win32 version. When I try running it I get this error:
"The program can't start because MSVCP100.dll is missing from your computer. Try reinstalling the program fo fix this problem."
I have tried re-installing it but same problem. Is there something I can do to solve this?

[Pdfedit-support] MSVCP100.dll

[Dave S. <sob...@gm...>]

Hi,

I have searched your archives but can't find anything.

I have installed the latest pdf.edit Win32 version. When I try running it I
get this error:
"The program can't start because MSVCP100.dll is missing from your
computer. Try reinstalling the program fo fix this problem."
I have tried re-installing it but same problem. Is there something I can do
to solve this?

Re: [Pdfedit-support] \"Add text\" works with with 0.3.2-4 but doesn\'t with 0.4.1-1

[Michal H. <ms...@gm...>]

On Mon, Jan 09, 2012 at 01:27:12PM -0500, GDombi wrote:
> Hi Micheal,

Hi,

> 
> Did the problem of disappearing text ever get fixed?
> 
> I downloader PDFedit from the Ubuntu software center and it has the same
> problem.  Open pdf files nicely but can't change the text?!?

I remember a similar bug which got fixed but it is hard to tell without
actually seeing what is going on with your case.

We are currently at 0.4.5 version which contains a lot of fixes since
0.4.1.

> I would appreciate and website you can point me towards to get an
> working PDF editor.

Could you try with the current git snapshot?
(git://pdfedit.git.sourceforge.net/gitroot/pdfedit/pdfedit)

HTH
-- 
Michal Hocko

[Pdfedit-support] Console mode save-as-text

[Robert S. K. <rob...@gm...>]

For a set of Chinese PDF's, pdfedit produces pretty much what I want
as output with its "save as text" function, but I'm not quite certain
how I can invoke this from the command-line without bringing up the
GUI and rolling my mouse around, so I can set it running in a batch
job.

I know there's a console mode, but it isn't quite clear to me what it
expects get fed in order to operate.

pdfedit -console ........ input.pdf output.txt

something of that sort is what I'm after.

[Pdfedit-support] save from script

[Stefan W. <s.w...@gm...>]

Dear all,

I am trying to write a script for pdfedit that opens a file, does 
something to it, and then saves the result. Everything works nicely, 
except, I don't know how to save the result.
The only way I can see to save a pdf from a script is via the saveAs 
method, which however ignores the changes made so far (which in turn is 
intended as I understand from

   http://pdfedit.petricek.net/bt/view.php?id=301 ).

So how is one supposed to save the changes to disk? Thanks in advance 
for your help!

Best,
Stefan

P.S.: For concreteness' sake, let's pretend I want to remove the first 
page. I would try this:

doc=loadPdf("file.pdf",false);
doc.removePage(1);
doc.saveAs("file_without_page_1.pdf");
doc.unloadPdf();

and run it with

   pdfedit -s scriptname

Re: [Pdfedit-support] configure choose the wrong lib directory on x 86_64 multilib. .

[Jozef <mis...@ho...>]

Dne 22.9.2011 21:54, Michal Hocko napsal(a):
> On Thu, Sep 22, 2011 at 02:15:14PM -0500, Bollinger, John C wrote:
>> On Thursday, September 22, 2011 12:40 PM, Michal Hocko [mailto:ms...@gm...] wrote:
>>
>>> What kind of problems you have with our bug tracker? I can access
>>> http://pdfedit.petricek.net/bt/main_page.php just fine.
>>
>> I don't have any trouble with that URL, thanks.  The problem is that
>> I didn't have it in the first place, because that's not where the
>> "Bugtracker" hyperlink on http://pdfedit.cz/en/index.html takes me.
>> The hyperlink is directed instead at http://pdfedit.petricek.net/bt/,
>> which is redirected to http://pdfedit.petricek.net/bt/index.html
>> (apparently an alternative URL for the PDFedit home page).

Fixed that, thx.

jm



> Martin?
>

Re: [Pdfedit-support] configure choose the wrong lib directory on x 86_64 multilib. .. .

[Bollinger, J. C <Joh...@ST...>]

On Thursday, September 22, 2011 2:56 PM, Michal Hocko [mailto:ms...@gm...] wrote:
> On Thu, Sep 22, 2011 at 02:15:14PM -0500, Bollinger, John C wrote:
> > On Thursday, September 22, 2011 12:40 PM, Michal Hocko
> [mailto:ms...@gm...] wrote:
> [...]
> >
> > > Most libraries have their parameters to specify compilation and
> > > link
> > > parameters.
> > > E.g. boost should be specified as --with-boost-libdir=PATH
> > > LibT1: --with-t1-library=PATH
> >
> >
> > Ok.  The boost and t1 options are documented, and that's how I
> worked
> > around the problem.
>
> So is the problem still present with those 2 parameters?


If I specify the correct library locations via those parameters then the program links successfully, even zlib.  In fact, I only need to specify the correct location for one library, since all the needed ones are in the same place, and the linker processes all -L options before any -l option.

My complaint is that I shouldn't need to specify library locations when the libaries are in an LSB-approved and distro-standard place to begin with.  Obviously, that is much less significant problem than not being able at all to build the program.  If I can find the time to improve the autoconf macros in this area then I will be helping myself.


Thanks,

John


Email Disclaimer:  www.stjude.org/emaildisclaimer

Re: [Pdfedit-support] configure choose the wrong lib directory on x 86_64 multilib. .

[Michal H. <ms...@gm...>]

On Thu, Sep 22, 2011 at 02:15:14PM -0500, Bollinger, John C wrote:
> On Thursday, September 22, 2011 12:40 PM, Michal Hocko [mailto:ms...@gm...] wrote:
[...]
> 
> > Most libraries have their parameters to specify compilation and
> > link
> > parameters.
> > E.g. boost should be specified as --with-boost-libdir=PATH
> > LibT1: --with-t1-library=PATH
> 
> 
> Ok.  The boost and t1 options are documented, and that's how I worked
> around the problem.

So is the problem still present with those 2 parameters?

> 
> 
> > ./configure --help should show you all available parameters.
> > zlib detection is really stupid and hardcoded. You can specify
> > a root directory for zlib build by --with-zlib=PATH but there is no
> > way
> > to tell it that it should look into /lib64 rather than /lib.
> > I thought I had some patch around to fix that but I cannot find it.
> >
> > Anyway you can workaround that by editing Makefile.flags which is
> > generated by configure and it contains all the flags. So you can
> > change
> > all linking paths from lib to lib64.
> > Sorry for the ugliness but I really hate to look into autoconf
> > macros
> > again ;)
> > If you want to fix them it would be really welcome but "friends do
> > not
> > let friends edit autoconf macros" so I cannot ask you to do it.
> 
> 
> Thanks Michal.  I have more than a passing familiarity with Autoconf,
> so I may just take a stab at this.  No promises, though.

Would be appreciated, indeed.
> 
> 
> Cheers,
> 
> John
> 
> Email Disclaimer:  www.stjude.org/emaildisclaimer
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Pdfedit-support mailing list
> Pdf...@li...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-support

-- 
Michal Hocko

Re: [Pdfedit-support] configure choose the wrong lib directory on x 86_64 multilib. .

[Michal H. <ms...@gm...>]

On Thu, Sep 22, 2011 at 02:15:14PM -0500, Bollinger, John C wrote:
> On Thursday, September 22, 2011 12:40 PM, Michal Hocko [mailto:ms...@gm...] wrote:
> 
> > What kind of problems you have with our bug tracker? I can access
> > http://pdfedit.petricek.net/bt/main_page.php just fine.
> 
> 
> I don't have any trouble with that URL, thanks.  The problem is that
> I didn't have it in the first place, because that's not where the
> "Bugtracker" hyperlink on http://pdfedit.cz/en/index.html takes me.
> The hyperlink is directed instead at http://pdfedit.petricek.net/bt/,
> which is redirected to http://pdfedit.petricek.net/bt/index.html
> (apparently an alternative URL for the PDFedit home page).

Martin?

-- 
Michal Hocko

Re: [Pdfedit-support] configure choose the wrong lib directory on x 86_64 multilib. .

[Bollinger, J. C <Joh...@ST...>]

On Thursday, September 22, 2011 12:40 PM, Michal Hocko [mailto:ms...@gm...] wrote:

> What kind of problems you have with our bug tracker? I can access
> http://pdfedit.petricek.net/bt/main_page.php just fine.


I don't have any trouble with that URL, thanks.  The problem is that I didn't have it in the first place, because that's not where the "Bugtracker" hyperlink on http://pdfedit.cz/en/index.html takes me.  The hyperlink is directed instead at http://pdfedit.petricek.net/bt/, which is redirected to http://pdfedit.petricek.net/bt/index.html (apparently an alternative URL for the PDFedit home page).


> OK, this seems that libt and xlib where taken from the bad path.


> Most libraries have their parameters to specify compilation and
> link
> parameters.
> E.g. boost should be specified as --with-boost-libdir=PATH
> LibT1: --with-t1-library=PATH


Ok.  The boost and t1 options are documented, and that's how I worked around the problem.


> ./configure --help should show you all available parameters.
> zlib detection is really stupid and hardcoded. You can specify
> a root directory for zlib build by --with-zlib=PATH but there is no
> way
> to tell it that it should look into /lib64 rather than /lib.
> I thought I had some patch around to fix that but I cannot find it.
>
> Anyway you can workaround that by editing Makefile.flags which is
> generated by configure and it contains all the flags. So you can
> change
> all linking paths from lib to lib64.
> Sorry for the ugliness but I really hate to look into autoconf
> macros
> again ;)
> If you want to fix them it would be really welcome but "friends do
> not
> let friends edit autoconf macros" so I cannot ask you to do it.


Thanks Michal.  I have more than a passing familiarity with Autoconf, so I may just take a stab at this.  No promises, though.


Cheers,

John

Email Disclaimer:  www.stjude.org/emaildisclaimer

Re: [Pdfedit-support] configure choose the wrong lib directory on x86_64 multilib

[Michal H. <ms...@gm...>]

On Thu, Sep 22, 2011 at 11:17:56AM -0500, Bollinger, John C wrote:
> With thanks to you kind souls around here, I successfully built
> PDFedit 0.4.5 on CentOS 5 / i386.  It was quite smooth compared to
> some other packages I have built, so kudos on that.
>
> I am now turning to building an x86_64 version (still on Cent5), and
> I have run into trouble with the configure script choosing the wrong
> directory for some of the needed libraries.  I have a workaround, so
> this is more a bug report than support request, but I am unable to
> access your bug tracker via the web site to report it that way.

What kind of problems you have with our bug tracker? I can access
http://pdfedit.petricek.net/bt/main_page.php just fine.

> RedHat-family x86_64 systems use the multilib approach, so /lib and
> /usr/lib contain 32-bit libraries (for the most part), whereas the
> 64-bit libraries are in /lib64 and /usr/lib64.  When building software
> on such a system, one generally wants to link against the libraries in
> /lib64 and /usr/lib64 in preference to anything in /lib or /usr/lib,
> and the linker generally does the right thing by default.  I have
> rarely, if ever, had any trouble related to this -- until now.
>
> 64-bit versions of all the libraries needed for PDFedit are installed
> on my build system, in /usr/lib64 as is standard for this distro.
> I initially also had 32-bit boost and zlib installed, and in that
> configuration the PDFedit build proceeded fine all the way to
> the final link of the pdfedit binary, then failed on not finding
> compatible versions of some of the needed 3rd-party libraries:
> 
> g++  -o pdfedit  [... many object files ...]   -L/usr/lib64/qt-3.3/lib -lqsa_pdfedit -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/qsa/lib/ -lqoutputdevices -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/kpdf-kde-3.3.2/ -L/usr/lib -lkernel -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/kernel -lutils -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/utils -lxpdf -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/xpdf -lfofi -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/fofi -lGoo -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/goo -lsplash -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/splash  -lfreetype -lt1 -L/usr/lib -lz -lqt-mt -lXext -lX11 -lm
> /usr/bin/ld: skipping incompatible /usr/lib/libt1.so when searching for -lt1
> /usr/bin/ld: skipping incompatible /usr/lib/libt1.so when searching for -lt1
> /usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
> /usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
> /usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
> /usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
> /usr/bin/ld: skipping incompatible /usr/lib/libXext.so when searching for -lXext
> /usr/bin/ld: skipping incompatible /usr/lib/libXext.so when searching for -lXext

OK, this seems that libt and xlib where taken from the bad path.

> 
> I reiterate that the needed 64-bit development libs are present
> on the system, but I suppose the specified link options cause the
> linker to overlook them.  Perhaps that is related to the two spurious
> appearances of the "-L/usr/lib" option.  For what it's worth, those
> appear to come from configure's choices for 'BOOST_LDFLAGS' and
> 'ZLIB_LIBS' options, which configure is getting wrong.

Most libraries have their parameters to specify compilation and link
parameters.
E.g. boost should be specified as --with-boost-libdir=PATH
LibT1: --with-t1-library=PATH

./configure --help should show you all available parameters.
zlib detection is really stupid and hardcoded. You can specify
a root directory for zlib build by --with-zlib=PATH but there is no way
to tell it that it should look into /lib64 rather than /lib.
I thought I had some patch around to fix that but I cannot find it.

Anyway you can workaround that by editing Makefile.flags which is
generated by configure and it contains all the flags. So you can change
all linking paths from lib to lib64.
Sorry for the ugliness but I really hate to look into autoconf macros
again ;)
If you want to fix them it would be really welcome but "friends do not
let friends edit autoconf macros" so I cannot ask you to do it.

>
> I attempted to fix the problem by exporting LDFLAGS=-L/usr/lib64
> to configure, but that had no effect whatever on the link command
> that was ultimately issued.  I also tried removing the 32-bit boost
> libraries, but in that case configure fails with:
>
> checking for boost-program-options library... checking whether
> the Boost::Program_Options library is available... yes configure:
> error: Could not link against !
>
> The log appears to shows configure assuming that the boost (and zlib)
> libs will be in /usr/lib, whereas it should be looking instead to
> /usr/lib64.  Ultimately, I was able to work around the problem via
> configure's --with-boost-libdir option.  Configure still chooses the
> wrong link options for zlib, but having it right for boost allows the
> linker to find the right zlib (and other) libraries as well, since -L
> options are global to the whole link.
>
> Overall, none of that hassle should be necessary for a system, such as
> mine, having the needed libraries in standard LSB-specified locations.
> 
> 
> Thanks,
> 
> John Bollinger
> 
> 
> Email Disclaimer:  www.stjude.org/emaildisclaimer
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Pdfedit-support mailing list
> Pdf...@li...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-support

-- 
Michal Hocko

Re: [Pdfedit-support] The replace_text tools does not build on GCC 4.1.2 / x86_64

[Michal H. <ms...@gm...>]

On Thu, Sep 22, 2011 at 12:04:14PM -0500, Bollinger, John C wrote:
> 
> Still being unable to access the PDFedit bug tracker, I hope this is a
> reasonable location to offer one more bug report (and a patch).
>
> While attempting to build the 0.4.5 tools on CentOS 5 / x86_64 using
> the distro's standard CGG 4.1.2 toolchain, I receive the following
> compilation error:
> 
> g++ -c -g -O2   -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fexceptions   -fstack-protector -pipe -posix -ansi -std=c++98 -I. -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/  -I/usr/include -I/usr/include/freetype2  -I/usr/include -o replace_text.o replace_text.cc
> replace_text.cc: In function 'int main(int, char**)':
> replace_text.cc:140: error: no matching function for call to 'min(size_t&, unsigned int)'

Yet another gcc 4.1 issue, I would say.
> 
> The source line in question is the innocuous looking:
> 
>                to = std::min(to, pdf->getPageCount()+1);
> 
> The problem is that 'to' has type size_t, whereas pdf->getPageCount()
> has type unsigned int, and these are not equivalent in the compilation
> environment. (size_t is a 64-bit unsigned integer, whereas unsigned
> int is only 32 bits wide.)

This is already fixed in the CVS as:

	to = std::min(static_cast<unsigned int>(to), pdf->getPageCount()+1);

> The problem could, and perhaps should, be fixed by changing the
> data type of one or the other of these expressions so that they are
> compatible, but a quick and not-too-dirty solution is to just do this:
> 
> diff -Naur pdfedit-0.4.5-base/src/tools/replace_text.cc pdfedit-0.4.5-mod/src/tools/replace_text.cc
> --- pdfedit-0.4.5-base/src/tools/replace_text.cc        2010-02-23 12:28:09.000000000 -0600
> +++ pdfedit-0.4.5-mod/src/tools/replace_text.cc 2011-09-22 11:20:19.000000000 -0500
> @@ -137,7 +137,7 @@
> 
> 
>                 // sane values
> -               to = std::min(to, pdf->getPageCount()+1);
> +               to = std::min(to, static_cast<size_t>(pdf->getPageCount()+1));
> 
>                 // now the hard stuff comes - do this crazy loops intentionally
>                 for (size_t things_to_replace = 0; things_to_replace < withs.size(); ++things_to_replace)
> === end of patch ===
> 
> 
> Best,
> 
> John Bollinger
> 
> 
> Email Disclaimer:  www.stjude.org/emaildisclaimer
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Pdfedit-support mailing list
> Pdf...@li...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-support

-- 
Michal Hocko

[Pdfedit-support] The replace_text tools does not build on GCC 4.1.2 / x86_64

[Bollinger, J. C <Joh...@ST...>]

Still being unable to access the PDFedit bug tracker, I hope this is a reasonable location to offer one more bug report (and a patch).

While attempting to build the 0.4.5 tools on CentOS 5 / x86_64 using the distro's standard CGG 4.1.2 toolchain, I receive the following compilation error:

g++ -c -g -O2   -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fexceptions   -fstack-protector -pipe -posix -ansi -std=c++98 -I. -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/  -I/usr/include -I/usr/include/freetype2  -I/usr/include -o replace_text.o replace_text.cc
replace_text.cc: In function 'int main(int, char**)':
replace_text.cc:140: error: no matching function for call to 'min(size_t&, unsigned int)'

The source line in question is the innocuous looking:

               to = std::min(to, pdf->getPageCount()+1);

The problem is that 'to' has type size_t, whereas pdf->getPageCount() has type unsigned int, and these are not equivalent in the compilation environment.  (size_t is a 64-bit unsigned integer, whereas unsigned int is only 32 bits wide.)  The problem could, and perhaps should, be fixed by changing the data type of one or the other of these expressions so that they are compatible, but a quick and not-too-dirty solution is to just do this:

diff -Naur pdfedit-0.4.5-base/src/tools/replace_text.cc pdfedit-0.4.5-mod/src/tools/replace_text.cc
--- pdfedit-0.4.5-base/src/tools/replace_text.cc        2010-02-23 12:28:09.000000000 -0600
+++ pdfedit-0.4.5-mod/src/tools/replace_text.cc 2011-09-22 11:20:19.000000000 -0500
@@ -137,7 +137,7 @@


                // sane values
-               to = std::min(to, pdf->getPageCount()+1);
+               to = std::min(to, static_cast<size_t>(pdf->getPageCount()+1));

                // now the hard stuff comes - do this crazy loops intentionally
                for (size_t things_to_replace = 0; things_to_replace < withs.size(); ++things_to_replace)
=== end of patch ===


Best,

John Bollinger


Email Disclaimer:  www.stjude.org/emaildisclaimer

[Pdfedit-support] configure choose the wrong lib directory on x86_64 multilib

[Bollinger, J. C <Joh...@ST...>]

With thanks to you kind souls around here, I successfully built PDFedit 0.4.5 on CentOS 5 / i386.  It was quite smooth compared to some other packages I have built, so kudos on that.

I am now turning to building an x86_64 version (still on Cent5), and I have run into trouble with the configure script choosing the wrong directory for some of the needed libraries.  I have a workaround, so this is more a bug report than support request, but I am unable to access your bug tracker via the web site to report it that way.


RedHat-family x86_64 systems use the multilib approach, so /lib and /usr/lib contain 32-bit libraries (for the most part), whereas the 64-bit libraries are in /lib64 and /usr/lib64.  When building software on such a system, one generally wants to link against the libraries in /lib64 and /usr/lib64 in preference to anything in /lib or /usr/lib, and the linker generally does the right thing by default.  I have rarely, if ever, had any trouble related to this -- until now.

64-bit versions of all the libraries needed for PDFedit are installed on my build system, in /usr/lib64 as is standard for this distro.  I initially also had 32-bit boost and zlib installed, and in that configuration the PDFedit build proceeded fine all the way to the final link of the pdfedit binary, then failed on not finding compatible versions of some of the needed 3rd-party libraries:

g++  -o pdfedit  [... many object files ...]   -L/usr/lib64/qt-3.3/lib -lqsa_pdfedit -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/qsa/lib/ -lqoutputdevices -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/kpdf-kde-3.3.2/ -L/usr/lib -lkernel -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/kernel -lutils -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/utils -lxpdf -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/xpdf -lfofi -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/fofi -lGoo -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/goo -lsplash -L/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/splash  -lfreetype -lt1 -L/usr/lib -lz -lqt-mt -lXext -lX11 -lm
/usr/bin/ld: skipping incompatible /usr/lib/libt1.so when searching for -lt1
/usr/bin/ld: skipping incompatible /usr/lib/libt1.so when searching for -lt1
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libXext.so when searching for -lXext
/usr/bin/ld: skipping incompatible /usr/lib/libXext.so when searching for -lXext

I reiterate that the needed 64-bit development libs are present on the system, but I suppose the specified link options cause the linker to overlook them.  Perhaps that is related to the two spurious appearances of the "-L/usr/lib" option.  For what it's worth, those appear to come from configure's choices for 'BOOST_LDFLAGS' and 'ZLIB_LIBS' options, which configure is getting wrong.

I attempted to fix the problem by exporting LDFLAGS=-L/usr/lib64 to configure, but that had no effect whatever on the link command that was ultimately issued.  I also tried removing the 32-bit boost libraries, but in that case configure fails with:

checking for boost-program-options library... checking whether the Boost::Program_Options library is available... yes
configure: error: Could not link against  !

The log appears to shows configure assuming that the boost (and zlib) libs will be in /usr/lib, whereas it should be looking instead to /usr/lib64.  Ultimately, I was able to work around the problem via configure's --with-boost-libdir option.  Configure still chooses the wrong link options for zlib, but having it right for boost allows the linker to find the right zlib (and other) libraries as well, since -L options are global to the whole link.

Overall, none of that hassle should be necessary for a system, such as mine, having the needed libraries in standard LSB-specified locations.


Thanks,

John Bollinger


Email Disclaimer:  www.stjude.org/emaildisclaimer

Re: [Pdfedit-support] Type mismatch in CPageContents::addInlineImag e(). .. .

[Bollinger, J. C <Joh...@ST...>]

On Wednesday, September 21, 2011 10:03 AM, Jeffrey Walton [mailto:nol...@gm...] wrote:

> On Wed, Sep 21, 2011 at 10:50 AM, Bollinger, John C
> <Joh...@st...> wrote:
[...]
> > Well, I wouldn't say the warning is bogus, but I'll accept that
> it is ignoreable in this situation.  I guess a static_cast<int>
> would after all be the best way to make the warning go away, since
> it doesn't in the end matter that a temporal object is involved.
> Ah, a fellow clean-compile enthusiast (or security minded
> individual).

Both, actually.  I have been in the business quite long enough to appreciate the many ways C provides to unintentionally shoot yourself in the foot.  Also long enough to recognize that C++ approximately squares the number of ways, plus arms you with a submachine gun with a flaky safety.  Resolving warnings is like keeping the safety on, however much good that's going to do.

> Actually, we (I) treat a clean compile is a security gate. If the
> code
> can't clean compile, it does not meet quality standards and gets
> kicked until it can.
>
> You might want to to try -Wall -Wextra -Wformat=2 -Wformat-security
> -Woverloaded-virtual -Wreorder -Wno-unused -Wno-type-limits. The
> last
> three ease the use of C++ with -Wall -Wextra.
>
> For linker hardening, try -z relro and -z now for PLT and GOT
> attacks.

Good advice, thanks.


John

Email Disclaimer:  www.stjude.org/emaildisclaimer

Re: [Pdfedit-support] Type mismatch in CPageContents::addInlineImag e(). .

[Jeffrey W. <nol...@gm...>]

On Wed, Sep 21, 2011 at 10:50 AM, Bollinger, John C
<Joh...@st...> wrote:
> On Wednesday, September 21, 2011 3:19 AM, Michal Hocko [mailto:ms...@gm...] wrote:
>> On Tue, Sep 20, 2011 at 04:13:37PM -0500, Bollinger, John C wrote:
>> > As I wrote a few minutes ago, I am attempting to build PDFedit v
>> 0.4.5
>> > on CentOS 5, using the distro's provided GCC 4.1.2 toolchain.
>>
>> Don't want to blame gcc here but 4.1.x was plain wrong. I would
>> encourage you to use something newer.
>
> Well, I am in the process of upgrading to CentOS 6, which uses GCC 4.4.  For the time being, however, I still need to support Cent5, which means I have to build (also) on Cent5.  Even there, however, I guess there's a version of GCC 4.4 available, if only I can figure out how to get the build system to use it.  It's probably not worth the effort, however.
>
> [...]
>
>> The warning is bogus. Pointer should just cast real to int
>> (truncate it)
>> and then provide a reference to a temporal int variable.
>
> Well, I wouldn't say the warning is bogus, but I'll accept that it is ignoreable in this situation.  I guess a static_cast<int> would after all be the best way to make the warning go away, since it doesn't in the end matter that a temporal object is involved.
Ah, a fellow clean-compile enthusiast (or security minded individual).
Actually, we (I) treat a clean compile is a security gate. If the code
can't clean compile, it does not meet quality standards and gets
kicked until it can.

You might want to to try -Wall -Wextra -Wformat=2 -Wformat-security
-Woverloaded-virtual -Wreorder -Wno-unused -Wno-type-limits. The last
three ease the use of C++ with -Wall -Wextra.

For linker hardening, try -z relro and -z now for PLT and GOT attacks.

Jeff

Re: [Pdfedit-support] Type mismatch in CPageContents::addInlineImag e(). .

[Bollinger, J. C <Joh...@ST...>]

On Wednesday, September 21, 2011 3:19 AM, Michal Hocko [mailto:ms...@gm...] wrote:

> On Tue, Sep 20, 2011 at 04:13:37PM -0500, Bollinger, John C wrote:
> > Hello All,
>
> Hi,
>
> >
> > As I wrote a few minutes ago, I am attempting to build PDFedit v
> 0.4.5
> > on CentOS 5, using the distro's provided GCC 4.1.2 toolchain.
>
> Don't want to blame gcc here but 4.1.x was plain wrong. I would
> encourage you to use something newer.

Well, I am in the process of upgrading to CentOS 6, which uses GCC 4.4.  For the time being, however, I still need to support Cent5, which means I have to build (also) on Cent5.  Even there, however, I guess there's a version of GCC 4.4 available, if only I can figure out how to get the build system to use it.  It's probably not worth the effort, however.

[...]

> The warning is bogus. Pointer should just cast real to int
> (truncate it)
> and then provide a reference to a temporal int variable.

Well, I wouldn't say the warning is bogus, but I'll accept that it is ignoreable in this situation.  I guess a static_cast<int> would after all be the best way to make the warning go away, since it doesn't in the end matter that a temporal object is involved.

> >
> > The most obvious fix would be to change the CInts to CReals, but
> I
> > don't know whether that would cause trouble elsewhere in the
> program.
>
> PDF specification says that both Width and Height are integers so
> CInt
> is appropriate.

Fair enough.  That's exactly the sort of answer I was looking for.


Thanks,

John


Email Disclaimer:  www.stjude.org/emaildisclaimer

Re: [Pdfedit-support] PDFedit 0.4.5 comile failure on gcc/g++ 4.1.2 . .

[Bollinger, J. C <Joh...@ST...>]

On Wednesday, September 21, 2011 3:06 AM, Michal Hocko [mailto:ms...@gm...] wrote:

[...]

> No. Arguments are deep copied (we are using clone method). Have a
> look
> at CDict::addProperty method.

[...]

> Does the deep copying answers your concern?

After parsing the CDict code and the CInt typdef a bit more, yes it does.  Thank you.  My apologies if I sounded alarmist.


Thanks,

John

Email Disclaimer:  www.stjude.org/emaildisclaimer

Re: [Pdfedit-support] Type mismatch in CPageContents::addInlineImage()

[Michal H. <ms...@gm...>]

On Tue, Sep 20, 2011 at 04:13:37PM -0500, Bollinger, John C wrote:
> Hello All,

Hi,

> 
> As I wrote a few minutes ago, I am attempting to build PDFedit v 0.4.5
> on CentOS 5, using the distro's provided GCC 4.1.2 toolchain.  

Don't want to blame gcc here but 4.1.x was plain wrong. I would
encourage you to use something newer.

Anyway,

> The method CPageContents::addInlineImage() is giving me some trouble,
> the bulk of which I raised in my previous mail.  In addition, however,
> I see some worrisome warnings in the same method:
> 
> g++ -c -g -O2   -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fexceptions   -fstack-protector -pipe -posix -ansi -std=c++98 -pedantic -I. -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/  -I/usr/include -I/usr/include/freetype2  -I/usr/include -o cpagecontents.o cpagecontents.cc
> cpagecontents.cc: In member function 'void pdfobjects::CPageContents::addInlineImage(const std::vector<char, std::allocator<char> >&, const libs::Point&, const libs::Point&)':
> cpagecontents.cc:543: warning: passing 'const double' for argument 1 to 'pdfobjects::CObjectSimple<Tp>::CObjectSimple(const typename pdfobjects::PropertyTraitSimple<Tp>::value&) [with pdfobjects::PropertyType Tp = pInt]'
> [...]
> cpagecontents.cc:544: warning: passing 'const double' for argument 1 to 'pdfobjects::CObjectSimple<Tp>::CObjectSimple(const typename pdfobjects::PropertyTraitSimple<Tp>::value&) [with pdfobjects::PropertyType Tp = pInt]'
> 
> These arise from the following two lines of code:
> 
>         image_dict.addProperty ("W", CInt (image_size.x));
>         image_dict.addProperty ("H", CInt (image_size.y));
> 
> Evidently, image_size.x and image_size.y are of type (const double),
> but they are passed to a constructor expecting an int&.  I'm neither
> sure what is needed, nor sure what actually happens here (and that in
> itself is a minor problem).  Given that we're dealing with references,
> however, I can't think of an approach the compiler could take to the
> issue that would be likely to have a satisfactory result.

The warning is bogus. Pointer should just cast real to int (truncate it)
and then provide a reference to a temporal int variable.

> 
> The most obvious fix would be to change the CInts to CReals, but I
> don't know whether that would cause trouble elsewhere in the program.

PDF specification says that both Width and Height are integers so CInt
is appropriate.

> 
> 
> Best,
> 
> John Bollinger
> 
> 
> Email Disclaimer:  www.stjude.org/emaildisclaimer
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Pdfedit-support mailing list
> Pdf...@li...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-support

-- 
Michal Hocko