PDF ... inside and outside

Printing pdf from your app

2011-03-02T13:38:00.000-08:00

My dear readers!

I've got a user call having to do with printing from a self made application by using the installed pdf-reader (try Foxit... the best for me!).
I've tried some time using the Keybd_Event-syntax from my Delphi/Pascal for virtual key-activations.
If you're using Delphi or Free Pascal you can put the code below directly into a button-event (OnClick) of your application. Other programming-languages will offer a pretty similar syntax. With the sleep-property you can do some experiments.

procedure TForm1.Button3Click(Sender: TObject);
begin
// At the uses-part don't forget the ShellAPI ;-)

// Show/open the pdf-document ...
ShellExecute(hinstance,'open',PChar('c:\temp\test.pdf'),nil,nil,SW_NORMAL);

sleep(2000); // sleep/wait for 2 seconds

// Virtual Keys [Strg] + [P] to open the print dialog ...
Keybd_Event(VK_CONTROL,0,0,0);
Keybd_Event(Ord('P'),MapVirtualKey(Ord('P'), 0),0,0);
Keybd_Event(Ord('P'),MapVirtualKey(Ord('P'), 0),KEYEVENTF_KEYUP,0);
Keybd_Event(VK_CONTROL,0,KEYEVENTF_KEYUP,0);

// Virtual key [ENTER] to start printout ...
Keybd_Event(VK_RETURN,1,0,0);
Keybd_Event(VK_RETURN, 1, KEYEVENTF_KEYUP, 0);

sleep(2000); // sleep/wait for 2 seconds

// Virtual keys [Alt] + [F4] to close the active reader-window ...
Keybd_Event(VK_MENU,0,0,0);
Keybd_Event(VK_F4,0,0,0);
Keybd_Event(VK_F4,0,KEYEVENTF_KEYUP,0);
Keybd_Event(VK_MENU,0,KEYEVENTF_KEYUP,0);

end;

From PDF to SAP SmartForms ... automatically

2010-03-29T03:52:00.000-07:00

My dear readers!

The reason in short ...
We had planned a banking product for several eligible customers based on an extensive form management in SAP Smartforms. We were facing problems like "only pdf-forms available" or "old pdf-forms should be completely redesigned". For a bank this can mean that hundreds of forms have to be converted... and the time is always short ;-)

Starting this project we knew that the needed new form creation in SAP Smartforms and the insertion of the recent pdf-forms into SAP would be the biggest time-package – not easy to be calculated. We discussed the idea to create a converter to manage at least the simple tasks of converting in an automatic way.

We had to regard two starting positions:
There were pdf-forms which should be transfered to SAP.
There were pdf-forms which should be completely redesigned before transfering to SAP.

Our basically idea was to extract the pdf-formfield data and properties, insert the data into an xml-structure and using the xml-uploadfunction in Smartforms as the final step. There were forms with less data and a clear structure but also very detailed and overcrowded structures. So we kept in mind that sometimes it would be probably necessary to turn a few screws directly in the converter source. The second part of the work should be the new designed forms. Here we started directly from scratch, creating doc-prototypes with associated technical files containing the formfield-properties. So no existing pdf-form for us. We decided to manage this problem with a different version of the converter. Both converter versions should be developed as a .NET-application. We used C# as ide.

Behind the converter-gui there are batch-modules (developed with Delphi as commandline-tools) doing three jobs for us:
• Extracting the main form-properties like used fonts, the form dimensions, date and time of creation, and so on.
• Extracting all form-fields with name, position values and field-lengths.
• Converting the displayed form content into a tiff-file, regarding the SAP tiff-specifications and the needed dpi-value as a backgoundimage for Smartforms.

The next point was a valid xml-structure to have a look inside. We got it doing a local xml-download of an existing form from Smartforms. We analyzed it, determined the parts which would be always the same and the parts which would be changed programmatically with variable values. We splitted the xml-structure into constant and variable templates. In the templates we signed the significant positions with unique placeholders. Our converter should transform all these things like form properties, field data, reference to the backgroundimage, constant and modified templates as the final step into one new xml-file for the Smartforms-upload.

To prepare Smartforms for the xml-upload first we have to create one single time a formstyle with all possible fontstyles used in the uploaded forms. Another point are the backgroundimages. They are created automatically while generating the upload-xml-structure but the local tiff-files still need to be transported into the SAP Form Graphics Administration (transaction SE78). At this time the referenced link is already in the xml-structure.

So the steps for existing pdf-forms are:
• Starting the converter.
• Selecting a pdf-form and moving through the converter-steps.
• Uploading the new tiff-file via transaction SE78 into SAP.
• Uploading the new xml-file into SAP Smartforms.
• Activating the new form in Smartforms. …That’s it!

At least the converter version for the non-existing forms… In this case the workflow is a bit different. The form properties are already extracted `cause we have the ascii-files with all form- and formfield-properties and bmp- or doc-prototypes.

First step is to convert the bmp- or doc-file into the tiff-format according to the SAP specifications. We’re using for this job the free graphic application „Gimp“. Although „Irfan View“ would be a good candidate for this job we should keep in mind that this application is only free for personal use. Then these tiff-files will be transfered into the SAP Form Graphics Administration (transaction SE78), too. Instead of grabbing the form- and field- properties from the pdf-form via commandline-tools the second version of the converter can read the needed data out of these technical ascii-files which come along with the bmp-prototype. At this stage the flow is the same. The xml-file will be created … uploaded …

So the steps for completely new forms are:
• Converting the bmp-file into tiff-format
• Uploading the new tiff-file via transaction SE78 into SAP.
• Selecting the technical form-data-file moving through the converter-steps.
• Uploading the new xml-file into SAP Smartforms.
• Activating the new form in Smartforms. …That’s it!

There’s one restriction: The described procedures concentrates themselves on the main task – creating single-page-forms. Sure it’s possible to enhance the converters for multi-page-forms but in our special case the cost-benefit ratio wouldn’t have a good relationship.

All together we had to convert approximately 300 forms. Normally this work would have lasted 100 days. With our converters we could do this job in less than 10 days!

Another kind of fast web access!

2009-11-18T11:25:00.000-08:00

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.

Under the surface ...

2009-09-23T02:03:00.000-07:00

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 ;-)

PDF and forms

2009-06-20T07:11:00.000-07:00

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