Post reply

Message icon:


shortcuts: hit alt+s to submit/post or alt+p to preview

Topic Summary

Posted by: RTT
« on: January 09, 2013, 06:06:39 PM »

Unfortunately no. I made some changes at the time, but because I hadn't Bridge at hand I didn't tested it that day, and then forgot completely.
The current code isn't working, but just now finished to test it and added the needed changes to make it work. Fix will go out in a next week patch release.
Thanks for pointing this out, again. My bad :(
Posted by: Roger
« on: January 09, 2013, 03:24:56 AM »

Is the Bridge keywords issue resolved in the new version 2.1 of PDF-ShellTools?
Posted by: RTT
« on: May 11, 2011, 04:02:09 PM »

This happens because Bridge edit/update the keywords field in the DC XMP section, but not in standard PDF metadata object, as it should (as stated in the PDF file format specifications), leaving these two places, where PDFs keep the metadata, unsynchronized.
To speed up the process, PDF-ShellTools gather the metadata only from the standard metadata object, so it misses these changes made by Bridge.
It all be OK if the metadata is edited by PDF-ShellTools, because it follows the rules and update the metadata in all the places.
Next step should be to make PDF-ShellTools and PDFE behave like Acrobat, and give preference to the XMP, when collecting metadata, if it exists, and only to the standard metadata object if it is the only available.
Posted by: Roger
« on: May 11, 2011, 05:47:18 AM »

Any progress on the "Bridge keywords"

I am using PDF shell Tools 12 release 2 and I still cant see the Bridge keywords (or Dublin properties)

Am I looking in the wrong place?

Posted by: science2002
« on: February 15, 2011, 01:47:07 PM »

Well done. Curious to test it!
Posted by: RTT
« on: February 13, 2011, 04:15:22 PM »

It works pretty well  ;)
Posted by: science2002
« on: February 13, 2011, 04:07:15 PM »

I am unprepared about licencing and Open source intricacies. I should say, however, that also Total Commander (in some versions at least) is a commercial product.
Posted by: RTT
« on: February 12, 2011, 11:56:58 PM »

If the PDF reader you are using is Acrobat, you can setup PDFE to control it directly, without delegate the load to IE.  Menu Edit>Preferences - Internal PDF Reader option set to "Adobe Acrobat".
Acrobat 9, and the new 10, are really fast, but only if enough RAM is available :)
The Foxit Reader, early 2.x versions, are also very fast.

I'm not sure I can use the total commander plugins interface in a commercial application. Even if I don't distribute the plugin, I need to use the same interface to integrate it.
Or maybe I can?

And the Sumatra project really needs to be integrated in a browser plugin.
Posted by: science2002
« on: February 12, 2011, 11:50:15 AM »

Thanks for pointing  your products to my attention. Looking forward to the patch. Here I am still with WinXp, no W7 (which also is resource intensive). Let me add another suggestion that could be helpful. The PDF view window in PDFE takes a bit of time to render, and part of this time probably is for using internet explorer intermediation. I saw a very small  plug-in (freeware) made for total commander that uses sumatra PDF, which is really fast: an almost instantanous opening, which is completely independent from the rest.
See this link

Sumatra PDF in fact  even with today version of PDFE is faster than other viewers, but it opens as an outside window, not an integrated one, since it has no ufficial ie plug-ins.
Posted by: RTT
« on: February 11, 2011, 11:14:44 PM »

do you have any rough time schedule for the next patch?
Soon, but can't say for sure yet. I need to fix some things before it get ready to go out. But my other tool, PDF-ShellTools, build 12 patch 1 will go out next week. The two tools share the edit metadata code, and this fix will be included, so you can test it soon. If you have Vista or Windows 7, editing the metadata properties with the Property Handler is really easy.

what do you think to make PDFE also a PDF file organizer, with virtual collections (Adobe name) or libraries (MS W7 name
That's something that is in the list of features to develop almost from the beginning of this project, but I need to first redesign the database code, to make it the way I envision it.

the way Bridge allows filtering is really great, and much more intuitive and flexible than PDFE does
Yep, but doing that for the amount of files PDFE can have indexed in the database, isn't easy. But I agree that many things can be improved, and the use of these filter techniques for in the grid files filtering is one of these things.

Bridge eats up so much RAM and HD space that one gets a shock
:) It's really incredible the amount of resources these Adobe tools need!
Posted by: science2002
« on: February 11, 2011, 08:33:13 AM »

Thank you for taking care of this issue. Without  any commitment, do you have any rough time schedule for the next patch?

More on the long run: what do you think to make PDFE also a PDF file organizer, with virtual collections (Adobe name) or libraries (MS W7 name)? A final suggestion: the way Bridge allows filtering is really great, and much more intuitive and flexible than PDFE does. On your front: Bridge eats up so much RAM and HD space that one gets a shock. Your PDFE is crisp and responsive even in low end machines. That's wonderful! Thanks again.
Posted by: RTT
« on: February 10, 2011, 11:54:48 PM »

PDFE already updates the PDF's XMP data, for the PDF standard properties.
I need yet to develop code to add the PDFE custom defined, and evolve also the editor of custom defined properties in order to be able to map the custom properties to an arbitrary namespace/schema.

But I have checked for what's going on with the Keywords property and indeed there is something that needs to be changed. Acrobat puts the keywords in two namespaces.  In the "PDF Properties", and in the "Dublin Core Properties", see attached image (what you see in the xap namespace related to this, and some other properties, is only the mirroring of these other effective data store places).
PDFE is editing only the first namespace. I have checked, and Adobe Bridge, with the default installed schemas, only read/write this property in the Dublin Core namespace, so that's why PDFE misses the keywords edited by the Adobe Bridge, and vice-versa.
I've now changed the code, and seems to be working fine. It will go out with the next patch release.

Thanks for pointing out the problem ;)
Posted by: science2002
« on: February 10, 2011, 10:57:11 AM »

After looking with a geek friend at ways to make organization on my pdf files, he showed PDFE and Adobe Bridge (vCS4 sold with InDesign and other Adobe products). The latter is geared to images, but works very well with PDFs, showing onthefly thumbnails.

I was impressed of both products, but he showed me the following: the keywords made by PDFE (for instance in a PDF file v.1.3) does not show in the metadata by Bridge, and vice versa. Both of them obviously save the Keywords in the PDF file, but under different places. I understood that Adobe uses the metadata standard Xap - XMP, while PDFE, may add keywords in the metadata (old) dictionary, which is no longer used by Adobe and other programs (like X-change pdf viewer, that my friend uses as a pdf reader) to show keywords.
I hold a copy of Bridge, and I am looking (my dream) to make it compatible with PDFE, so to be able to use both of them without losing the keywords.

1. Is there any possibility that PDFE writes and reads the pdf keywords also in the Xap - XMP standard? Or is it possible at the moment to make PDFE at least just read this latter standard, that Adobe and other applications use extensively?

2. I would like to ask the same question to Adobe, i.e. why its applications (Bridge in first instance, but not only) are unable to detect the PDF keywords tagging of PDFE. For such purpose, could you be precise on what standard PDFE uses to add keywords to PDF?

Thank you in advance for any clarification on this issue. I shall say that I am very confused on PDF keyword tagging -- a feature, I suppose,  that was created to reduce confusion!