PDF XChange Forum

Hi!

I have another suggestion to make concerning custom tools. So far the only way to call a custom tool from a batch is to call PDFTools with the tool's ID (apparently a GUID). Why not call it by its name like any standard tool. All it takes is for users to give their custom tools a unique name and unicity could easily be checked by the program when a custom tool is created.

Apart from providing a more homogeneous way of calling tools, this would have several advantages: (1) the registry wouldn't get even more bloated than it is already; and (2) this would make a future portable version of PDF-Tools possible.

Indeed having a portable version of PDF-Tools would be a great improvement for obvious reasons. I hope this will happen some day...


Thanks - JLM

Hi Jean-Luc,

Thanks for the post - We've recently implemented the ability to copy the GUID to make this easier:


I'll ask if it's possible to allow for the names to be used, but I can't make any guarantees.

Thanks,

Hi Jean-Luc,

Why not call it by its name like any standard tool.

Its not correct for standard tools because you cannot run such tools by specifying just their display names. Here is simple misunderstanding because for identifying of standard tools we use non-GUID(but unique) identifiers like:
"pdft.tool.addWatermarks"
"pdft.tool.resizePages"
"pdft.tool.deletePages"

Obviously these are not display names. But surely there is special possibility to use in cmd-line an parts of standard IDs like:

"addWatermarks"
"resizePages"
"deletePages"

- it might look that display names of standard tools can be used in cmd-line, but it is not true.

-----------

In the future we may allow the launching of custom/standard tools by specifying just display names, but it is not reliable way for sure.
Also we still have question: what special purpose do you have to use the tool's display-name instead of reliable ID?

Cheers.

Hi Vasyl!

Thanks for your explanations concerning the standard tools' IDs. The fact is that I have never been able to use any of the standard tools as they are. I have always had to create custom ones to fit my needs. In any case, the manual (on which my assumptions were based) would need to be updated, or at least the examples it provides. For instance, on page 177, one example of a command-line is:
PDFXTools.exe /RunTool:showprog=no;showrep=no imagesToPDF "c:\picture1.png" "c:\picture2.png"
This could be corrected.

That said, I have no problem with GUIDs as such, except that they are not portable. You ask what special use I have for non-GUID names. I do precise analysis, standardisation, reformatting and restructuring of large PDF libraries in order to improve their accessibility and usability. To this end, I have designed a number of home-made utilities written in various scripting languages (Lua, Python, AutoItScript) which call specialised command-line tools (mostly PDFTools, Coherent cpdf and pdftk). All these toolds are portable, except PDFTools, because of its use of GUID-based identifiers. So, for the time being, your software is installed on my laptop which I have to ferry around with me to the various places where these libraries are stored and, each time, establish some sort of network connection with the computers hosting these libraries. It's manageable, but very inconvenient,

So I am thinking about the future. It would be much more convenient to have a portable version of PDFTools which could be carried around on a USB stick, together with the other command-line tools and utilities mentioned above, to wherever they are needed. The problem, of course, is that GUI-based identifiers are tied to a particular machine's registry, so cannot be portable. Hence my suggestion.

Of course, I agree that GUID-based names are reliable. But it seems to me that, on balance, the "cost" for this reliability is disproportionate. Surely, you keep a dictionary of the custom tools' names created by the user within some internal database, together with their definitions, for each instance of PDFTools. Wouldn't it be simpler and just as reliable to test the uniqueness of a custom tool when it is created. Or am I missing something?

I would add that, based on a long experience of Windows, I find that Microsoft's use - and abuse - of the registry is a source of instability and security leaks which is not justified by its obvious advantages.

Cheers, JLM

Hi, Jean-Luc.

That said, I have no problem with GUIDs as such, except that they are not portable.

Its not correct, because you may easily export your custom tools (by common Export Tools from the Options menu or Export Selected Tools from the context menu) from one machine and import them to another machine as well. Can you use simple export/import features for your tools?

Cheers.

Hi Vasyl!

Ok, I'll try your suggestion with the export feature, and I'll keep you informed of the result.

Thanks for your help!

JLM

Hello JLM,

Please do keep us posted once you've had the chance to try it out!

Regards,
Stefan