Question on optimization for PDF files, copy fillable forms, delete redundant fonts

as promised some weeks ago we are now starting with this optimization development. Could you please provide an official offer web page for the font subset tool, which we can use to order?

We just want to make sure that the new solution is going to keep PDF/A compliance, if required. Additionally it should also keep meta information and form fields.

We are also going to buy Advanced PDF Tools Command Line v3.0 to achieve additional compression for existing PDF files. I assume that we have to buy the "Developer license" to redistribute the solution as usual.

Thank you very much and best regards,
===========================
Thanks for your message, please email to us some sample PDF files for test purpose, your sample PDF files will helpful for us to test the font subset function.

If your input PDF file is a PDF/A format, we can keep PDF/A format in output PDF file, that's no problem.

We can keep meta information in output PDF file.

However, we feel difficulty to keep fillable forms in output PDF file, because in our past test, the characters in form fields will become garbage after font is subsetted, the user can't input correct characters into text
form fields in the future. In general, we will "flatten" fillable form fields automatically during compression.

Also, please notice, the fillable form fields is not supported by PDF/A format, if your input PDF file is contain fillable form fields, we sure it is not a PDF/A format, we can't keep fillable form fields in a PDF/A format, please notice this matter.

We can do following processes,

1. if input PDF file is a PDF/A format, the output PDF file will be PDF/A format too,
2. if input PDF file is not a PDF/A format, the output PDF file will not a PDF/A format too, if you wish convert a normal PDF file to PDF/A, please download our PDF to PDF/A Converter from following page,

http://www.verydoc.com/pdf-to-pdfa.html

3. if input PDF file contains fillable forms, we can’t subset fonts in this PDF file, but we can use zlib arithmetic to compress the uncompressed objects in this PDF file. If you wish force to compress this PDF file, the fillable forms will be "flatten" in output PDF file.


Yes, with a developer license you can integrate our product with your application and distribute it with your own application royalty free.

VeryPDF
===========================
To clarify our requirements, I would like to describe the situation
especially on fillable form fields and PDF/A in more detail:

We are creating fillable PDF forms with editable text fields and signature
fields. These PDF forms are PDF/A-1b compliant as far as possible. They
contain the necessary meta information and the embedded fonts.

These PDF forms are then handed over to a PDF signature software, which is
not under our control. This PDF signature software then allows the user to
edit the text fields, to sign the PDF form and to finalize the PDF form, so
that it is again PDF/A-1b compliant and no longer editable. This process of
editing and finalizing the PDF file is not under our control, it is handled
by independent signature software.

Our purpose is to create editable PDF forms, which are PDF/A-compliant (as
far as possible). So far we used Acrobat Pro to check for PDF/A-compliance
via Preflight functionality in Acrobat Pro and it indicated that our PDF
forms are PDF/A compliant though they include editable text fields and
signature fields.

In order to reduce the file size of the fillable PDF forms we are going to
take 2 actions:

1. Additional compression via Advanced PDF Tools Command Line v3.0

--> A check of the demo version indicated that
the reduction of the file size is only minimal, e.g. about 50 KB for PDF
files of an original size of 2.5 MB to 3.7 MB. Nevertheless we are going to
purchase Advanced PDF Tools Command Line v3.0 to achieve as much file size
reduction as possible. Also the expected reduction should be larger due to
the constraints of the demo version.

2. Usage of font sub sets on embedded fonts

a) Non-PDF/A compliant PDF documents (no fillable form): You indicated that this is no problem for you to implement

b) PDF/A compliant PDF documents (no fillable form): You indicated that this is no problem for you to implement

c) Fillable forms ( independent from PDF/A compliance): We can distinguish between

c1) Fonts, which are used in editable text fields
c2) Fonts, which are used in PDF document, but not in editable text fields

From our point of view c2) should be treated as described in 2a) or 2b).
Please let us know if this is true for the custom build version, which you
planned to create for us.

Case c1) is critical to us. The PDF forms created by us should still be
editable. And they should use the desired font for the editable text fields
during input. Please let us know, if it is possible for you to prevent
those fonts from the subset-usage and keep them as complete font
description in the PDF file. Only fonts which are not used in editable text
fields should be reduced to sub sets.

Please let us know if this solution could be implemented by you.

Additionally we do not clearly understand what you mean with " In general,
we will "flatten" fillable form fields automatically during compression."
Could you please explain this in more detail?

Thank you very much for your support and best regards
===========================
If your PDF file contains fillable forms, "subset font" function will
become very complexity. If possible, can you please email to us some sample
PDF files which contain fillable forms and comply with PDF/A format? After
we checked your sample PDF files, we will come back to you asap.

