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

Re: [Pdfedit-support] gui-Win32-20100509_0038.zip broken on windows 7 sp1 x64

[Carsten K. <C.K...@gm...>]

Hello Jozef,

> we are shipping debugging versions which are incompatible with vc
> redistributables. the fix is to distribute release version of that
> application BUT the gui is just a proof of concept for now - you
> cannot really edit pdfs with it. That is why it is really not a priority now.

ok but tools are broken, too.

greetings
Carsten

Re: [Pdfedit-support] gui-Win32-20100509_0038.zip broken on windows 7 sp1 x64

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

Hi Carsten,


it has been already reported (once) that it had failed to start. the problem is caused by vs2008 and ""more improved debug dll hell"" :)  
we are shipping debugging versions which are incompatible with vc redistributables. the fix is to distribute release version of that application BUT the gui is just a proof of concept for now - you cannot really edit pdfs with it. That is why it is really not a priority now.

For using pdfedit on windows you have currently these options:
- cygwin http://www.cygwin.com/
- http://www.andlinux.org/
- virtualbox or similar
- wait for http://code.google.com/p/pdfeditor/
- go for another pdf editor ;) try to google it, there are pretty good ones for 30-day trial



neither ideal but at least something.

jm


> Date: Mon, 7 Mar 2011 02:55:43 +0100
> From: C.K...@gm...
> To: pdf...@li...
> Subject: [Pdfedit-support] gui-Win32-20100509_0038.zip broken on windows 7	sp1 x64
> 
> Hi,
> 
> if I try to run "gui.win32.exe" I get
> 
> >The application has failed to start because its side-by-side configuration is incorrect. Please
> >see the application event log or use the command-line sxstrace.exe tool for more detail.
> 
> README states:
> This means that no dll hell/incorrect runtime environment problems occur but there is significant file size overhead.
> 
> Didn't worked :-)
> 
> greetings
> Carsten
> 
> 
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Pdfedit-support mailing list
> Pdf...@li...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-support
 		 	   		  

[Pdfedit-support] gui-Win32-20100509_0038.zip broken on windows 7 sp1 x64

[Carsten K. <C.K...@gm...>]

Hi,

if I try to run "gui.win32.exe" I get

>The application has failed to start because its side-by-side configuration is incorrect. Please
>see the application event log or use the command-line sxstrace.exe tool for more detail.

README states:
This means that no dll hell/incorrect runtime environment problems occur but there is significant file size overhead.

Didn't worked :-)

greetings
Carsten

Re: [Pdfedit-support] How do I obtain the bounding box values?

[Eric D. <er...@do...>]

On 03/05/2011 04:33 AM, Jozef Misutka wrote:
> i haven't had time to look into your script but i think the requested 
> functionality is implemented in
> dialogs.qs in function highlightingSelectedText

Cool!

> hope it helps,

It does.

It will take some time to understand all of this, but this definitely helps.

I'll keep you posted on my progress.

Thanks,
- Eric

Re: [Pdfedit-support] How do I obtain the bounding box values?

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

hi erik,


