My dear readers!
Are you offering free pdf documents on your webpages?
Are these pdf documents very large?
Is the free traffic in your web-package limited?
To prevent bad surprises and to gain new interested web-visitors you should try my app PDF-Analyzer Pro or my PDFIndexCut.dll (for using in batch).
I'll tell you why ...
If you want to upload a large document you should think at the interested user with a slow internet-connection, too.
It doesn't matter if you're using the linearized (fast web access) option while creating the document. Sure... the user can read the first pages very quickly but in the background the pdf-download grows more and more on his local harddisk. Often enough after reading the first pages the user knows that the document is worthless for him - one worthless download for him and worthless traffic for you as the website-owner, too.
Using my PDFIndexCut it's possible to separate documents in two parts - the first one we can call the index-part and the second one the content-part. The index-part should contain only the title-page and the index or the first starting pages. In the index-part there are free positionable links to the content-part.
If these two document-parts are online the interested visitor can open/download the small index-part to get a first impression about the whole document if it could be useful for him or not. If it seems to be useful he can click on the content-link in the index-part to open/download the large content-part. If it seems to be useless for a user there's only a small download and not mbytes of useless pdf-garbage on the local harddisk and you as the website-owner can keep the traffic low.
PDFIndexCut has options for the pagenumber where the document shall be separated, for the positions of the content-link and for the content-link-text. PDFIndexCut is very flexible and should feed your needs, too.
If you have only less large documents you can use my app PDF-Analyzer Pro 'cause the functionality from PDFIndexCut is there implemented.
Give it a try... there's a testversion available online.
Mittwoch, 18. November 2009
Mittwoch, 23. September 2009
Under the surface ...
Did you ever had the idea to look inside the real pdf-code while looking through a pdf-document? If you have some technical understanding this can be very interesting for you. What do you need for this? You already have everything to look inside... Try your editor "Notepad" from your windows-system. With a little bit luck you'll see that the internal pdf-code is readable, too.
The first important information you'll find at the beginning of the pdf-file. There's something like "%PDF-1.3%âãÏÓ" (for example). Some characters you can ignore but the "PDF" shows you that it's a pdf-file (what a surprise). The "1.3" means that this document was created according to the (older) pdf specification 1.3.
Now you should try the search-function from your editor...
Try a search with "FontName". Sure you'll find more than one entry in your code showing you all embedded/used fonts in your document. Such an entry could look like this one: "/FontName/Arial-BoldItalicMT/".
Some other interesting searchkeys/tags for you are: "Creator", "CreationDate", "Producer", "ModDate", "Title", "Keywords" or "Subject" for example. If you can't find a tag, this means only that there's no content for it. If there's no maintained title for the document you won't find the tag "Title" in the code.
If the document is encrypted the text following the tags isn't readable but even this gives you an information about the document ... it's an encrypted document ;-)
Finally another interesting tag "Count" oder "/Count". Here you'll find the pagecount of the document. This could look like here: ".../Count 9/...".
A little more appetite for PDF? Time to go on discovering ;-)
The first important information you'll find at the beginning of the pdf-file. There's something like "%PDF-1.3%âãÏÓ" (for example). Some characters you can ignore but the "PDF" shows you that it's a pdf-file (what a surprise). The "1.3" means that this document was created according to the (older) pdf specification 1.3.
Now you should try the search-function from your editor...
Try a search with "FontName". Sure you'll find more than one entry in your code showing you all embedded/used fonts in your document. Such an entry could look like this one: "/FontName/Arial-BoldItalicMT/".
Some other interesting searchkeys/tags for you are: "Creator", "CreationDate", "Producer", "ModDate", "Title", "Keywords" or "Subject" for example. If you can't find a tag, this means only that there's no content for it. If there's no maintained title for the document you won't find the tag "Title" in the code.
If the document is encrypted the text following the tags isn't readable but even this gives you an information about the document ... it's an encrypted document ;-)
Finally another interesting tag "Count" oder "/Count". Here you'll find the pagecount of the document. This could look like here: ".../Count 9/...".
A little more appetite for PDF? Time to go on discovering ;-)
Samstag, 20. Juni 2009
PDF and forms
My dear readers!
Today i want to write about pdf and forms. A good topic for adobe - a bit like a money machine ;-)
In the past we're happy to fill a pdf-form directly on the monitor ... then doing the printout ... 'cause saving the formfield data with the adobe reader wasn't possible ... and the next time we would fill the data again ... :-(
These were the good old days if we're knowing only the free adobe reader for reading pdf documents...
Now there are better days. Since a while there is the free foxit pdf reader on the market. Faster and more slim than the adobe reader. With all functionality what the "normal" user in front of the monitor requires. ...And he can fill in formfields, and he can save the filled formfields, and if the form is loaded again these values can be changed... and saved again ...! The foxit reader is my absolute favorite!
What does the "great pdf inventor" ...? No. He doesn't enhance his pdf reader... but he enhance his form creation tools and build in check routines to proof if a form (created by an adobe tool) was changed by another pdf tool. What does this mean? If a form made by an adobe tool was changed (and fill in data and save it into the form is a modification) is opend by the adobe reader all form fields are not usable anymore!
I've made this experiences with a form made by the adobe product "InDesign".
But there's no problem without a solution. And if we don't have the solution then we have to create it ;-)
Soon i'll create a tool (dll or application ... we will see) which can take all properties and formfields from an adobe form building a new quite similar form without all these check routines. With these form we can work with the adobe reader and the foxit reader and ... without these annoying restrictions.
[All used names of trademarks, labels and companies are under the copyright of the respective companies and belongs to these companies or individuals.]
Cheers and a nice day,
Ingo Schmoekel
Today i want to write about pdf and forms. A good topic for adobe - a bit like a money machine ;-)
In the past we're happy to fill a pdf-form directly on the monitor ... then doing the printout ... 'cause saving the formfield data with the adobe reader wasn't possible ... and the next time we would fill the data again ... :-(
These were the good old days if we're knowing only the free adobe reader for reading pdf documents...
Now there are better days. Since a while there is the free foxit pdf reader on the market. Faster and more slim than the adobe reader. With all functionality what the "normal" user in front of the monitor requires. ...And he can fill in formfields, and he can save the filled formfields, and if the form is loaded again these values can be changed... and saved again ...! The foxit reader is my absolute favorite!
What does the "great pdf inventor" ...? No. He doesn't enhance his pdf reader... but he enhance his form creation tools and build in check routines to proof if a form (created by an adobe tool) was changed by another pdf tool. What does this mean? If a form made by an adobe tool was changed (and fill in data and save it into the form is a modification) is opend by the adobe reader all form fields are not usable anymore!
I've made this experiences with a form made by the adobe product "InDesign".
But there's no problem without a solution. And if we don't have the solution then we have to create it ;-)
Soon i'll create a tool (dll or application ... we will see) which can take all properties and formfields from an adobe form building a new quite similar form without all these check routines. With these form we can work with the adobe reader and the foxit reader and ... without these annoying restrictions.
[All used names of trademarks, labels and companies are under the copyright of the respective companies and belongs to these companies or individuals.]
Cheers and a nice day,
Ingo Schmoekel
Abonnieren
Posts (Atom)