>>c) Fillable forms( independent from PDF/A compliance): We can
>>distinguish between c1) Fonts, which are used in editable text fields
>>c2) Fonts, which are used in PDF document, but not in editable text fields
>>From our point of view c2) should be treated as described in 2a) or 2b).
>>Please let us know if this is true for the custom build version, which you
>>planned to create for us.

Yes, you are right, we have to process the fonts for characters in editable
text fields and appearance of text fields separately, this function is
difficulty, we have to check some of your sample PDF files before we give
you an answer.


>>Additionally we do not clearly understand what you mean with " In general,
>>we will "flatten" fillable form fields automatically during compression."
>>Could you please explain this in more detail?

"flatten" function will convert fillable forms to non-fillable forms, it
will remove fillable forms automatically.

VeryPDF
===========================
Here are two sample PDF files - both with editable fields. Pages.pdf is a
quite simple file while Maximal.pdf is large. I am not sure about the PDF/A
compliance of Pages.pdf, but Maximal.pdf is PDF/A compliant.

(See attached file: PDFSubFonts.zip)

Thank you very much for your great support!

===========================
We can subset the fonts in your PDF files and keep the active forms now,
please download the new PDF files from following URL,

XXXXXXXXXXXXXXXXXXX

if you have any question for these PDF files, please feel free to let us
know, we will assist you asap.

VeryPDF
===========================
Thank you very much for your examples!

We have checked them and have some additional questions:

- Pages-new.pdf:
1. The defined default text for the text field is only visible after
clicking into the text field (with Adobe Reader 9.3). Adobe Reader X
immediately displays the default value, but we would also have to support
Adobe Reader 9.
2. A different font is used when you edit the text in the text field (with Adobe Reader 9.3)

- Maximal-new.pdf:
3. Special characters (e.g. "?" and "?" on page 7) are not displayed correctly
4. Sometimes the display of the text is slightly different from the original display (e.g. on the last page)

General questions / remarks:
--> We have seen that all embedded fonts now use subsets. Might this be the
reason for question # 2. We would have thought that the fonts used in text
fields should be embedded as complete font set and not only as sub set

--> The original PDF documents which have been merged together into
"Maximal.pdf" used different types of "Times New Roman" . Might this be the
reason for question # 4?

Thank you very much for your ongoing support and best regards,

===========================
We have fixed these problems to you, please download new PDF files from
following URL,

http://dl.dropbox.com/u/5570462/csc.zip

>>- Pages-new.pdf:
>>1. The defined default text for the text field is only visible after
>>clicking into the text field (with Adobe Reader 9.3). Adobe Reader X
>>immediately displays the default value, but we would also have to support
>>Adobe Reader 9.
>>2. A different font is used when you edit the text in the text field (with
>>Adobe Reader 9.3)

I have "Adobe Acrobat 9 Pro Extended" installed in my system, I haven't
Adobe Reader 9.3, you may view these PDF files in Adobe Reader 9.3 again,
please feel free to let me know if you still have same problem.

--> We also saw differences in the behaviour of displaying the default
values in our internal tests on different machines with the same version of
Adobe Reader. We are going to investigate this in more detail before we
come back to you.

--> Entering characters into text fields, which are not part of the default
value are now displayed as rectangles. We have also seen that the final PDF
document does only include font subsets. We still think that it should
contain the complete font for fonts, which are used for text fields. The
complete font should be necessary to allow the user to enter any possible
character into the text field.

>>- Maximal-new.pdf:
>>3. Special characters (e.g. "?" and "?" on page 7) are not displayed
>>correctly

Fixed.

--> Special character "?" is now displayed as "§". (We have not checked
every potential special character which might be used in different European
languages.)


>>4. Sometimes the display of the text is slightly different from the
>>original display (e.g. on the last page)
>>--> The original PDF documents which have been merged together into
>>"Maximal.pdf" used different types of "Times New Roman" . Might this be the
>>reason for question # 4?

Please check last page in these PDF files again, please feel free to let me
know if you still have same problem.

--> We have to check this in more detail before we come back to you!

Please note that our remarks to # 2 and # 3 are essential, because we have
to be sure that the European special characters are displayed correctly and
that it is possible to enter any potential character of a font into text
fields!

VeryPDF
===========================
We have added our comments below. Unfortunately we still see some issues
with this version.

Thank you very much for your ongoing support!!

===========================
We have solved the font problem to you completely, please download the new
PDF files with subset fonts from following URL to try again,

XXXXXXXXXXXXXXXXXXXXX

if you have any question for the new PDF files, please feel free to let us know.

VeryPDF
===========================
Thank you very much for the new delivery!

