Batch Compression of pdfs

[ConstantineGeorgantzas]

Just a thought here.

What would happen if all the files were copied to a folder then the whole folder compressed (easy) and then the files copied back? I THINK that the files should remain compressed and not require the PDF compression at all.

It would take some experimenting to prove though.

I am using Adobe Acrobat 6.0 to compress and it cannot compress folders.

Good idea though.

One other idea I had was to merge the 14000 pdfs together, which is easy but time comsuming, compress the large document, and then break the pdf apart again and put all the documents back in their respective files, which would be even more time consuming.

[weaponx]

THE ULTIMATE SOLUTION:

-When run it will prompt for source and destination paths

-Folder structure and file names will be recreated in destination

-DON'T FORGET to include the FileListToArrayEX functions either in the file or like I did in an external file called FileListToArrayEX.au3

-If you want to use UNC paths like \\Server\blablabla you should map them first or use DriveMapAdd at the beginning of the script and hard-code source & destination

expandcollapse popup

#include <FileListToArrayEX.au3>
#include <Array.au3>

;Match exact window titles
Opt("WinTitleMatchMode", 3)

$ACROBAT = "Adobe Acrobat Standard"
$REDUCE = "Reduce File Size"
$SAVEAS = "Save As"

$PDFINPUT = FileSelectFolder ( "PDF Source", "",7 )
;$PDFINPUT = @ScriptDir & "\IN"

$PDFOUTPUT = FileSelectFolder ( "PDF Destination", "",7 )
;$PDFOUTPUT = @ScriptDir & "\OUT"

$PDFLIST = _FileListToArrayEx($PDFINPUT, '*.pdf', 1,'', True)