i haven't had time to look into your script but i think the requested functionality is implemented in 
dialogs.qs in function highlightingSelectedText

 	var _op = firstSelected();
	var _firstTextOp = undefined;
	var _rectangles = [];
	while (_op) {
		if (isTextOp( _op )) {
			var _pom = getFirstTextOp( _op );

			if (_firstTextOp == undefined)
				_firstTextOp = _pom;

			if ( ! _pom.equals (_firstTextOp) ) {
				operatorDrawRect( _rectangles, getColor("bg"), 0, _firstTextOp );
				_firstTextOp = _pom;
				_rectangles = [];
			}

			var _br = _op.getBBox();
			var _x1 = convertPixmapPosToPdfPos_x( _br[0], _br[1] );
			var _y1 = convertPixmapPosToPdfPos_y( _br[0], _br[1] );
			var _x2 = convertPixmapPosToPdfPos_x( _br[2], _br[3] );
			var _y2 = convertPixmapPosToPdfPos_y( _br[2], _br[3] );

			_rectangles.push( [_x1, _y1, _x2-_x1, _y2-_y1 ] );
		}

  


hope it helps,
jozef




> Date: Fri, 4 Mar 2011 11:53:01 -0500
> From: er...@do...
> To: pdf...@li...
> Subject: Re: [Pdfedit-support] How do I obtain the bounding box values?
> 
> >
> >> How can I obtain a list all text and graphic objects on a given page?
> >> How do I call getBBox on them?
> >>      
> > I am not familiar with the scripting but operators should be accesible
> > via content stream object. Jozo might tell you more. Anyway I would
> > rather use the gs if it implements this feature.
> >    
> 
> That's the most practical suggestion. Developing a PDFedit algorithm to 
> calculate the "page bounding box" would duplicate what Ghostscript has 
> already done.
> 
> But still, I wonder ...
> 
> Jozo's PDF-to-XML script contains the bounding box information from each 
> operator, so it must be possible to create a pure PDFedit implementation.
> 
> I'll think about it some more and write back when I have something that 
> works.
> 
> Thanks,
> - Eric
> 
> 
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Pdfedit-support mailing list
> Pdf...@li...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-support
 		 	   		  

Re: [Pdfedit-support] How do I obtain the bounding box values?

[Eric D. <er...@do...>]

>
>> How can I obtain a list all text and graphic objects on a given page?
>> How do I call getBBox on them?
>>      
> I am not familiar with the scripting but operators should be accesible
> via content stream object. Jozo might tell you more. Anyway I would
> rather use the gs if it implements this feature.
>    

That's the most practical suggestion. Developing a PDFedit algorithm to 
calculate the "page bounding box" would duplicate what Ghostscript has 
already done.

But still, I wonder ...

Jozo's PDF-to-XML script contains the bounding box information from each 
operator, so it must be possible to create a pure PDFedit implementation.

I'll think about it some more and write back when I have something that 
works.

Thanks,
- Eric

Re: [Pdfedit-support] How do I obtain the bounding box values?

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

On Fri, Mar 04, 2011 at 09:47:04AM -0500, Eric Doviak wrote:
> Thanks for your response, Michal.
> 
> >> But occasionally, I receive a PDF file with enormous white margins.
> >> In such cases, I want to crop the pages down to the bounding box
> >> before resizing and rescaling the page.
> >>      
> > Maybe just a terminology but what do you mean by the bounding box? I
> > guess what you actually mean is the media size (aka paper size). You
> > will get this value by page_dict.property( "MediaBox" ) and you can
> > change it by modifying the given rectangle.
> >    
> 
> By "bounding box," I mean the "page bounding box" that Ghostscript 
> returns when you run:
> 
> gs -dSAFER -dNOPAUSE -dBATCH -q -r72 -sDEVICE=bbox -f filename.pdf

I do not know how this is implemented but it looks like it really prints
out the smallest box which contains all displayed objects.

> 
> 
> > Btw. do you want this to be automatical? (determine the text area and
> > crop down to this size + border).
> >
> > This would be really interesting but then you would need to go through
> > all text and graphical operators on the page and call getBBox on them
> > and calculate the area from them.
> >    
> 
> That's what I was afraid of.

I think you do not have to be afraid ;) Just reuse the numbers
calculated by gs.

> How can I obtain a list all text and graphic objects on a given page? 
> How do I call getBBox on them?

I am not familiar with the scripting but operators should be accesible
via content stream object. Jozo might tell you more. Anyway I would
rather use the gs if it implements this feature.

-- 
Michal Hocko

Re: [Pdfedit-support] How do I obtain the bounding box values?

[Eric D. <er...@do...>]

Thanks for your response, Michal.

>> But occasionally, I receive a PDF file with enormous white margins.
>> In such cases, I want to crop the pages down to the bounding box
>> before resizing and rescaling the page.
>>      
> Maybe just a terminology but what do you mean by the bounding box? I
> guess what you actually mean is the media size (aka paper size). You
> will get this value by page_dict.property( "MediaBox" ) and you can
> change it by modifying the given rectangle.
>    

By "bounding box," I mean the "page bounding box" that Ghostscript 
returns when you run:

gs -dSAFER -dNOPAUSE -dBATCH -q -r72 -sDEVICE=bbox -f filename.pdf


> Btw. do you want this to be automatical? (determine the text area and
> crop down to this size + border).
>
> This would be really interesting but then you would need to go through
> all text and graphical operators on the page and call getBBox on them
> and calculate the area from them.
>    

That's what I was afraid of.

How can I obtain a list all text and graphic objects on a given page? 
How do I call getBBox on them?

Thanks again,
- Eric

Re: [Pdfedit-support] How do I obtain the bounding box values?

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

On Wed, Mar 02, 2011 at 04:50:17PM -0500, Eric Doviak wrote:
> Hi Michal, Jozef and Martin,