Our first check indicates that the issue with the special characters is fixed!

But it seems that the text fields are flattened now. It is not possible to
enter any text into the text fields. We were not able to discover an
"Acroform" entry in the PDFs. Therefore we assume that the text fields are
flattened.

As mentioned previously it is essential for us to generate fillable forms.
We could not use a solution which does not allow fillable text and
signature fields.

Please let us know if it is possible for you to keep the text and signature fields.

This would also require to keep all fonts which are used in text fields as
complete font file in the PDF document. Due to the fact that the fillable
text fields must allow entering any potential character of a font, the
fonts for fillable text fields must not be reduced to font subsets!

Thank you very much for your ongoing support!!

===========================
>>But it seems that the text fields are flattened now. It is not possible to
>>enter any text into the text fields. We were not able to discover an
>>"Acroform" entry in the PDFs. Therefore we assume that the text fields are
>>flattened.

This is a minor problem, we will copy "Acroform" entry from old PDF file and insert them into new PDF file, then you will able to fill the text fields in the new PDF file, we will spend a few days to develop this work.


>>Please let us know if it is possible for you to keep the text and signature fields.

Yes, of course, this is possible.


>>This would also require to keep all fonts which are used in text fields as
>>complete font file in the PDF document. Due to the fact that the fillable
>>text fields must allow entering any potential character of a font, the
>>fonts for fillable text fields must not be reduced to font subsets!

OK, we will try to work on "copy fields" function continue, we will let you know after this function is ready, thanks for your patience.

VeryPDF
===========================
Could you please provide a timeline for your work on the open issues to us? We need this information tomorrow for a decision with our Management and a high priority customer on the next steps.

===========================
We have finished the "copy forms" function, please download the new PDF files from following URL to try again,

XXXXXXXXXXXXXXXXXXX

We have finished following functions in maximal-3.pdf pages-3.pdf and files,

1. Subset fonts in PDF files,
2. Copy the text fields and signature fields from original PDF files to new PDF files,
3. Set new PDF files to PDF/A format,

If you have any question for the new PDF files, please feel free to let us know.

VeryPDF
===========================
Thank you very much for the new delivery!

It's great that the text and signature fields are visible again!

We have discovered the following issues:

- You have used font Helvetica for the text fields (e.g. in 18 0 obj /DA in pages-3.pdf). Originally Helvetica was not used as font in text fields. Times New Roman was originally used. We would have thought that Times New Roman would be kept as complete remaining font in this case. Please note that Times New Roman is not a fixed font that is used in our PDF forms for text fields. Any font could be used as font for text fields in our PDF forms. Whatever font has been used should remain as complete font in an editable PDF form from our point of view.

- Helvetica is not embedded. Therefore the PDF documents are currently not PDF/A compatible. On the other hand, if Times New Roman (or any other font that was originally used within text fields) would be used again for the text fields, embedding of Helvetica would become obsolete.

- The display of predefined text in text fields is a little bit strange. It seems that the text is displayed twice. One version of the text could be modified. The other version remains visible in the background. Might this be a side-effect of using Helvetica, too?

- The flag values of signature fields (/Ff) get changed, e.g. from 0 to 4194304.

- Mandatory signature fields used to have a red frame. They are displayed now with a black frame - like not-mandatory text fields. Might this be a side effect of the changed flag values?

Please let us know if our description is clear to you or if you need any additional information.

Could you please provide a timeline, if you could not answer of fix these issues by tomorrow? That would be great and helpful for us, too.

Thank you very much for your support and best regards,

===========================
We have created a new version to you, please download it from following URL,

We have fixed all problems in this version.

VeryPDF
===========================
Thank you very much for the new version! Here are our questions after the first tests:

1. The result documents are not compatible - though the execution comments of PDFFontSubSet.exe (displayed in the command prompt) indicate that the PDF/A function is used. The following list is from a check for "maximal.pdf" after using PDFFontSubSet:

- Missing glyphs in embedded font (2234 occurances on 63 pages)
- More than one encoding in CMap in a True Type symbol font (2234 occurances on 63 pages)
- Font not embedded (and font display mode not 3) (3 occurances on 1 page) - TimesNewRomanPSMT 11.0 pt not embedded
- Invalid encoding for True Type Font (3 occurances on  page)

2. Could you please check if the following call sequence of veryPDF functions is ok or if we should better use a different call sequence:

1. Merge documents
2. Repair form (option of PDFFontDelDup (remove duplicate fonts))
3. Remove duplicate fonts (PDFFontDelDup)
4. Font Sub Sets (PDFFontSubSet)
5. Additional compression
6. Set Encoding  / Permissions (only for PDF files which do not have to be PDF/A-compliant
7. PDF2PDFA (if PDF/A compliance is required

3. On some pages the displayed text slightly differs from previous versions. Might this be related to the message "Missing glyphs" in embedded font?

4. A first check of the flag values of text fields indicates that they are better now. But we did not yet check all the flag values. And we discovered a deviation when entering text into text fields. Originally the text size in text fields was variable in the following sense: When starting to enter text the font size was according to the size of the text field. When the entered text exceeds the length of the text field, the used display font in a text field gets automatically smaller. Now a fixed font size is used (font size does not get automatically smaller when the entered text length exceeds the size of the text field. We have not yet checked all the flag values of text fields.

--> It seems that the appearance object for text fields is not correct in all cases (appearance object of some text objects seems to be correct, but seems to be missing for other text fields). We are going to check this in more detail as soon as possible.

5. Documents, which do not have to be PDF/A-compliant still embed font "Helvetica" though it is not used in the document
"
6. Font Subsets in documents which do not have to PDF/A-compliant are of "Type 1 / Ansi" - without usage of PDFFontDelDup these fonts have type "True Type" another coding

Please note that questions # 5 and 6 have a much lower priority than questions # 1-4. Please let us know, if our questions are clear to you or if we should provide any additional information.

Once again thank you very much for your in-time delivery and ongoing support!

===========================
We have created a new version to you, please download it from following URL,

1) Fixed.

We are using “Preflight” function in Adobe Acrobat 9 Pro Extended, everything is work fine now,

2) Yes, your call sequence is right.

3) We have fixed the “embed font” problem in the new version, please use the new version to try again, can you get everything in the new version?

4) Thanks for your message, if you encounter any problem on the text fields, please email to us the sample PDF files in question, after we reproduced your problem in our system, we will figure out a solution to you asap.

5) Fixed, we have removed "Helvetica" font from output PDF files.

6) Thanks for your message, we don’t understand your meaning for this problem completely, if possible, can you please email to us the sample PDF files in question? Once we reproduce your problem in our system, we will figure out a solution to you asap.

VeryPDF
===========================
Unfortunately we cannot see any differences with regards to the issues described below when we use the new version. Could you please check if you provided the correct version?

I am going to provide more information tomorrow.

===========================
We have already solved the issue #1 and other issues in the new version, please test the new version carefully, if you still have same issues, please feel free to let us know, we will assist you asap.

VeryPDF
===========================
Here is some additional information on our test results. The descriptions are more detailed now and we also added new examples and some new issues that we discovered recently.

We are going to perform additional tests and I am going to send more information tomorrow - especially on topics # 1 - 4 from our previous mail. We are still investigating these topics and I have no additional information on them today.

5. Documents, which do not have to be PDF/A-compliant still embed font "Helvetica" though it is not used in the document. The following example shows
- Helvetica.pdf as input file and Helvetica-out.pdf as output file

Helvetica.pdf uses font "ArialMT" with "Actual Font Type: True Type". The result document shows font "Helvetica" with "Type 1".

5a. Sometimes the font is substituted by another font. Please refer to FontTest.pdf and FontTest2.pdf in the following zip file:

"TimesNewRomanPSMT True Type" is replaced with "Times-Roman Type 1".

6. Type of Font Subsets: Please have a look at the examples of "helvetica.zip" and "beispiele.zip". As mentioned in issue # 5 both fonts originally have Type "True Type" and have Type "Type 1" in the output documents.

7. The result files are not the same on different test machines. We have created "Helvetica2.pdf" and "FontTest2.pdf" on a Windows XP machine with Adobe Reader X. We have created "Helvetica-out.pdf" and "FontTest-out.pdf" on a Windows 7 machine with Adobe Reader 9.

Could the differences also be related to other variances - e.g. INI files etc.?

We have not yet checked "Helvetica-out.pdf" and "FontTest-out.pdf" for PDF/A-compliance, but it seems that there is PDF/A-compliant information in the result file, while this is missing in the "Helvetica2.pdf" and "FontTest2.pdf" output files. All files without PDF/A-information have been created on Windows XP machines. The output files with PDF/A-information have been created on a Windows 7 machine.

Please let us know if we should check for additional differences in our test computers.

8. PDFFontSubset stops with example file "includefield.pdf" in section "Copy forms to new PDF file...". No output file is written.


All result files have been created by only using PDFFontDelDup.exe to exclude side-effects with our software.
===========================

We have fixed these problems to you, please use new version to try again.

VeryPDF
===========================
VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.20_1166]
Rating: 0 (from 0 votes)

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *


Verify Code   If you cannot see the CheckCode image,please refresh the page again!