You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by egibler <eg...@zytron.net> on 2008/12/01 16:49:34 UTC
0.95 & Acrobat Performance Problems
Hi,
I receive lots and lots of small (1-3 page) PDFs each day, combine them
using Acrobat Professional, and print and mail them for clients. One client
recently upgraded from FOP .2x to FOP 0.95, and the combining of his files
has become nearly impossible. It'll put the first 10 pages together fairly
quickly, but gets incrementally slower with subsequent additions until the
process grinds to a halt before page 150 or so. He tends to send me batches
of between 1500 and 3500 pages, so I'm well shy of what I need to
accomplish. The process worked great with the earlier version, and works
fine with my other clients' PDFs that are created with various other tools.
These files are invoices. Batches of which regularly represent several
millions of dollars, so they really have to be right, timely, and without
duplicates or omissions.
I'm not at all familiar with FOP - please forgive my ignorance. I hadn't
heard of it until the problem occurred and I started doing a bit of
research. From what I've read, there seems to be a fair amount of
discussion related to memory issues and large PDFs. I'm wondering if anyone
else has a situation similar to mine, and / or might be able to suggest what
I might be able to do to get my production back on track.
I'm working in Windows XP SP3, 2Gb RAM and a 3GHz processor.
Any advice would be sincerely appreciated.
Thanks,
Ed
--
View this message in context: http://www.nabble.com/0.95---Acrobat-Performance-Problems-tp20774481p20774481.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.95 & Acrobat Performance Problems
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I've just added support for forcing a single-byte encoding when using
the "font" element without an XML font metric file in FOP Trunk:
http://svn.apache.org/viewvc?rev=731248&view=rev
So using current FOP Trunk you could do:
<font embed-url="file:///opt/sigma_tomcat/webapps/sigma/WEB-INF/fonts/ocra.ttf"
encoding-mode="single-byte>
<font-triplet name="ocra" style="normal" weight="normal"/>
</font>
This way and for larger fonts than OCRA (i.e. fonts with characters
outside the WinAnsi encoding), you'll have access to all glyphs in the
font which you don't have when working with an XML font metric file.
On 19.12.2008 21:40:00 Jeremias Maerki wrote:
> Just as I thought. You're doing this:
> <font kerning="yes" embed-url="file:///opt/sigma_tomcat/webapps/sigma/WEB-INF/fonts/ocra.ttf">
> <font-triplet name="ocra" style="normal" weight="normal"/>
> </font>
>
> This bypasses the XML font metric files. Currently, it's not possible to
> tell FOP this way to use WinAnsi encoding. You have to create an XML
> font metrics file for each font as described in [1] (using "-enc ansi",
> just as in FOP 0.20.5 although you'll have to recreate the files).
> Then you'll have to do this:
>
> <font metrics-url="file:///opt/sigma_tomcat/webapps/sigma/WEB-INF/fonts/ocra.ttf.xml">
> kerning="yes"
> embed-url="file:///opt/sigma_tomcat/webapps/sigma/WEB-INF/fonts/ocra.ttf">
> <font-triplet name="ocra" style="normal" weight="normal"/>
> </font>
>
> HTH
>
> [2] http://xmlgraphics.apache.org/fop/trunk/fonts.html#truetype-metrics
>
> On 19.12.2008 20:20:01 egibler wrote:
> >
> > The font configuration should be attached (I used the 'Upload File...'
> > button, but don't know where the file goes).
> >
> > Thanks!!!
> > Ed
> >
> >
> >
> > That's just a font metrics file. It could still be that your
> > configuration file is set up so you get a CID font. Can we see the font
> > configuration, too?
> >
> > http://www.nabble.com/file/p21096930/configuration.xml configuration.xml
> > --
> > View this message in context: http://www.nabble.com/0.95---Acrobat-Performance-Problems-tp20774481p21096930.html
> > Sent from the FOP - Users mailing list archive at Nabble.com.
> >
>
>
>
> Jeremias Maerki
>
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.95 & Acrobat Performance Problems
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Just as I thought. You're doing this:
<font kerning="yes" embed-url="file:///opt/sigma_tomcat/webapps/sigma/WEB-INF/fonts/ocra.ttf">
<font-triplet name="ocra" style="normal" weight="normal"/>
</font>
This bypasses the XML font metric files. Currently, it's not possible to
tell FOP this way to use WinAnsi encoding. You have to create an XML
font metrics file for each font as described in [1] (using "-enc ansi",
just as in FOP 0.20.5 although you'll have to recreate the files).
Then you'll have to do this:
<font metrics-url="file:///opt/sigma_tomcat/webapps/sigma/WEB-INF/fonts/ocra.ttf.xml">
kerning="yes"
embed-url="file:///opt/sigma_tomcat/webapps/sigma/WEB-INF/fonts/ocra.ttf">
<font-triplet name="ocra" style="normal" weight="normal"/>
</font>
HTH
[2] http://xmlgraphics.apache.org/fop/trunk/fonts.html#truetype-metrics
On 19.12.2008 20:20:01 egibler wrote:
>
> The font configuration should be attached (I used the 'Upload File...'
> button, but don't know where the file goes).
>
> Thanks!!!
> Ed
>
>
>
> That's just a font metrics file. It could still be that your
> configuration file is set up so you get a CID font. Can we see the font
> configuration, too?
>
> http://www.nabble.com/file/p21096930/configuration.xml configuration.xml
> --
> View this message in context: http://www.nabble.com/0.95---Acrobat-Performance-Problems-tp20774481p21096930.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.95 & Acrobat Performance Problems
Posted by egibler <eg...@zytron.net>.
The font configuration should be attached (I used the 'Upload File...'
button, but don't know where the file goes).
Thanks!!!
Ed
That's just a font metrics file. It could still be that your
configuration file is set up so you get a CID font. Can we see the font
configuration, too?
http://www.nabble.com/file/p21096930/configuration.xml configuration.xml
--
View this message in context: http://www.nabble.com/0.95---Acrobat-Performance-Problems-tp20774481p21096930.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.95 & Acrobat Performance Problems
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
That's just a font metrics file. It could still be that your
configuration file is set up so you get a CID font. Can we see the font
configuration, too?
On 17.12.2008 17:04:58 egibler wrote:
>
> I got ahold of the configuration file for the font that is acting up. From
> what I can see, it is being defined as an ANSI font, but when the PDF is
> produced, it shows as CID. Again, in version .2 it worked great. Is there
> anything that can or should be added / edited to the following (or
> elsewhere) that would get the font rendered as ANSI?
>
> I'd sure appreciate any suggestions.
> Thanks!
> Ed
>
> ********************************************
> <?xml version="1.0" encoding="UTF-8"?>
> <font-metrics type="TRUETYPE">
> <font-name>OCRAExtended</font-name>
>
> <cap-height>648</cap-height>
> <x-height>0</x-height>
> <ascender>857</ascender>
> <descender>-176</descender>
> <bbox>
> <left>-4</left>
> <bottom>-176</bottom>
> <right>875</right>
> <top>857</top>
> </bbox>
> <flags>33</flags>
> <stemv>0</stemv>
> <italicangle>0</italicangle>
> <subtype>TRUETYPE</subtype>
> <singlebyte-extras>
> <encoding>WinAnsiEncoding</encoding>
> <first-char>0</first-char>
> <last-char>255</last-char>
> <widths>
> <char idx="0" wdt="1000"/>
> <char idx="1" wdt="1000"/>
>
> **** snipped out ‘2’ to '254’***
>
> <char idx="255" wdt="604"/>
> </widths>
> </singlebyte-extras>
> </font-metrics>
>
> **************************************************
>
> Jeremias Maerki-2 wrote:
> >
> > On 04.12.2008 23:25:57 Andreas Delmelle wrote:
> >> On 04 Dec 2008, at 23:05, egibler wrote:
> >>
> >> >
> >> > I think we uncovered the culprit!
> >> >
> >> > The files we received in the 0.2 version used an 'OCRAExtended'
> >> > font, which
> >> > was TrueType and Encoding: Ansi.
> >> >
> >> > The files we receive now with 0.95 have 'OCRAExtended', which is
> >> > TrueType
> >> > (CID) and Encoding: Entity-H.
> >> >
> >> > From what I've read, the CID font is basically for foreign languages
> >> > with
> >> > huge character sets. Is this correct?
> >>
> >> Basically, yes.
> >
> > But not just that. It doesn't really take an "exotic" language for that
> > CID fonts to become interesting.
> >
> >> > Is there a reason that the guys who
> >> > make the PDF need this CID font in version 0.95. The only
> >> > characters used
> >> > are numbers (0-9).
> >>
> >> I'm not sure. I'll leave the detailed explanation to those who are
> >> more familiar with that part of the code (if they decide to chime in),
> >> but my best guess would be that the on-the-fly metrics generation
> >> (introduced in later versions) somehow defaults to CID font-metrics (?)
> >
> > Yes, we do CID fonts for TrueType fonts by default because that's the
> > most versatile approach. I was not aware that this can slow down
> > Acrobat's PDF concatenation this much. If Adobe had chosen to simply
> > embed the font multiple times (as probably other tools would), the whole
> > thing would be much faster. But the PDF file would obviously be bigger
> > in the end.
> >
> > The thing with this choice is that we currently cannot switch from
> > single byte handling to multi byte handling when necessary. The
> > architecture of the font subsystem doesn't currently allow that. So we
> > have to make a decision beforehand which approach to take. And currently,
> > if you don't use an XML font metrics file, the choice is hard-coded to
> > CID fonts. Maybe that needs to be made configurable at least. I've
> > recorded an RFE in Bugzilla so this doesn't get forgotten:
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=46348
> >
> >> > I swapped the font out in my samples, and combining 200 one-page pdfs
> >> > dropped from 30+ minutes to a few seconds. This would make all the
> >> > difference to us, if it is doable from the developers' perspective.
> >> >
> >> > What do you think?
> >>
> >> Makes sense that this is such a drain. Using CID fonts means Acrobat
> >> has to merge the glyph tables from 200 documents (and possibly change
> >> references in the documents themselves too, accordingly).
> >>
> >> If my above assumption is correct, then the issue could be alleviated
> >> on the producing end. Even if no longer necessary, it is still
> >> possible to manually generate a font-metrics file for the given font
> >> in Ansi encoding, and reference that in the config file.
> >
> > Right, that's one work-around: an XML font metrics file generated with
> > -ansi. The other option, since you're talking about an OCR font: you
> > could switch to the Type 1 variant in which case you're automatically in
> > the single byte realm and the problem would not appear.
> >
> >> If they do not immediately know how, refer them to:
> >> http://xmlgraphics.apache.org/fop/0.95/fonts.html
> >>
> >>
> >> HTH!
> >>
> >> Cheers
> >>
> >> Andreas
> >>
> >
> >
> > Jeremias Maerki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/0.95---Acrobat-Performance-Problems-tp20774481p21055068.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.95 & Acrobat Performance Problems
Posted by egibler <eg...@zytron.net>.
I got ahold of the configuration file for the font that is acting up. From
what I can see, it is being defined as an ANSI font, but when the PDF is
produced, it shows as CID. Again, in version .2 it worked great. Is there
anything that can or should be added / edited to the following (or
elsewhere) that would get the font rendered as ANSI?
I'd sure appreciate any suggestions.
Thanks!
Ed
********************************************
<?xml version="1.0" encoding="UTF-8"?>
<font-metrics type="TRUETYPE">
<font-name>OCRAExtended</font-name>
<cap-height>648</cap-height>
<x-height>0</x-height>
<ascender>857</ascender>
<descender>-176</descender>
<bbox>
<left>-4</left>
<bottom>-176</bottom>
<right>875</right>
<top>857</top>
</bbox>
<flags>33</flags>
<stemv>0</stemv>
<italicangle>0</italicangle>
<subtype>TRUETYPE</subtype>
<singlebyte-extras>
<encoding>WinAnsiEncoding</encoding>
<first-char>0</first-char>
<last-char>255</last-char>
<widths>
<char idx="0" wdt="1000"/>
<char idx="1" wdt="1000"/>
**** snipped out ‘2’ to '254’***
<char idx="255" wdt="604"/>
</widths>
</singlebyte-extras>
</font-metrics>
**************************************************
Jeremias Maerki-2 wrote:
>
> On 04.12.2008 23:25:57 Andreas Delmelle wrote:
>> On 04 Dec 2008, at 23:05, egibler wrote:
>>
>> >
>> > I think we uncovered the culprit!
>> >
>> > The files we received in the 0.2 version used an 'OCRAExtended'
>> > font, which
>> > was TrueType and Encoding: Ansi.
>> >
>> > The files we receive now with 0.95 have 'OCRAExtended', which is
>> > TrueType
>> > (CID) and Encoding: Entity-H.
>> >
>> > From what I've read, the CID font is basically for foreign languages
>> > with
>> > huge character sets. Is this correct?
>>
>> Basically, yes.
>
> But not just that. It doesn't really take an "exotic" language for that
> CID fonts to become interesting.
>
>> > Is there a reason that the guys who
>> > make the PDF need this CID font in version 0.95. The only
>> > characters used
>> > are numbers (0-9).
>>
>> I'm not sure. I'll leave the detailed explanation to those who are
>> more familiar with that part of the code (if they decide to chime in),
>> but my best guess would be that the on-the-fly metrics generation
>> (introduced in later versions) somehow defaults to CID font-metrics (?)
>
> Yes, we do CID fonts for TrueType fonts by default because that's the
> most versatile approach. I was not aware that this can slow down
> Acrobat's PDF concatenation this much. If Adobe had chosen to simply
> embed the font multiple times (as probably other tools would), the whole
> thing would be much faster. But the PDF file would obviously be bigger
> in the end.
>
> The thing with this choice is that we currently cannot switch from
> single byte handling to multi byte handling when necessary. The
> architecture of the font subsystem doesn't currently allow that. So we
> have to make a decision beforehand which approach to take. And currently,
> if you don't use an XML font metrics file, the choice is hard-coded to
> CID fonts. Maybe that needs to be made configurable at least. I've
> recorded an RFE in Bugzilla so this doesn't get forgotten:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=46348
>
>> > I swapped the font out in my samples, and combining 200 one-page pdfs
>> > dropped from 30+ minutes to a few seconds. This would make all the
>> > difference to us, if it is doable from the developers' perspective.
>> >
>> > What do you think?
>>
>> Makes sense that this is such a drain. Using CID fonts means Acrobat
>> has to merge the glyph tables from 200 documents (and possibly change
>> references in the documents themselves too, accordingly).
>>
>> If my above assumption is correct, then the issue could be alleviated
>> on the producing end. Even if no longer necessary, it is still
>> possible to manually generate a font-metrics file for the given font
>> in Ansi encoding, and reference that in the config file.
>
> Right, that's one work-around: an XML font metrics file generated with
> -ansi. The other option, since you're talking about an OCR font: you
> could switch to the Type 1 variant in which case you're automatically in
> the single byte realm and the problem would not appear.
>
>> If they do not immediately know how, refer them to:
>> http://xmlgraphics.apache.org/fop/0.95/fonts.html
>>
>>
>> HTH!
>>
>> Cheers
>>
>> Andreas
>>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/0.95---Acrobat-Performance-Problems-tp20774481p21055068.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.95 & Acrobat Performance Problems
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 04.12.2008 23:25:57 Andreas Delmelle wrote:
> On 04 Dec 2008, at 23:05, egibler wrote:
>
> >
> > I think we uncovered the culprit!
> >
> > The files we received in the 0.2 version used an 'OCRAExtended'
> > font, which
> > was TrueType and Encoding: Ansi.
> >
> > The files we receive now with 0.95 have 'OCRAExtended', which is
> > TrueType
> > (CID) and Encoding: Entity-H.
> >
> > From what I've read, the CID font is basically for foreign languages
> > with
> > huge character sets. Is this correct?
>
> Basically, yes.
But not just that. It doesn't really take an "exotic" language for that
CID fonts to become interesting.
> > Is there a reason that the guys who
> > make the PDF need this CID font in version 0.95. The only
> > characters used
> > are numbers (0-9).
>
> I'm not sure. I'll leave the detailed explanation to those who are
> more familiar with that part of the code (if they decide to chime in),
> but my best guess would be that the on-the-fly metrics generation
> (introduced in later versions) somehow defaults to CID font-metrics (?)
Yes, we do CID fonts for TrueType fonts by default because that's the
most versatile approach. I was not aware that this can slow down
Acrobat's PDF concatenation this much. If Adobe had chosen to simply
embed the font multiple times (as probably other tools would), the whole
thing would be much faster. But the PDF file would obviously be bigger
in the end.
The thing with this choice is that we currently cannot switch from
single byte handling to multi byte handling when necessary. The
architecture of the font subsystem doesn't currently allow that. So we
have to make a decision beforehand which approach to take. And currently,
if you don't use an XML font metrics file, the choice is hard-coded to
CID fonts. Maybe that needs to be made configurable at least. I've
recorded an RFE in Bugzilla so this doesn't get forgotten:
https://issues.apache.org/bugzilla/show_bug.cgi?id=46348
> > I swapped the font out in my samples, and combining 200 one-page pdfs
> > dropped from 30+ minutes to a few seconds. This would make all the
> > difference to us, if it is doable from the developers' perspective.
> >
> > What do you think?
>
> Makes sense that this is such a drain. Using CID fonts means Acrobat
> has to merge the glyph tables from 200 documents (and possibly change
> references in the documents themselves too, accordingly).
>
> If my above assumption is correct, then the issue could be alleviated
> on the producing end. Even if no longer necessary, it is still
> possible to manually generate a font-metrics file for the given font
> in Ansi encoding, and reference that in the config file.
Right, that's one work-around: an XML font metrics file generated with
-ansi. The other option, since you're talking about an OCR font: you
could switch to the Type 1 variant in which case you're automatically in
the single byte realm and the problem would not appear.
> If they do not immediately know how, refer them to: http://xmlgraphics.apache.org/fop/0.95/fonts.html
>
>
> HTH!
>
> Cheers
>
> Andreas
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.95 & Acrobat Performance Problems
Posted by Andreas Delmelle <an...@telenet.be>.
On 04 Dec 2008, at 23:05, egibler wrote:
>
> I think we uncovered the culprit!
>
> The files we received in the 0.2 version used an 'OCRAExtended'
> font, which
> was TrueType and Encoding: Ansi.
>
> The files we receive now with 0.95 have 'OCRAExtended', which is
> TrueType
> (CID) and Encoding: Entity-H.
>
> From what I've read, the CID font is basically for foreign languages
> with
> huge character sets. Is this correct?
Basically, yes.
> Is there a reason that the guys who
> make the PDF need this CID font in version 0.95. The only
> characters used
> are numbers (0-9).
I'm not sure. I'll leave the detailed explanation to those who are
more familiar with that part of the code (if they decide to chime in),
but my best guess would be that the on-the-fly metrics generation
(introduced in later versions) somehow defaults to CID font-metrics (?)
> I swapped the font out in my samples, and combining 200 one-page pdfs
> dropped from 30+ minutes to a few seconds. This would make all the
> difference to us, if it is doable from the developers' perspective.
>
> What do you think?
Makes sense that this is such a drain. Using CID fonts means Acrobat
has to merge the glyph tables from 200 documents (and possibly change
references in the documents themselves too, accordingly).
If my above assumption is correct, then the issue could be alleviated
on the producing end. Even if no longer necessary, it is still
possible to manually generate a font-metrics file for the given font
in Ansi encoding, and reference that in the config file.
If they do not immediately know how, refer them to: http://xmlgraphics.apache.org/fop/0.95/fonts.html
HTH!
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.95 & Acrobat Performance Problems
Posted by egibler <eg...@zytron.net>.
I think we uncovered the culprit!
The files we received in the 0.2 version used an 'OCRAExtended' font, which
was TrueType and Encoding: Ansi.
The files we receive now with 0.95 have 'OCRAExtended', which is TrueType
(CID) and Encoding: Entity-H.
>From what I've read, the CID font is basically for foreign languages with
huge character sets. Is this correct? Is there a reason that the guys who
make the PDF need this CID font in version 0.95. The only characters used
are numbers (0-9).
I swapped the font out in my samples, and combining 200 one-page pdfs
dropped from 30+ minutes to a few seconds. This would make all the
difference to us, if it is doable from the developers' perspective.
What do you think?
Thanks!
Ed
On 01 Dec 2008, at 20:39, egibler wrote:
Hi
> <snip />
> To me, the smoking gun is the upgrade, but I could be pursuaded
> otherwise.
> It wouldn't be my first incorrect assumption. I'm hoping to find
> the cause,
So, the most important question is probably: is there something
special about those PDFs? Are there many images, custom fonts,
tables ...? Anything that might give us a clue?
--
View this message in context: http://www.nabble.com/0.95---Acrobat-Performance-Problems-tp20774481p20843484.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.95 & Acrobat Performance Problems
Posted by Andreas Delmelle <an...@telenet.be>.
On 01 Dec 2008, at 20:39, egibler wrote:
Hi
> <snip />
> To me, the smoking gun is the upgrade, but I could be pursuaded
> otherwise.
> It wouldn't be my first incorrect assumption. I'm hoping to find
> the cause,
That would be helpful indeed. A lot has changed in the way the PDF is
constructed between the two versions, so it's definitely possible that
some of those changes are responsible. OTOH, without /any/ indication
whatsoever of what precisely is going on, it will be difficult to
address.
So, the most important question is probably: is there something
special about those PDFs? Are there many images, custom fonts,
tables ...? Anything that might give us a clue?
Apart from the mere theoretical possibility, you're the first to
report such an issue (but this could be because there's only very few
people that have the exact same setup, and use Acrobat to merge PDF
generated by FOP? iText is among the most popular libraries to be used
for this purpose.)
>
> or at least some sort of work around, or I'm afraid I'm going to
> have to
> turn away this client's business.
That would be unfortunate, and is something we would help to avoid, if
only we knew where to start looking... :/
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: 0.95 & Acrobat Performance Problems
Posted by "Griffin,Sean" <SG...@CERNER.COM>.
I would look for differences in the source PDFs between the two versions. Even opening a PDF in a text editor will possibly show enough differences to explain the problem. FOP 0.95 creates PDF v1.4 files. I don't remember what FOP 0.20.5 created. Maybe there's a difference in how the contents of the PDF are compressed/uncompressed that influences the ability to concatenate. There are filters that FOP applies to certain items in the PDF, like the FLATE filter on images, so maybe those are affecting the behavior. Are files of similar content and page count approximately the same size between a source that works and a source that does not? If you have to, you could write a program to use iText to do the PDF concatenation instead of Acrobat just to see if the problem is reproducible from other software.
-----Original Message-----
From: egibler [mailto:egibler@zytron.net]
Sent: Monday, December 01, 2008 1:40 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: 0.95 & Acrobat Performance Problems
Thanks for the response.
My problem is absolutely in Acrobat, specifically in how Acrobat deals with
the PDFs generated using FOP 0.95 (I'm pretty sure). I'm hoping there might
be some setting, or known issue, in dealing with the two products in the
fashion I'm doing it.
I combine somewhere between 20,000 and 30,000 PDF pages daily, and have done
so for about three years. The process is quick and reliable.
Last week, one of our clients migrated from FOP .2 to FOP .95, and abolutely
every subsequent file sent by them has brought me to my knees. The
remaining 90% of my work (coming from other clients and using other PDF
generation tools) is flowing great, and I can rerun old FOP .2 files which
also still work great.
To me, the smoking gun is the upgrade, but I could be pursuaded otherwise.
It wouldn't be my first incorrect assumption. I'm hoping to find the cause,
or at least some sort of work around, or I'm afraid I'm going to have to
turn away this client's business.
Does that make sense? I readily acknowledge my lack of experience with the
FOP toolset. Any light shed on the issue would be most helpful.
Thanks,
ed
paul womack wrote:
>
> egibler wrote:
>> Hi,
>>
>> I receive lots and lots of small (1-3 page) PDFs each day, combine them
>> using Acrobat Professional, and print and mail them for clients. One
>> client
>> recently upgraded from FOP .2x to FOP 0.95, and the combining of his
>> files
>> has become nearly impossible. It'll put the first 10 pages together
>> fairly
>> quickly, but gets incrementally slower with subsequent additions until
>> the
>> process grinds to a halt before page 150 or so. He tends to send me
>> batches
>> of between 1500 and 3500 pages, so I'm well shy of what I need to
>> accomplish. The process worked great with the earlier version, and works
>> fine with my other clients' PDFs that are created with various other
>> tools.
>>
>> These files are invoices. Batches of which regularly represent several
>> millions of dollars, so they really have to be right, timely, and without
>> duplicates or omissions.
>>
>> I'm not at all familiar with FOP - please forgive my ignorance. I hadn't
>> heard of it until the problem occurred and I started doing a bit of
>> research. From what I've read, there seems to be a fair amount of
>> discussion related to memory issues and large PDFs. I'm wondering if
>> anyone
>> else has a situation similar to mine, and / or might be able to suggest
>> what
>> I might be able to do to get my production back on track.
>
>
> I'm a little confused. While FOP does indeed have some known
> performance issues with multi page documents,
> isn't the performance issue YOU'RE talking about
> inside Acrobat?
>
> BugBear
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/0.95---Acrobat-Performance-Problems-tp20774481p20777151.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
----------------------------------------------------------------------
CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.95 & Acrobat Performance Problems
Posted by egibler <eg...@zytron.net>.
Thanks for the response.
My problem is absolutely in Acrobat, specifically in how Acrobat deals with
the PDFs generated using FOP 0.95 (I'm pretty sure). I'm hoping there might
be some setting, or known issue, in dealing with the two products in the
fashion I'm doing it.
I combine somewhere between 20,000 and 30,000 PDF pages daily, and have done
so for about three years. The process is quick and reliable.
Last week, one of our clients migrated from FOP .2 to FOP .95, and abolutely
every subsequent file sent by them has brought me to my knees. The
remaining 90% of my work (coming from other clients and using other PDF
generation tools) is flowing great, and I can rerun old FOP .2 files which
also still work great.
To me, the smoking gun is the upgrade, but I could be pursuaded otherwise.
It wouldn't be my first incorrect assumption. I'm hoping to find the cause,
or at least some sort of work around, or I'm afraid I'm going to have to
turn away this client's business.
Does that make sense? I readily acknowledge my lack of experience with the
FOP toolset. Any light shed on the issue would be most helpful.
Thanks,
ed
paul womack wrote:
>
> egibler wrote:
>> Hi,
>>
>> I receive lots and lots of small (1-3 page) PDFs each day, combine them
>> using Acrobat Professional, and print and mail them for clients. One
>> client
>> recently upgraded from FOP .2x to FOP 0.95, and the combining of his
>> files
>> has become nearly impossible. It'll put the first 10 pages together
>> fairly
>> quickly, but gets incrementally slower with subsequent additions until
>> the
>> process grinds to a halt before page 150 or so. He tends to send me
>> batches
>> of between 1500 and 3500 pages, so I'm well shy of what I need to
>> accomplish. The process worked great with the earlier version, and works
>> fine with my other clients' PDFs that are created with various other
>> tools.
>>
>> These files are invoices. Batches of which regularly represent several
>> millions of dollars, so they really have to be right, timely, and without
>> duplicates or omissions.
>>
>> I'm not at all familiar with FOP - please forgive my ignorance. I hadn't
>> heard of it until the problem occurred and I started doing a bit of
>> research. From what I've read, there seems to be a fair amount of
>> discussion related to memory issues and large PDFs. I'm wondering if
>> anyone
>> else has a situation similar to mine, and / or might be able to suggest
>> what
>> I might be able to do to get my production back on track.
>
>
> I'm a little confused. While FOP does indeed have some known
> performance issues with multi page documents,
> isn't the performance issue YOU'RE talking about
> inside Acrobat?
>
> BugBear
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/0.95---Acrobat-Performance-Problems-tp20774481p20777151.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: 0.95 & Acrobat Performance Problems
Posted by paul womack <pw...@papermule.co.uk>.
egibler wrote:
> Hi,
>
> I receive lots and lots of small (1-3 page) PDFs each day, combine them
> using Acrobat Professional, and print and mail them for clients. One client
> recently upgraded from FOP .2x to FOP 0.95, and the combining of his files
> has become nearly impossible. It'll put the first 10 pages together fairly
> quickly, but gets incrementally slower with subsequent additions until the
> process grinds to a halt before page 150 or so. He tends to send me batches
> of between 1500 and 3500 pages, so I'm well shy of what I need to
> accomplish. The process worked great with the earlier version, and works
> fine with my other clients' PDFs that are created with various other tools.
>
> These files are invoices. Batches of which regularly represent several
> millions of dollars, so they really have to be right, timely, and without
> duplicates or omissions.
>
> I'm not at all familiar with FOP - please forgive my ignorance. I hadn't
> heard of it until the problem occurred and I started doing a bit of
> research. From what I've read, there seems to be a fair amount of
> discussion related to memory issues and large PDFs. I'm wondering if anyone
> else has a situation similar to mine, and / or might be able to suggest what
> I might be able to do to get my production back on track.
I'm a little confused. While FOP does indeed have some known
performance issues with multi page documents,
isn't the performance issue YOU'RE talking about
inside Acrobat?
BugBear
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org