Hi,

> 
> For a very long time, I have wanted a program that would
> automatically resize and rescale a PDF page so that it fits on a
> standard-size sheet of paper. After many bad hacks and after
> receiving a lot of help, I have gotten closer to my dream.
> 
> The attached script:
> 
>    *   determines the page orientation
>    *   calculates the optimal page metrics and scale factor and
>    *   resizes and rescales the pages.
> 
> For most purposes, this script will do what I need it to do -- fit
> the text of an journal article onto a standard size sheet of paper.

Nice

> 
> But occasionally, I receive a PDF file with enormous white margins.
> In such cases, I want to crop the pages down to the bounding box
> before resizing and rescaling the page.

Maybe just a terminology but what do you mean by the bounding box? I
guess what you actually mean is the media size (aka paper size). You
will get this value by page_dict.property( "MediaBox" ) and you can
change it by modifying the given rectangle.

Btw. do you want this to be automatical? (determine the text area and
crop down to this size + border). 

This would be really interesting but then you would need to go through
all text and graphical operators on the page and call getBBox on them
and calculate the area from them.

> 
> So I would like to include the bounding box values in my script. I
> know that there is a "getBBox()"  function, but I cannot get it to
> work.

getBBox is IIRC a operator function which returns its bounding box

-- 
Michal Hocko

[Pdfedit-support] How do I obtain the bounding box values?

[Eric D. <er...@do...>]

Hi Michal, Jozef and Martin,

For a very long time, I have wanted a program that would automatically 
resize and rescale a PDF page so that it fits on a standard-size sheet 
of paper. After many bad hacks and after receiving a lot of help, I have 
gotten closer to my dream.

The attached script:

    *   determines the page orientation
    *   calculates the optimal page metrics and scale factor and
    *   resizes and rescales the pages.

For most purposes, this script will do what I need it to do -- fit the 
text of an journal article onto a standard size sheet of paper.

But occasionally, I receive a PDF file with enormous white margins. In 
such cases, I want to crop the pages down to the bounding box before 
resizing and rescaling the page.

So I would like to include the bounding box values in my script. I know 
that there is a "getBBox()"  function, but I cannot get it to work.

How do I obtain the bounding box values?

Thanks,
- Eric

Re: [Pdfedit-support] How do I obtain the bounding box and media box?

[Eric D. <er...@do...>]

On 03/02/2011 10:50 AM, Eric Doviak wrote:
> Making some progress.

I have figured everything out except for the bounding box.

I know that there is a "getBBox()"  function, but I cannot get it to work.

How do I obtain the bounding box values?

Thanks,
- E

Re: [Pdfedit-support] How do I obtain the bounding box and media box?

[Eric D. <er...@do...>]

On 03/01/2011 12:48 PM, Eric Doviak wrote:
> Everything should be done entirely within PDFedit.


Making some progress. (See attached).
- E

[Pdfedit-support] How do I obtain the bounding box and media box?

[Eric D. <er...@do...>]

Hi Michal, Jozef and Martin,

For a very long time, I have wanted a program that would automatically 
resize and rescale a PDF page so that it fits on a standard-size sheet 
of paper. After many bad hacks and after receiving a lot of help, I 
finally have something that works. (See attached).

I created a Perl script (called "pdfcrop") that:

    *   finds the borders of the PDF's bounding box (using ghostscript),
    *   determines the page orientation (by "grepping" the PDF file),
    *   calculates the optimal page metrics and scale factor and
    *   calls PDFedit to resize and rescale the pages.

The script is less than ideal, but it works.

Could you help me create a pure PDFedit implementation of this script? 
There's no good reason for using Perl and there's no good reason why my 
script should use ghostscript and grep to obtain the bounding box and 
page orientation. Everything should be done entirely within PDFedit.

If I knew the names of the PDFedit functions that obtain the bounding 
box and media box of each page, I could create a pure PDFedit 
implementation.

Could you tell me the names of those functions?

Thanks,
- Eric

Re: [Pdfedit-support] A feature question

[Johannes J. <joh...@we...>]

Hello,

pdftk file1.pdf file2.pdf cat output file3.pdf sould do it.

Regards
 Johannes

[Pdfedit-support] Starting script from console

[Garret R. <bol...@gm...>]

Hi there,
I want to convert some pdfs to text. All work fine in other programs too,
but only pdfedit can convert tables to (readable) text. I have many pdf
files and want to convert tables from them. I have made simple script:

function saveAsText_page(f,page) {
 var of=new File(f);
 of.open(File.WriteOnly);
 pg=pdff.getPage(page);
 text=pg.getText();
 of.write(text);
 of.write("\n");
 of.close();
}


pdff = loadPdf(takeparameter(),false)
saveAsText_page(takeparameter(),takeparameter())

I can run pdfedit with -script option and everything works fine (except
takeparameters function) in GUI. But I want to run it in console mode only,
but when I run pdfedit -s myscript, it only prints

pdfedit -s myscript.qs
PDFedit 0.4.5-20100603071400
Použití:
 pdfedit -console [jméno funkce] [parametr(y) funkce]
První parametr je název funkce, která se zavolá (nezáleží na velikosti
písmen) nebo jeho jednoznačná část.
Zbytek parametrů je předán volané funkci.
Dostupné funkce:
 Delinearizator
  Popis: Delinearize input file
  Parametry: [input file] [output file]
 Flattener
  Popis: Flatten input file (remove all revisions except the last one)
  Parametry: [input file] [output file]

to the standard output. When I want to give it arguments (pdfedit -s
myscript.qs "../t1.pdf" 45) it prints "function "../t1.pdf" not found". How
to start my script without GUI?

Jan Sedlák

Re: [Pdfedit-support] A feature question

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

Hi Rich,
I'm pretty sure it can't, but you may be able to get what you want by
converting the PDFs to eps and using another program.

Regards,
Alister


> -----Original Message-----
> From: Rich Mack [mailto:ra...@ya...]
> Sent: Thursday, 10 February 2011 12:01 p.m.
> To: pdf...@li...
> Subject: [Pdfedit-support] A feature question
> 
> This is a question about the functionality PDFEdit. I'm not too
> familiar with it, so I don't know it's capabilities.
> 
> I have two PDFs. PDF A is a single page portrait 8.5x11.0(inch). PDF B
> is a single page landscape 11.0x17.0(inch). In a nutshell what I want
> to do is overlay PDF B on top of PDF A and retain the media size of
> 11.0x17.0. Or better yet, copy a small area from PDF A and paste it
> into PDF B.
> 
> Can PDFEdit preform this operation?
> 
> Rich
> 
> 
> 
> 
>
-----------------------------------------------------------------------
> -------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
> XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Pdfedit-support mailing list
> Pdf...@li...
> https://lists.sourceforge.net/lists/listinfo/pdfedit-support

[Pdfedit-support] A feature question

[Rich M. <ra...@ya...>]

This is a question about the functionality PDFEdit. I'm not too familiar with it, so I don't know it's capabilities.

I have two PDFs. PDF A is a single page portrait 8.5x11.0(inch). PDF B is a single page landscape 11.0x17.0(inch). In a nutshell what I want to do is overlay PDF B on top of PDF A and retain the media size of 11.0x17.0. Or better yet, copy a small area from PDF A and paste it into PDF B.

Can PDFEdit preform this operation?

Rich


      

Re: [Pdfedit-support] Trouble with oversized input PDFs -- 'patch' options?

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

On Sun, Jan 30, 2011 at 11:46:10AM -0500, PMA wrote:
> 
> 
> Michal Hocko wrote:
> > On Sun, Jan 30, 2011 at 11:17:30AM -0500, PMA wrote:
> >> Michal Hocko wrote:
> > [...]
> >> Ok, I'll test with the patch, which I've just downloaded and read some of.
> >> But I must tell you, I have never applied a patch (I gather "applied" is the
> >> right word).  Could you point me to a dependable instruction document?
> >> Meanwhile, I'll hold off importing a newer version.  Thanks for your help!
> >> ---------------------------------------------------------------------------------------------------------
> >> [01/30/11]
> >> Ahem: nevermind, I see the command!
> >> Pete
> >> ---------------------------------------------------------------------------------------------------------
> >> [same, later]
> >> I'm using Debian 'lenny' and 'patch' 2.5.9-5, have copied 
> >> '/usr/bin/pdfedit'
> >> and 'crop_box-sync_with_media_box.patch' an into isolated subdirectory
> >> /usr/bin/PatchTest, and have cd'd there.  Running --
> >>
> >>              patch   pdfedit   crop_box-sync_with_media_box.patch
> >>
> >> by itself yields errors.  Can you tell me which 'patch' options (especially
> >> the '-p' number) I should be using?
> > 
> > patch -p1 crop_box-sync_with_media_box.patch in the top level source
> > directory.
> > 
> > 
> ---------------------------------------------------------------------------------------------------------------
> 
> Does this mean that I need to have built my exec from source?
> (I see no "source" or "src" in paths from 'find / -name "pdfedit*",
> and my /usr/bin/pdfedit is the ELF binary from a .deb package.)

