Freitag, 29. Mai 2015

Determine dpi-values from pdf- and image-files

I just received an e-mail inquiry from a customer with the question how to determine the dpi values from PDF and image files ...

The dpi value can be calculated in an easy way.
1 dpi means 1 pixel per inch and 1 inch has 2.54 cm.
An image file with a width of 1024 pixels and 10 cm width has a dpi of (1024 x 2.54) / 10 ... so in this case 260 dpi.

An A4 PDF has the standard dimensions of 595 x 842 pixels.
With 21 cm width and a pixel width of 595 this results in:
(595 x 2.54) / 21 ... so you get the common 72 dpi.

This means if an A4 PDF page is rendered directly to an image file, the quality won't be great, because the quality has a fix limit of 72 dpi.

Dienstag, 23. Dezember 2014

Foxit versus Adobe ... or "David against Goliath"

Since many years now Adobe as the driving force keep on publishing their pdf format as a "de facto standard" mainly established for online and graphical documents. Due to the fact that a document standard should be usable for all users (for reading) Adobe published the free Adobe Reader for PDF documents.

Of course pdf documents have to be created before reading ;-) On one hand there are the normal documents but on the other hand the pdf-format is well suited for all types of forms. By embedding e.g. JavaScript actions and buttons much life can be breathed into pdf forms.

For all these things, there are a number of Adobe products - paid products in a high cost range. Since version 1.0 of the PDF specifications many years have passed and with each new version of an Adobe Reader installation the required harddisk space increased by many megabytes. This fact called the Open source community into action. Source Based on a free library like e.g. Ghostscript alternative ways of free PDF creation as printer drivers were developed. These printer drivers are usable inside most office products. Two well known free pdf printer drivers are PDFCreator and FreePDF. In the meantime there are some more free pdf readers published. There are portable versions, too. So there's no need to install - only copying anywhere onto the harddisk. That's all. 

One of the best adobe alternatives - perhaps the best - regarding free pdf readers is the well known Foxit PDF reader. While an Adobe Reader 10 installation needs about 457 mb harddisk space, the Foxit Reader 5.4.2 comes along with slim 44 MB! ... And less megabytes means less harddisk space and this means often higher processing speed and a faster start, too! An additional hint: If you only want to read/show pdf documents the small "Sumatra PDF" (specially the portable version) is all you need.

What could be the reason for a big company like Adobe spending a lot of money to establish a document standard? ... Of course 'cause they are always the first with new pdf-products to earn money ;-)  So actually there's not only the Adobe Reader but also the high-priced products from the Adobe Acrobat series that allow everything related to the creation of PDF documents.

That pdf-products can be much cheaper (with a comparable quality) is proving the Foxit Corporation - Manufacturer of the free Foxit PDF Reader. Started with the free Foxit pdf reader, now the company offers a wide range of lean and more cost-effective products for the development and editing of pdf documents. The products are running on nearly any technical basis (windows, iOS, Android, ...). This ranges from applications for PDF editing and creation up to complete developer sdks. All this with a very "nice price" licensing procedure.

As a developer in the pdf environment of course i have several products and versions of pdf readers and various versions of the Adobe Reader installed. This allows me for example to say "runs on Adobe ... too". But in my daily business i'm just using the Foxit Reader - Give it a try ;-)

Donnerstag, 19. Dezember 2013

PrPages now supports “gray value tolerance”!

The new option “gray value tolerance” makes PrPages rather complete. What is the purpose and sense of this value which is also known as "gray balance"?

Because sometimes slightly shading gray colours could be interpreted as very slight light blue or pink color tones for example some main printer-drivers are working with an optionally so called “gray value tolerance” or "gray balance".

PrPages splits each pixel of the pdf-page into the three rgb-values. The “gray value tolerance” represents the difference between the highest and the lowest rgb-value. A value of 15 (by the way
that’s good practice) means that the highest and lowest colour-value (the values are from 0 up to 255) of a pixel can differ at most by the value 15 and still be interpreted as a shade of gray.

Without a tolerance value even the smallest deviation leads to a colour-detection because the slightest difference means that it's not real gray.