;For $X = 1 to 1
For $X = 1 to $PDFLIST[0]
    ;Force new instance of Acrobat - CAREFUL THIS WILL LAUNCH A NEW INSTANCE FOR EVERY FILE
    ;Run(@ProgramFilesDir & "\Adobe\Acrobat 7.0\Acrobat\acrobat.exe /n " & @ScriptDir & "\" & $PDFINPUT & "\" & $PDFLIST[$X])
    
    ;Break file path into array
    $A = StringSplit($PDFLIST[$X], "\")
    
    ;Strip filename from file path
    $FILENAME = _ArrayPop ($A)
    
    ;Compact array, replace input folder with output
    $DIR = StringReplace ( _ArrayToString ( $A, "\",1 ), $PDFINPUT, $PDFOUTPUT)
    
    ;Create folder structure
    DirCreate ( $DIR )
    
    ;Delete file, otherwise Acrobat will prompt for file delete
    FileDelete($DIR & "\" & $FILENAME)
    
    ;Open file in Acrobat 7
    Run(@ProgramFilesDir & "\Adobe\Acrobat 7.0\Acrobat\acrobat.exe " & $PDFLIST[$X])
    WinActivate (StringFormat("%s - [%s]",$ACROBAT,$FILENAME))
    WinWaitActive (StringFormat("%s - [%s]",$ACROBAT,$FILENAME))
    
    ;Send Alt-F to open file menu
    Send ( "!f" )
    
    ;Send z to open Reduce File Size
    Send ( "z" )
    
    WinActivate ($REDUCE)
    WinWaitActive ($REDUCE)
    
    ;Click OK Button, leaving Acrobat 7 as default output
    ControlClick ($REDUCE, "","[CLASS:Button; INSTANCE:2]" )
    
    WinActivate ($SAVEAS)
    WinWaitActive ($SAVEAS)
    
    ;Set file path to output folder with same filename
    ControlSetText($SAVEAS, "", "[CLASS:Edit; INSTANCE:1]" , $DIR & "\" & $FILENAME)
    
    ;Click save
    ControlClick ($SAVEAS, "","[CLASS:Button; INSTANCE:2]" )
    
    ;Reactivate main window
    WinActivate (StringFormat("%s - [%s]",$ACROBAT,$FILENAME))
    WinWaitActive (StringFormat("%s - [%s]",$ACROBAT,$FILENAME))
    
    ;Send CTRL-W to close file
    Send ( "^w" )
    
    ;Wait for Acrobat title to eliminate file name before continuing
    WinWaitActive ($ACROBAT)
Next

Edited July 27, 2007 by weaponx

[GEOSoft]

I am using Adobe Acrobat 6.0 to compress and it cannot compress folders.

Maybe not but I have a function posted in example scripts that will compress a folder.

Edit::

http://www.autoitscript.com/forum/index.php?showtopic=46653

Edited July 27, 2007 by GEOSoft

[ConstantineGeorgantzas]

You'll probably want to use the path "\\Ny_fs1\Corp\Group" then. Try that and see if it gives you any more files.

Also, to see what files it DID return, you can add this to the end of your script:

FileDelete(@ScriptDir&"\filesfound.txt")
For $i=1 To $MyArray[0]
  FileWriteLine(@ScriptDir&"\filesfound.txt",$MyArray[$i])
Next
Run(@ComSpec & ' /c start "" "'&@ScriptDir&'\filesfound.txt"', "", @SW_HIDE)

Now examine that list and see what (if anything) is missing. (I know that's not a trivial task, with thousands of possible file names...look at the paths and see if anything was blatently skipped).

No wait, you were right. The problem was that I only replaced one @ScriptDir with "\\Ny_fs1\Corp\Group" and not all of them. And then I had to wait for the computer to process the script. It told me that there were about 60000 pdf files in the directory; I recognized many of those files also, as I had tried to compress the files manually for a period of four or five days, I had become familiar with them.

Can you explain this line:

FileDelete("\\Ny_fs1\Corp\Group"&"\filesfound.txt")

What exactly is being deleted and why? Was there extra stuff found in the search that we don't want? And why is &"\filesfound.txt" added?

Edited July 27, 2007 by ConstantineGeorgantzas

[MrTWist]

The AutoIT Help file is going to be your best tool to figure this out.

Open up the help file, click the index tab and type FileCopy in the textbox, then hit enter.

What that will tell you is that the files in the source (in this case, all files ending in pdf on the S: drive) are going to be copied to (use the help index!) directory pointed to by @ScriptDir and create a directory named Temp if one doesn't already exist.

Seriously, the help file is great. It explains the function and has an example at the bottom of the desription.

If you read the help file, you make progress fast.

By the way, things that start with @ in AutoIT are knows as macros. There are a whole bunch of them that that give you quick handles to the operating system, file system, time/date, etc.

Can you explain why FileCopy("S:\*.pdf", @ScriptDir & "\Temp\", 8) is better and what it is all about?

I tried it and it did not work anyway, but I would like to know the thinking behind it none the less.

By the way, temp is just a folder I keep in the desktop.

[james3mg]

No wait, you were right. The problem was that I only replaced one @ScriptDir with "\\Ny_fs1\Corp\Group" and not all of them. And then I had to wait for the computer to process the script. It told me that there were about 60000 pdf files in the directory; I recognized many of those files also, as I had tried to compress the files manually for a period of four or five days, I had become familiar with them.

Can you explain this line:

FileDelete("\\Ny_fs1\Corp\Group"&"\filesfound.txt")

What exactly is being deleted and why? Was there extra stuff found in the search that we don't want? And why is &"\filesfound.txt" added?

1) That wasn't the line I told you to use...it was supposed to be @ScriptDir&"\filesfound.txt". Fix that, and your script may even run faster, since you're not writing all the file names into a file on your network, but rather your local machine.

2) The lines I gave you write a list of all the files found into a file named filesfound.txt, then it opens that file up in your default text editor so you don't have to do it manually.

3) When the script exits, that file still remains in the same directory as your script, so you can refer to it later if you want.

4) If you were to run the script again without that line, it would simply APPEND the new list to the end of the old list, since that's what FileWriteLine does...it adds a line to the end of a file.

5) Since this isn't what you want (you want a complete list of the files found in the latest run only), the line you inquire about simply tries to delete the file first.

6) If FileDelete doesn't work (eg the file already didn't exist), the function returns an @error, but the script keeps running. If it does work, the script keeps running too. So at the end of that line, whether that file already existed or not, it doesn't anymore. Then the script starts FileWriteLine 'ing data into that file, but since it now doesn't exist, it creates the file, which is blank to start out with...meaning it's now appending the list to a blank file.

Make sense?

Edit: I only intended for you to replace instances of U:\ with \\Ny_fs1\Corp\Group...NOT @scriptdir. To understand @ScriptDir, run this: MsgBox(0,"hi",@ScriptDir) and you'll see it's essentially a variable that contains the PATH that your script is in, no matter where that is. Thus, it's usually a good place to stick files you need for your script (like filesfound.txt). Anywhere you need to reference your company's network drive, THAT's where you use \\Ny_fs1\Corp\Group.

Edit2: Rather than have you write the list into a text file, I probably should have had you use _ArrayDisplay() instead. To do that, stick this line at the TOP of your script:

#include <Array.au3>oÝ÷ ٩ݶ¬zeiǨ~Øh±çâ½ébë,µªíx0ØEWzW­y©Ýzwb"¶n*&Jjëh×6_ArrayDisplay($MyArray)

Look _ArrayDisplay up in the help file if you want more information about this function. That way, you're not having to write the list of files to a file that will have to be deleted someday, and you get the added benefit of seeing the structure of your array. Edited July 27, 2007 by james3mg

[ConstantineGeorgantzas]

1) That wasn't the line I told you to use...it was supposed to be @ScriptDir&"\filesfound.txt". Fix that, and your script may even run faster, since you're not writing all the file names into a file on your network, but rather your local machine.