Yes, you have to build the binary from sources. You have basically 2
options:
	- download the tarball from sf.net and build it
	- standard debian way: 
	apt-get source pdfedit/stable; apply the patch; fakeroot debian/rules binary

The second option is better as you get the deb package which you can
install by dpkg. Please note that you will have to install some packages
for both approaches (namely qt3-dev-tools, freetype2, boost, debian
helpers for packages bulding).

-- 
Michal Hocko

Re: [Pdfedit-support] Trouble with oversized input PDFs -- 'patch' options?

[PMA <Pet...@ay...>]

Michal Hocko wrote:
> On Sun, Jan 30, 2011 at 11:17:30AM -0500, PMA wrote:
>> Michal Hocko wrote:
> [...]
>> Ok, I'll test with the patch, which I've just downloaded and read some of.
>> But I must tell you, I have never applied a patch (I gather "applied" is the
>> right word).  Could you point me to a dependable instruction document?
>> Meanwhile, I'll hold off importing a newer version.  Thanks for your help!
>> ---------------------------------------------------------------------------------------------------------
>> [01/30/11]
>> Ahem: nevermind, I see the command!
>> Pete
>> ---------------------------------------------------------------------------------------------------------
>> [same, later]
>> I'm using Debian 'lenny' and 'patch' 2.5.9-5, have copied 
>> '/usr/bin/pdfedit'
>> and 'crop_box-sync_with_media_box.patch' an into isolated subdirectory
>> /usr/bin/PatchTest, and have cd'd there.  Running --
>>
>>              patch   pdfedit   crop_box-sync_with_media_box.patch
>>
>> by itself yields errors.  Can you tell me which 'patch' options (especially
>> the '-p' number) I should be using?
> 
> patch -p1 crop_box-sync_with_media_box.patch in the top level source
> directory.
> 
> 
---------------------------------------------------------------------------------------------------------------

Does this mean that I need to have built my exec from source?
(I see no "source" or "src" in paths from 'find / -name "pdfedit*",
and my /usr/bin/pdfedit is the ELF binary from a .deb package.)

Re: [Pdfedit-support] Trouble with oversized input PDFs -- 'patch' options?

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

On Sun, Jan 30, 2011 at 11:17:30AM -0500, PMA wrote:
> Michal Hocko wrote:
[...]
> Ok, I'll test with the patch, which I've just downloaded and read some of.
> But I must tell you, I have never applied a patch (I gather "applied" is the
> right word).  Could you point me to a dependable instruction document?
> Meanwhile, I'll hold off importing a newer version.  Thanks for your help!
> ---------------------------------------------------------------------------------------------------------
> [01/30/11]
> Ahem: nevermind, I see the command!
> Pete
> ---------------------------------------------------------------------------------------------------------
> [same, later]
> I'm using Debian 'lenny' and 'patch' 2.5.9-5, have copied 
> '/usr/bin/pdfedit'
> and 'crop_box-sync_with_media_box.patch' an into isolated subdirectory
> /usr/bin/PatchTest, and have cd'd there.  Running --
> 
>              patch   pdfedit   crop_box-sync_with_media_box.patch
> 
> by itself yields errors.  Can you tell me which 'patch' options (especially
> the '-p' number) I should be using?

patch -p1 crop_box-sync_with_media_box.patch in the top level source
directory.


-- 
Michal Hocko

Re: [Pdfedit-support] Trouble with oversized input PDFs -- 'patch' options?

[PMA <Pet...@ay...>]