Summarized it could be gray or … perhaps a very, very light blue? Anyway not an absolutely clear gray – so there are few coloured pixels on a page and it’s up to you what you want. Some main printer-drivers are working with optionally “gray value tolerances” and if you need identical results
for your work or accounting you should use these option with PrPages, too.

Montag, 3. Dezember 2012

Analyze PDF-documents for coloured pages

The calculation of printing costs for pdf-documents separated
for each serviceline or department in a company is always a
problem. How many pages - coloured or black & white - were printed?
Which were the dimensions of the printed pages? Which are the
responsible company departments? And finally: Who should be
responsible for the costs of new toner cartridges?

Internally the pdf-structure offers the device-flags like
- for example - DeviceRGB, DeviceGray oder DeviceCMYK which
points to the used colours in the document. Better: It could
point 'cause it's not a must to use device-flags in the pdf-
document. It's possible to have coloured pages in a document
with DeviceGray and it's possible to have coloured and b/w-pages
in a document without any device-flag and it's possible to
have only b/w-pages in a document with DeviceCMYK and so on...
So the device-flags are only indicators for the used colour-
models in a document but not a save method to determine
coloured pages.

This is a big problem in service-departments! There are
solutions available ... very expensive solutions.

For the described purpose i'm offering in my product range
the module "PrPages". It's a so-called command-line exe.
A batch executable means easiest installation with all
applications and workflows in 32 - and 64-bit Windows
environments without any problems!

The module's approach is that the real colour informations
are in each image pixel and based on this informations
you can make the only reliable statement regarding the
used colours on a pdf-page.
The graphic type bitmap offers three values for colour-
settings on pixel level. "PrPages" renders the pdf-pages
temporarily into bitmap format and checks the pixel values
for the colour informations to analyze the pages as b/w or
Depending on the options you have set, a csv-file is created.
Each line contains the filename, the page count, the page
size of the first page, the pagecount for coloured and
the pagecount for b/w-pages.
Another option results in one line for each pdf-page with
the filename, single page number, the page size and a note
for b/w or coloured.

Depending on the system environment the module works with
high performance using a safe and stable technology.
On my product pages you'll find the "PrPages" as a trial
version to check if the tool is the right choice for your
purposes - Try before you buy.

Montag, 9. April 2012

PDF, JavaScript and Code you don't want

My dear readers!

Regarding trojan- and virus-attacks often you can read about pdf-documents entering your local machine as email-attachments. While opening these attachments it's possible that embedded trojans and other malware will be installed unvisible or system settings could be changed.

This works via scriptlanguage JavaScript. With embedded JavaScript-code the functionality of a pdf-document can be greatly expanded. The embedded code will be coupled with an event like OnLoad (that's while a document will be opened) and then executed if the event happens. Normally this is a positive thing but it may also be to your detriment.

Installing your Adobe- or Foxit-PDF-Reader (which are able to interprete Javascript-Code) it's a standard that using Javascript is activated. It's an optional setting which can be deactivated by you again.

Deactivating Javascript in Adobe Reader 9 or 10 (for example) you can go this way:

...Edit -> Preferences -> JavaScript...

in the right window section you can remove the marks in the checkboxes at
"Java Script / Enable Acrobat JavaScript" and
"Java Script Security / Enable menu items Javascript execution privileges".

Deactivating Javascript in Foxit-Reader 5 goes like this:

...Tools -> Preferences -> JavaScript...

Remove the mark at the checkbox at
"Enable Javascript actions".

If you don't want to deal with such things and if an easy pdf-reader is enough for you should try the small and easy to use Sumatra PDF Reader which aren't able to interprete JavaScript.


Mittwoch, 2. März 2011

Printing pdf from your app

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);
// At the uses-part don't forget the ShellAPI ;-)

// Show/open the pdf-document ...

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

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

// Virtual key [ENTER] to start printout ...

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

// Virtual keys [Alt] + [F4] to close the active reader-window ...


Montag, 29. März 2010

From PDF to SAP SmartForms ... automatically

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!