2) The lines I gave you write a list of all the files found into a file named filesfound.txt, then it opens that file up in your default text editor so you don't have to do it manually.

3) When the script exits, that file still remains in the same directory as your script, so you can refer to it later if you want.

4) If you were to run the script again without that line, it would simply APPEND the new list to the end of the old list, since that's what FileWriteLine does...it adds a line to the end of a file.

5) Since this isn't what you want (you want a complete list of the files found in the latest run only), the line you inquire about simply tries to delete the file first.

6) If FileDelete doesn't work (eg the file already didn't exist), the function returns an @error, but the script keeps running. If it does work, the script keeps running too. So at the end of that line, whether that file already existed or not, it doesn't anymore. Then the script starts FileWriteLine 'ing data into that file, but since it now doesn't exist, it creates the file, which is blank to start out with...meaning it's now appending the list to a blank file.

Make sense?

Edit: I only intended for you to replace instances of U:\ with \\Ny_fs1\Corp\Group...NOT @scriptdir. To understand @ScriptDir, run this: MsgBox(0,"hi",@ScriptDir) and you'll see it's essentially a variable that contains the PATH that your script is in, no matter where that is. Thus, it's usually a good place to stick files you need for your script (like filesfound.txt). Anywhere you need to reference your company's network drive, THAT's where you use \\Ny_fs1\Corp\Group.

Edit2: Rather than have you write the list into a text file, I probably should have had you use _ArrayDisplay() instead. To do that, stick this line at the TOP of your script:

#include <Array.au3>oÝ÷ ٩ݶ¬zeiǨ~Øh±çâ½ébë,µªíx0ØEWzW­y©Ýzwb"¶n*&Jjëh×6_ArrayDisplay($MyArray)

Look _ArrayDisplay up in the help file if you want more information about this function. That way, you're not having to write the list of files to a file that will have to be deleted someday, and you get the added benefit of seeing the structure of your array.

Thank you; that post was very helpful and clear. I will be sure to read it several times over so that I may take advantage of this newfound insight.

[weaponx]

Dude. I posted THE ULTIMATE SOLUTION. I spent half my work day freaking testing and it does everything you asked for and more, why didn't you try it.