Michal Hocko wrote:
> [Please do not top post]
> 
> On Thu, Jan 27, 2011 at 06:04:25PM -0500, PMA wrote:
>> Here we go:
>>
>> Pages
>>     3,0
>>        Type
>>        Kids
>>           4,0
>>           Type
>>           MediaBox
>>              0 Int =       0
>>              1 Int =       0
>>              2 Int =   792
>>              3 Int = 1224
>>           ...
>>           Cropbox
>>              0 Int =       0
>>              1 Int =       0
>>              2 Int =   612
>>              3 Int =   792
>>
>> Those are the values both before & after I edit.
> 
> The problem is that CropBox which defines a visible part of the media
> (defined by MediaBox) cuts out the rest. It smells like
> http://pdfedit.petricek.net/bt/view.php?id=290. We have probably set the
> CropBox to the default value (A4 paper size) rather than to the MediaBox.
> Could you test with the patch from the bugtracker or try 0.4.3 which
> already contains the fix.
> 
> The patch testing would be much more helpful because you could report
> this to the Debian bug tracking system and they will update the patch. 
> 
> Anyway I would encourage you to update to 0.4.5-2 (from the current
> unstable). There were many fixes since 0.4.1.
> 
>> (This what you wanted to know?)
> 
> Yes, thanks
> 
>>
>> Michal Hocko wrote:
>>> On Thu, Jan 27, 2011 at 05:20:16PM -0500, PMA wrote:
>>>> Hi Michal.
>>> Hi,
>>>
>>>> If we can feasibly discuss this problem without my posting
>>>> my doc, I'd rather, as copyright issues are not yet settled.
>>>> I'll restate --
>>>>
>>>> I have a musical-score PDF specifically created to print on
>>>> 11x17 paper.  It needs a few edits that I'd like to do with
>>>> PDFedit.  And I've succeeded with those, to this extent:
>>>>
>>>> 	-- the file opens in PDFedit
>>> What is the PDFedit version you are using?
>>>
>>>> 	-- my changes are successful
>>>> 	-- I can save the result
>>>> 	-- if I re-open that, PDFedit displays it *complete*
>>>>
>>>> HOWEVER. if I open that saved result with either 'xpdf' or
>>>> Adobe (at work, where there's a printer that likes PDFs),
>>>> I get only *part* of it -- the upper left portion, ca 8.5x11:
>>> OK, could you check the MediaBox/CropBox before and after you do your
>>> editing work? (you can find them in the Object Tree - right side on the
>>> application layout - when you navigate through the Pages to the one you
>>> are editing up to the Dictionary object).
>>>
>>> We are doing some tricks if no MediaBox is defined directly for the page
>>> so this sounds like a smoking gun at the moment, but it would definitely
>>> be good if you could test it.
>>>
> 
Ok, I'll test with the patch, which I've just downloaded and read some of.
But I must tell you, I have never applied a patch (I gather "applied" is the
right word).  Could you point me to a dependable instruction document?
Meanwhile, I'll hold off importing a newer version.  Thanks for your help!
---------------------------------------------------------------------------------------------------------
[01/30/11]
Ahem: nevermind, I see the command!
Pete
---------------------------------------------------------------------------------------------------------
[same, later]
I'm using Debian 'lenny' and 'patch' 2.5.9-5, have copied 
'/usr/bin/pdfedit'
and 'crop_box-sync_with_media_box.patch' an into isolated subdirectory
/usr/bin/PatchTest, and have cd'd there.  Running --

             patch   pdfedit   crop_box-sync_with_media_box.patch

by itself yields errors.  Can you tell me which 'patch' options (especially
the '-p' number) I should be using?

Thanks

Re: [Pdfedit-support] Trouble with oversized input PDFs

[PMA <Pet...@ay...>]

Michal Hocko wrote:
> [Please do not top post]
> 
> On Thu, Jan 27, 2011 at 06:04:25PM -0500, PMA wrote:
>> Here we go:
>>
>> Pages
>>     3,0
>>        Type
>>        Kids
>>           4,0
>>           Type
>>           MediaBox
>>              0 Int =       0
>>              1 Int =       0
>>              2 Int =   792
>>              3 Int = 1224
>>           ...
>>           Cropbox
>>              0 Int =       0
>>              1 Int =       0
>>              2 Int =   612
>>              3 Int =   792
>>
>> Those are the values both before & after I edit.
> 
> The problem is that CropBox which defines a visible part of the media
> (defined by MediaBox) cuts out the rest. It smells like
> http://pdfedit.petricek.net/bt/view.php?id=290. We have probably set the
> CropBox to the default value (A4 paper size) rather than to the MediaBox.
> Could you test with the patch from the bugtracker or try 0.4.3 which
> already contains the fix.
> 
> The patch testing would be much more helpful because you could report
> this to the Debian bug tracking system and they will update the patch. 
> 
> Anyway I would encourage you to update to 0.4.5-2 (from the current
> unstable). There were many fixes since 0.4.1.
> 
>> (This what you wanted to know?)
> 
> Yes, thanks
> 
>>
>> Michal Hocko wrote:
>>> On Thu, Jan 27, 2011 at 05:20:16PM -0500, PMA wrote:
>>>> Hi Michal.
>>> Hi,
>>>
>>>> If we can feasibly discuss this problem without my posting
>>>> my doc, I'd rather, as copyright issues are not yet settled.
>>>> I'll restate --
>>>>
>>>> I have a musical-score PDF specifically created to print on
>>>> 11x17 paper.  It needs a few edits that I'd like to do with
>>>> PDFedit.  And I've succeeded with those, to this extent:
>>>>
>>>> 	-- the file opens in PDFedit
>>> What is the PDFedit version you are using?
>>>
>>>> 	-- my changes are successful
>>>> 	-- I can save the result
>>>> 	-- if I re-open that, PDFedit displays it *complete*
>>>>
>>>> HOWEVER. if I open that saved result with either 'xpdf' or
>>>> Adobe (at work, where there's a printer that likes PDFs),
>>>> I get only *part* of it -- the upper left portion, ca 8.5x11:
>>> OK, could you check the MediaBox/CropBox before and after you do your
>>> editing work? (you can find them in the Object Tree - right side on the
>>> application layout - when you navigate through the Pages to the one you
>>> are editing up to the Dictionary object).
>>>
>>> We are doing some tricks if no MediaBox is defined directly for the page
>>> so this sounds like a smoking gun at the moment, but it would definitely
>>> be good if you could test it.
>>>
> 
Ok, I'll test with the patch, which I've just downloaded and read some of.
But I must tell you, I have never applied a patch (I gather "applied" is the
right word).  Could you point me to a dependable instruction document?
Meanwhile, I'll hold off importing a newer version.  Thanks for your help!

[01/30/11]
Ahem: nevermind, I see the command!
Pete

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Pdfedit-support mailing list
Pdf...@li...
https://lists.sourceforge.net/lists/listinfo/pdfedit-support

Re: [Pdfedit-support] Trouble with oversized input PDFs

[PMA <Pet...@ay...>]

Michal Hocko wrote:
> [Please do not top post]
> 
> On Thu, Jan 27, 2011 at 06:04:25PM -0500, PMA wrote:
>> Here we go:
>>
>> Pages
>>     3,0
>>        Type
>>        Kids
>>           4,0
>>           Type
>>           MediaBox
>>              0 Int =       0
>>              1 Int =       0
>>              2 Int =   792
>>              3 Int = 1224
>>           ...
>>           Cropbox
>>              0 Int =       0
>>              1 Int =       0
>>              2 Int =   612
>>              3 Int =   792
>>
>> Those are the values both before & after I edit.
> 
> The problem is that CropBox which defines a visible part of the media
> (defined by MediaBox) cuts out the rest. It smells like
> http://pdfedit.petricek.net/bt/view.php?id=290. We have probably set the
> CropBox to the default value (A4 paper size) rather than to the MediaBox.
> Could you test with the patch from the bugtracker or try 0.4.3 which
> already contains the fix.
> 
> The patch testing would be much more helpful because you could report
> this to the Debian bug tracking system and they will update the patch. 
> 
> Anyway I would encourage you to update to 0.4.5-2 (from the current
> unstable). There were many fixes since 0.4.1.
> 
>> (This what you wanted to know?)
> 
> Yes, thanks
> 
>>
>> Michal Hocko wrote:
>>> On Thu, Jan 27, 2011 at 05:20:16PM -0500, PMA wrote:
>>>> Hi Michal.
>>> Hi,
>>>
>>>> If we can feasibly discuss this problem without my posting
>>>> my doc, I'd rather, as copyright issues are not yet settled.
>>>> I'll restate --
>>>>
>>>> I have a musical-score PDF specifically created to print on
>>>> 11x17 paper.  It needs a few edits that I'd like to do with
>>>> PDFedit.  And I've succeeded with those, to this extent:
>>>>
>>>> 	-- the file opens in PDFedit
>>> What is the PDFedit version you are using?
>>>
>>>> 	-- my changes are successful
>>>> 	-- I can save the result
>>>> 	-- if I re-open that, PDFedit displays it *complete*
>>>>
>>>> HOWEVER. if I open that saved result with either 'xpdf' or
>>>> Adobe (at work, where there's a printer that likes PDFs),
>>>> I get only *part* of it -- the upper left portion, ca 8.5x11:
>>> OK, could you check the MediaBox/CropBox before and after you do your
>>> editing work? (you can find them in the Object Tree - right side on the
>>> application layout - when you navigate through the Pages to the one you
>>> are editing up to the Dictionary object).
>>>
>>> We are doing some tricks if no MediaBox is defined directly for the page
>>> so this sounds like a smoking gun at the moment, but it would definitely
>>> be good if you could test it.
>>>
> 
Ok, I'll test with the patch, which I've just downloaded and read some of.
But I must tell you, I have never applied a patch (I gather "applied" is the
right word).  Could you point me to a dependable instruction document?
Meanwhile, I'll hold off importing a newer version.  Thanks for your help!

Re: [Pdfedit-support] Trouble with oversized input PDFs

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

On Fri, Jan 28, 2011 at 11:09:38AM +0100, Michal Hocko wrote:
> [Please do not top post]
> 
> On Thu, Jan 27, 2011 at 06:04:25PM -0500, PMA wrote:
> > Here we go:
> > 
> > Pages
> >     3,0
> >        Type
> >        Kids
> >           4,0
> >           Type
> >           MediaBox
> >              0 Int =       0
> >              1 Int =       0
> >              2 Int =   792
> >              3 Int = 1224
> >           ...
> >           Cropbox
> >              0 Int =       0
> >              1 Int =       0
> >              2 Int =   612
> >              3 Int =   792
> > 
> > Those are the values both before & after I edit.
> 
[...]
> The patch testing would be much more helpful because you could report
> this to the Debian bug tracking system and they will update the patch. 

But the patch doesn't apply and backporting is not so trivial due to
some rework in that area. I have backported it localy and tried on top
of the current Debia stable sources and it still did the same. So this
is something different.

So I have looked deeper into history and found the commit which fixes
it. The fix was introduced in 0.4.2.

Attached you will find the patch for the Debian stable version so push
it through their bug tracking system.

-- 
Michal Hocko

Re: [Pdfedit-support] Trouble with oversized input PDFs

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

[Please do not top post]

On Thu, Jan 27, 2011 at 06:04:25PM -0500, PMA wrote:
> Here we go:
> 
> Pages
>     3,0
>        Type
>        Kids
>           4,0
>           Type
>           MediaBox
>              0 Int =       0
>              1 Int =       0
>              2 Int =   792
>              3 Int = 1224
>           ...
>           Cropbox
>              0 Int =       0
>              1 Int =       0
>              2 Int =   612
>              3 Int =   792
> 
> Those are the values both before & after I edit.

The problem is that CropBox which defines a visible part of the media
(defined by MediaBox) cuts out the rest. It smells like
http://pdfedit.petricek.net/bt/view.php?id=290. We have probably set the
CropBox to the default value (A4 paper size) rather than to the MediaBox.
Could you test with the patch from the bugtracker or try 0.4.3 which
already contains the fix.

The patch testing would be much more helpful because you could report
this to the Debian bug tracking system and they will update the patch. 

Anyway I would encourage you to update to 0.4.5-2 (from the current
unstable). There were many fixes since 0.4.1.

> (This what you wanted to know?)

Yes, thanks

> 
> 
> Michal Hocko wrote:
> > On Thu, Jan 27, 2011 at 05:20:16PM -0500, PMA wrote:
> >> Hi Michal.
> > 
> > Hi,
> > 
> >> If we can feasibly discuss this problem without my posting
> >> my doc, I'd rather, as copyright issues are not yet settled.
> >> I'll restate --
> >>
> >> I have a musical-score PDF specifically created to print on
> >> 11x17 paper.  It needs a few edits that I'd like to do with
> >> PDFedit.  And I've succeeded with those, to this extent:
> >>
> >> 	-- the file opens in PDFedit
> > 
> > What is the PDFedit version you are using?
> > 
> >> 	-- my changes are successful
> >> 	-- I can save the result
> >> 	-- if I re-open that, PDFedit displays it *complete*
> >>
> >> HOWEVER. if I open that saved result with either 'xpdf' or
> >> Adobe (at work, where there's a printer that likes PDFs),
> >> I get only *part* of it -- the upper left portion, ca 8.5x11:
> > 
> > OK, could you check the MediaBox/CropBox before and after you do your
> > editing work? (you can find them in the Object Tree - right side on the
> > application layout - when you navigate through the Pages to the one you
> > are editing up to the Dictionary object).
> > 
> > We are doing some tricks if no MediaBox is defined directly for the page
> > so this sounds like a smoking gun at the moment, but it would definitely
> > be good if you could test it.
> > 

-- 
Michal Hocko