>- is it possible to call an Acrobat plug-in from a VB6 program ? (I saw that a plug-in is an .api file rather than a .dll)

Not directly. A plug-in is loaded by Acrobat, and Acrobat allows the
plug-in to register menu items, tool buttons and so forth. So it is
Acrobat that calls the plug-in, always.

It is possible for an external program to ask Acrobat to run a menu
item, and so run part of a plug-in. But passing parameters is a
separate issue - for example you could put parameters into a file.
>
>- do PDF Optimizer functions like AVDocSaveOptimized can be called from a C/C++ standalone application ?

The Acrobat SDK cannot be used to make standalone applications:
Acrobat always does the work. The methods available to you are IAC,
which can be a standalone executable using Acrobat, and plug-ins,
which are part of Acrobat. AVDocSaveOptimized is only in the plug-in
API.

So, the way to go in this would be to create a plugin that saves a file as optimised. This plugin would register a menu item and this menu item could be called from the VB or C# app via Acrobat API. Right?

In this scenario, would it still be possible to have a single installer file for the PDF optimiser tool? That is which also installs the Acrobat plugin?

> his plugin would register a menu item and this menu item could be called from the VB or C# app via Acrobat API. Right?

This should work. You still have to consider what back door would be
used to pass parameters, or whether you need parameters (for example
it could just act on the currently open front document).
>
>In this scenario, would it still be possible to have a single installer file for the PDF optimiser tool? That is which also installs the Acrobat plugin?

You mean, could you write an installer that installed an executable,
and also a plug-in, given that someone has already purchased abnd
installed Acrobat? I don't see why not, but bear in mind that the
location for the Acrobat plug_ins folder is not fixed.

left->right, top->bottom is only true for Roman language documents. For Hebrew or Arabic, for example, it's right->left. For Chinese or Japanese, it may be top->bottom, left->right (for vertical text).

If you are planning to do text extraction on PDF, there is a LOT of complexity involved...

I'm lost on this, as well. How, programmatically, do you optimize? I will be running this process as an automated service, so menu items would be out of the question. It will be a .net windows service that scans a directory, appends the PDFs and optimizes them. How do I go about doing this?

'For i = 0 To PDFfiles.Count - 1
' fileNames(i) = PDFfiles(i)
'Next i
If PDFfiles.Count = 0 Then
'FileSet.LogMessage("No files were found for this set. Output File was going to be " & outputFileName)
Exit Function
End If
tempFileName = Path.Combine(outputDir, "temp.pdf")

In adobe there is a function by which you can right click on a group of files, and choose to concatenate them, with a menu option for making the file size smaller. I have tried to scour the documentation for a way to automate this, and have found nothing. Is this at all possible through the SDK?

What's odd is I found a way to combine the PDFs, then save as postscript then distill, but it takes 12 hours, mostly the PDF conversion. the combine and shrink takes about 5. I essentialyl just need a way to shrink the PDF without making postscript of it.