http://www.autoitscript.com/forum/index.ph...st&p=379809

[james3mg]

Thank you; that post was very helpful and clear. I will be sure to read it several times over so that I may take advantage of this newfound insight.

Because of some odd error on the forum, I'm not sure if that was sarcastic or not...my post looks ok to me, but the quote in your reply (and my post if I try to edit it) shows up quite garbled. If the AutoIt code box at the end of my post looked garbled to you, thus giving absolutely no 'newfound insight' ( ), then the jab was well-deserved, even if the garble was unintentional. Let me know if that's the case and I'll re-post what I was trying to say, hoping that it won't garble again.

Hopefully it actually WAS helpful and actually came through in english...just trying to help you learn here

Edited July 27, 2007 by james3mg

[GEOSoft]

Because of some odd error on the forum, I'm not sure if that was sarcastic or not...my post looks ok to me, but the quote in your reply (and my post if I try to edit it) shows up quite garbled. If the AutoIt code box at the end of my post looked garbled to you, thus giving absolutely no 'newfound insight' ( ), then the jab was well-deserved, even if the garble was unintentional. Let me know if that's the case and I'll re-post what I was trying to say, hoping that it won't garble again.

Hopefully it actually WAS helpful and actually came through in english...just trying to help you learn here

That seems to have started yesterday. I've had it a few times now.

[ConstantineGeorgantzas]

Dude. I posted THE ULTIMATE SOLUTION. I spent half my work day freaking testing and it does everything you asked for and more, why didn't you try it.

http://www.autoitscript.com/forum/index.ph...st&p=379809

I have tested it and thank you. I posted comments in my other topic; sorry if they could not reach you.

http://www.autoitscript.com/forum/index.ph...st&p=379713

http://www.autoitscript.com/forum/index.ph...st&p=379880

[ConstantineGeorgantzas]

Because of some odd error on the forum, I'm not sure if that was sarcastic or not...my post looks ok to me, but the quote in your reply (and my post if I try to edit it) shows up quite garbled. If the AutoIt code box at the end of my post looked garbled to you, thus giving absolutely no 'newfound insight' ( ), then the jab was well-deserved, even if the garble was unintentional. Let me know if that's the case and I'll re-post what I was trying to say, hoping that it won't garble again.

Hopefully it actually WAS helpful and actually came through in english...just trying to help you learn here

I'm having trouble manipulating the files in the $MyArray we created. As you may recall, each element in MyArray held the location and the name of a pdf file. Now I am trying to open and then compress these files one at a time with a for loop, but neither of these work:

RunWait($MyArray[$i], "\\Ny_fs1\Corp\Group", @SW_MAXIMIZE)

ShellExecuteWait("C:\Program Files\Adobe\Acrobat 6.0\Acrobat\Acrobat.exe", "MyArray[$i]");, "", open, @SW_MAXIMIZE)

I'm just trying to focus on the opening part before I move on.

[weaponx]

I'm having trouble manipulating the files in the $MyArray we created. As you may recall, each element in MyArray held the location and the name of a pdf file. Now I am trying to open and then compress these files one at a time with a for loop, but neither of these work:

RunWait($MyArray[$i], "\\Ny_fs1\Corp\Group", @SW_MAXIMIZE)

ShellExecuteWait("C:\Program Files\Adobe\Acrobat 6.0\Acrobat\Acrobat.exe", "MyArray[$i]");, "", open, @SW_MAXIMIZE)

I'm just trying to focus on the opening part before I move on.

You're killing me.

Whatever path returned from FileListToArrayEx is a path to a pdf file, which you can't just execute.

First off you can't even use runwait here since you have to perform other actions inside Acrobat.

You must do it like this:

Run(@ProgramFilesDir & "\Adobe\Acrobat 6.0\Acrobat\acrobat.exe " & $MyArray[$i])oÝ÷ Ø    l¡«è×(ËZÙr­çÞ­éÜx4*Z¶Ø§²×u«­¢+ÙÉ¥Ù5Á ÅÕ½Ðí`èÅÕ½Ðì°ÅÕ½ÐìÀäÈìÀäÈí9å}ÌÄÀäÈí
½ÉÀÀäÈíɽÕÀÅÕ½Ðì¤

Put that at the top of your script and now any File or Folder open dialogs will show it as drive X

[james3mg]

@WeaponX - I was having him reference the UNC path because, though he already has that path mapped as U:\ (presumably through a startup script or group policy), he was having difficulty getting any results from U:\, though the UNC path was working. What is the down-side to the UNC path (and forgive the ignorant question)?

@ConstantineGeorgantzas - What WeaponX says about Run() is true - read in the Help file about Run() and you'll see that you can only Run() an executable file (.exe, .bat, .com, .lnk that points to one of these others, etc). If you delve down into Windows a bit, you'll discover that when you double-click a file, Windows actually has to go into the registry to find out how to Open (note, not run) that file. When it finds the program, it Runs the program, with the filename as a parameter, which is the normal method for Opening a file with a program. (As a side note, I don't know if you remember the old DOS error "Bad command or file name"...same reason - you can't run a file, you have to run a program that can open the file!) The line that WeaponX gave you will work, as long as you have Acrobat 6.0, and it installed in the default place. I prefer using a different method, that's more akin to how Windows actually opens files:

Run(@ComSpec & ' \c start "" "\\Ny_fs1\Corp\Group\' & $MyArray[$i] & '"',"",@SW_Hide

That line tells windows to "Start" the file whose path (when prefixed with \\Ny_fs1\Corp\Group\) is stored in $MyArray[$i], just as if you'd double-clicked the file. Note that Start is a command that you can run at the commandline, just like "dir" or "ipconfig", which is just what we've done here. To learn more about Windows' "Start" command, look it up online, or open up a command prompt (start -> run and type in cmd then hit OK) and type "start /?" without the quotes. This method ensures that your code will work on any windows-based machine (at least, any that has the ability to open an acrobat document), even after upgrading Acrobat sometime in the future (at which point the program won't be under Acrobat 6.0 anymore).

Does that help?

Edited July 30, 2007 by james3mg

[weaponx]

@WeaponX - I was having him reference the UNC path because, though he already has that path mapped as U:\ (presumably through a startup script or group policy), he was having difficulty getting any results from U:\, though the UNC path was working. What is the down-side to the UNC path (and forgive the ignorant question)?

I have nothing against UNC paths but I thought a few posts back he was having trouble with it. Also the script that I created for him prompted for a Source and Destination for his pdf's and his UNC path may not be an option.

[ConstantineGeorgantzas]

I am having trouble testing the code we worked on that involved _FileToArrayEx; it takes a very long time to build that array each time so the rest of the script I am writing gets bogged down. So, for only during testing, I would like to build the array from the notepad direction you originally gave me, which we later improved to _ArrayDisplay. I would like to build the array with stringsplit, but stringsplit deletes delimiters, which poses a problem because the only text in the file includes addresses and newlines. I tried to use _ReplaceStringInFile to append junk text on the end of .pdf to use as a delimiter, but it didn't work.

How should I approach this?

[weaponx]

I am having trouble testing the code we worked on that involved _FileToArrayEx; it takes a very long time to build that array each time so the rest of the script I am writing gets bogged down. So, for only during testing, I would like to build the array from the notepad direction you originally gave me, which we later improved to _ArrayDisplay. I would like to build the array with stringsplit, but stringsplit deletes delimiters, which poses a problem because the only text in the file includes addresses and newlines. I tried to use _ReplaceStringInFile to append junk text on the end of .pdf to use as a delimiter, but it didn't work.

How should I approach this?

StringSplit should not even come into play here. _FileListToArrayEx is as fast as you'll get with 60,000 files. Anytime you are scanning a directory that large it will take time.

Once again I posted a complete program for you which will scan a folder and find pdf's in any subfolders, compress them, and copy the same folder structure to a new destination.

[ConstantineGeorgantzas]

Once again I posted a complete program for you which will scan a folder and find pdf's in any subfolders, compress them, and copy the same folder structure to a new destination.

I know. But I cannot get it to work. I wrote these posts before concerning the issue:

http://www.autoitscript.com/forum/index.ph...st&p=379713

http://www.autoitscript.com/forum/index.ph...st&p=379880

[james3mg]

If you still have the .txt list that we created earlier however, you could use FileReadLine in a loop to get the data stored in that .txt file into an array. That way, you won't have to worry about deleting any characters by using StringSplit. HOWEVER, realize that list is static...if someone puts a new pdf file on the network, you won't be doing anything to it, because it won't be in that list. For that reason, I would suggest you just realize that the time it takes is an unfortunate necessity of working with that many files, especially over a network.

If, however, you still want to just practice getting a list into an array from the .txt file list:

Just because this is an excellent learning exercise, I'm just going to tell you that you need to FileOpen() the file, then have a loop that reads your file line by line (use FileReadLine() ), using ReDim or _ArrayAdd to cause the array to grow by one element each time it loops. (You'll probably use a While 1...WEnd loop to set up an infinite loop, then use Return within the loop when you want to exit the loop [lit. when you reach the end of the file]).

Try to write a standalone script that does nothing but read the contents of that .txt file into an array, then use _ArrayDisplay to show you the results (Don't forget to FileClose the .txt file at the end of your script, and to include Array.au3 at the top). If it works, you'll realize just how much you've learned about AutoIt (btw, it WON'T work the first time...try to debug it a few times...I almost never have a script that works the first time after I write it). If you can't get it debugged, feel free to ask for help (post your code for this standalone script), it would just be good for you to give it a shot yourself first. But remember, if you want to do it, this is just an exercise - you really need to generate a complete list each time the program is run for your final script.

Your final script will need to go through all the files stored in the array and filter out the stuff you don't want to do anything with (using functions like FileGetSize, FileGetAttrib, FileGetTime, and possibly comparing the filename to a list you could generate of files that you specifically want to exclude (which could be generated by your script as well...maybe files which have already been compressed but are still bigger than your desired threshold). You can use _ArrayDelete to remove filenames from the array of files, so that the array will simply be a list of files for the script to compress.

Edited July 31, 2007 by james3mg

[ConstantineGeorgantzas]

Try to write a standalone script that does nothing but read the contents of that .txt file into an array, then use _ArrayDisplay to show you the results (Don't forget to FileClose the .txt file at the end of your script, and to include Array.au3 at the top). If it works, you'll realize just how much you've learned about AutoIt (btw, it WON'T work the first time...try to debug it a few times...I almost never have a script that works the first time after I write it). If you can't get it debugged, feel free to ask for help (post your code for this standalone script), it would just be good for you to give it a shot yourself first. But remember, if you want to do it, this is just an exercise - you really need to generate a complete list each time the program is run for your final script.

[/qoute]

Here is that exercise you outlined:

#include <Array.au3>

Global $FileArray

;Run(@ComSpec & ' /c start "" "'&"\\Ny_fs1\Corp\Group"&'\filesfound.txt"', "", @SW_HIDE);run does not return a handle
$handle = FileOpen(@ScriptDir & "\filesfound.txt", 0);returns no error

While 1
    $line = FileReadLine($handle)
    If @error = -1 Then ExitLoop;if the end of the file is reached then stop reading
    _ArrayAdd($FileArray, $line)
Wend

_ArrayDisplay($FileArray)

FileClose($handle)

The way it stands now nothing happens and the computer does not report errors. If I use the Run function as opposed to the line beneath it, at least notepad and the file open, but I cannot understand why FileOpen() doesn't do do that. I cannot tell why one would chose to use FileOpen instead of ShellExecute or Run . I also never see the array displayed, but the computer never notifies me of an error.