info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Font embedding in Existing PDF's
17 views
Skip to first unread message
Rohan Suku
Feb 2, 2021, 5:55:14 AM2/2/21
to
I need to embed fonts in generated PDF fom word Document programtically in C# .net.
Currently I am using Ghostscript 9.53 for embedding fonts. The resultant PDF's are approx 3-4 times bigger comapred to the ones genrarted with Ghostscript 9.07. These PDF's are sent to the Printer and to Archive.
Since bigger PDF's are eating the archive Disk space very quickly, what possibilites exists to make the PDF's smaller with embedded fonts using GS 9.53.3.
I've tried using the resource folder from 9.07 in 9.53.3 and also using the ResourceDir switch. The Resultant PDF was still the same size.
My requirement is that fonts needs to be embedded and keep the PDF's to the smallest size as Possible.
Currently I am using Ghostscript 9.53 for embedding fonts. The resultant PDF's are approx 3-4 times bigger comapred to the ones genrarted with Ghostscript 9.07. These PDF's are sent to the Printer and to Archive.
Since bigger PDF's are eating the archive Disk space very quickly, what possibilites exists to make the PDF's smaller with embedded fonts using GS 9.53.3.
I've tried using the resource folder from 9.07 in 9.53.3 and also using the ResourceDir switch. The Resultant PDF was still the same size.
My requirement is that fonts needs to be embedded and keep the PDF's to the smallest size as Possible.
Jeffrey H. Coffield
Feb 2, 2021, 5:34:07 PM2/2/21
to
to go too far outside your padded cell, Apache POI could be a solution.
Not C# but platform independent.
If interested see the following.
https://stackoverflow.com/questions/6201736/javausing-apache-poi-how-to-convert-ms-word-file-to-pdf
Jeff Coffield
www.digitalsynergyinc.com
ken
Feb 3, 2021, 2:56:00 AM2/3/21
to
In article <f598435b-83be-4769...@googlegroups.com>,
daffod...@gmail.com says...
As I said on IRC (though you did not respond so I have no idea if you
saw it), it is very unlikely that you can reliably produce a new PDF
file with the fonts embedded, which correctly draws the text, without
the file being substantially larger.
It is conceivable that, for PDF files produced systematically in the
same way, a simpler treatment is possible and that is why (for the PDF
files you are processing) an older and less reliable method produces
acceptable results.
However, should the production of the original PDF files change you may
well discover the reason that the files are now larger is because you
were taking advantage of some 'quirk' of the original PDF files which no
longer applies with the new ones.
As I said, I cannot possibly venture to guess at a reason wiithout
seeing the original files. Nor I suspect can anyone else, given that I
maintain the software which creates the PDF files. If you would like
someone to look at your problem you should open a bug report, attach an
example file and state the command line you are using.
You can sign up to the Ghostscript bug tracker at bugs.ghostscript.com
Ken
daffod...@gmail.com says...
saw it), it is very unlikely that you can reliably produce a new PDF
file with the fonts embedded, which correctly draws the text, without
the file being substantially larger.
It is conceivable that, for PDF files produced systematically in the
same way, a simpler treatment is possible and that is why (for the PDF
files you are processing) an older and less reliable method produces
acceptable results.
However, should the production of the original PDF files change you may
well discover the reason that the files are now larger is because you
were taking advantage of some 'quirk' of the original PDF files which no
longer applies with the new ones.
As I said, I cannot possibly venture to guess at a reason wiithout
seeing the original files. Nor I suspect can anyone else, given that I
maintain the software which creates the PDF files. If you would like
someone to look at your problem you should open a bug report, attach an
example file and state the command line you are using.
You can sign up to the Ghostscript bug tracker at bugs.ghostscript.com
Ken
Rohan Suku
Feb 3, 2021, 9:34:19 AM2/3/21
to
The command hasn't changed. The only diferrence I can notice is in the version of ghostscript. The smaller ones were generated via 9.07 and bigger ones with 9.53.
The text and image contents of the files remain the same. The only operation perfomed is to embed the fonts completely. Thats's were the size difference occurs. The PDF's were generated systematically. I can generate a sample file and provide it to you. I cannot share the currently generated files because it contains certain sensitive information.
For me it seems the only difference is in bigger fonts thats embedded into the PDF Files (9.07 had smaller font files comapred to 9.53.3).
My concern here ist how can I instruct ghostscript not to use the bigger Fonts or use the Resources from version 9.07?
ken
Feb 3, 2021, 11:11:42 AM2/3/21
to
In article <d9180159-1e0d-4e15...@googlegroups.com>,
daffod...@gmail.com says...
> The text and image contents of the files remain the same. The only
operation perfomed is to embed the fonts completely.
I'm afraid that's what you *want* to happen, but it isn't what the
pdfwrite device does. It creates a totally new PDF file, it does not
simply embed fonts into the existing PDF file. At the PDF-syntax level
the input and output files will be quite different.
As such there is a great deal going on behind the scenes and fonts are a
a particular problem. It is likely that the reason for the change is
that the simpler method used by the old version of Ghostscript was
insufficient and led to incorrect PDF files being created from some
kinds of input files.
Obviously we would fix that, we prefer that the result be correct to
being small.
> My concern here ist how can I instruct ghostscript not to use the
bigger Fonts or use the Resources from version 9.07?
As I said, I doubt that you can. The likelihood is that the fonts are
being embedded differently to avoid a problem. You are (currently)
fortunate that your usage does not expose the underlying problem in the
output from the old version of Ghostscript.
However it is quite possible that at some point in the future you will
encounter an input file which does not process correctly using the old
scheme, in which case your output file would be incorrect.
That is, of course, a guess. As I have said, I cannot even begin to
guess what changes over the last 7 years would have had this effect,
there have been literally thousands of commits.
You could, of course, carry on using the old version of Ghostscript.
But if you open a bug report, attach an example file and give me a
command line I will look at the problem. Note that if the example
requires the use of non-standard fonts you will have to supply those as
well, and the fontmap.GS file which maps them so that Ghostscript can
use them.
Basically I need to be able to reproduce your problem on my system
before I can investigate it.
Ken
daffod...@gmail.com says...
> The text and image contents of the files remain the same. The only
operation perfomed is to embed the fonts completely.
pdfwrite device does. It creates a totally new PDF file, it does not
simply embed fonts into the existing PDF file. At the PDF-syntax level
the input and output files will be quite different.
As such there is a great deal going on behind the scenes and fonts are a
a particular problem. It is likely that the reason for the change is
that the simpler method used by the old version of Ghostscript was
insufficient and led to incorrect PDF files being created from some
kinds of input files.
Obviously we would fix that, we prefer that the result be correct to
being small.
> My concern here ist how can I instruct ghostscript not to use the
bigger Fonts or use the Resources from version 9.07?
being embedded differently to avoid a problem. You are (currently)
fortunate that your usage does not expose the underlying problem in the
output from the old version of Ghostscript.
However it is quite possible that at some point in the future you will
encounter an input file which does not process correctly using the old
scheme, in which case your output file would be incorrect.
That is, of course, a guess. As I have said, I cannot even begin to
guess what changes over the last 7 years would have had this effect,
there have been literally thousands of commits.
You could, of course, carry on using the old version of Ghostscript.
But if you open a bug report, attach an example file and give me a
command line I will look at the problem. Note that if the example
requires the use of non-standard fonts you will have to supply those as
well, and the fontmap.GS file which maps them so that Ghostscript can
use them.
Basically I need to be able to reproduce your problem on my system
before I can investigate it.
Ken
Rohan Suku
Feb 5, 2021, 6:44:25 AM2/5/21
to
The bug id is 703481
ken
Feb 5, 2021, 6:47:54 AM2/5/21
to
In article <c32f9ea5-e402-4ff5...@googlegroups.com>,
daffod...@gmail.com says...
> > Basically I need to be able to reproduce your problem on my system
> > before I can investigate it.
> >
> >
> > Ken
> I have opened a bug ticket as you mentioned. The sample files are attached.
> The bug id is 703481
And I've replied in that thread. For anyone curious the bug can be found
here:
https://bugs.ghostscript.com/show_bug.cgi?id=703481
daffod...@gmail.com says...
> > Basically I need to be able to reproduce your problem on my system
> > before I can investigate it.
> >
> >
> > Ken
> I have opened a bug ticket as you mentioned. The sample files are attached.
> The bug id is 703481
here:
https://bugs.ghostscript.com/show_bug.cgi?id=703481
0 new messages