xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maruan Sahyoun <sahy...@fileaffairs.de>
Subject Re: FOP memory growing with a lot of <page-sequences>
Date Fri, 19 Apr 2013 14:36:58 GMT
well - it is one print job, has paperhandling marks, goes to an envelope stuffing machine ....

Maruan Sahyoun

Am 19.04.2013 um 14:56 schrieb "Kerry, Richard" <richard.kerry@atos.net>:

>  
> Yes I did understand what you wrote, and the earlier correspondent.
>  
> I was attempting to ask why.
> It seems illogical to treat many small documents as one large one.  Especially if the
large one is so large that it is hard to process. 
>  
>  
> Regards,
> Richard.
>  
>  
>  
>  
>  
> Richard Kerry
> BNCS Engineer
> T: +44 (0)20 82259063
> M: +44 (0)7812 325518
> Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ
> richard.kerry@atos.net
> uk.atos.net
> 
> 
> 
> 
> 
> This e-mail and the documents attached are confidential and intended solely for the addressee;
it may also be privileged. If you receive this e-mail in error, please notify the sender immediately
and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability
cannot be triggered for the message content. Although the sender endeavours to maintain a
computer virus-free network, the sender does not warrant that this transmission is virus-free
and will not be liable
> From: Maruan Sahyoun [sahyoun@fileaffairs.de]
> Sent: 19 April 2013 12:04
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: FOP memory growing with a lot of <page-sequences>
> 
> no - that's one document with 100k pages
> 
> Maruan Sahyoun
> 
> Am 19.04.2013 um 13:04 schrieb "Kerry, Richard" <richard.kerry@atos.net>:
> 
>>  
>> Surely that's 100k documents, each with one page (or a small number of pages) ?
>>  
>>  
>> Uncertainly,
>> Richard.
>>  
>>  
>>  
>>  
>>  
>>  
>> Richard Kerry
>> BNCS Engineer
>> T: +44 (0)20 82259063
>> M: +44 (0)7812 325518
>> Room EBX 301, BBC Television Centre, Wood Lane, London, W12 7RJ
>> richard.kerry@atos.net
>> uk.atos.net
>> 
>> 
>> 
>> 
>> 
>> This e-mail and the documents attached are confidential and intended solely for the
addressee; it may also be privileged. If you receive this e-mail in error, please notify the
sender immediately and destroy it. As its integrity cannot be secured on the Internet, the
Atos group liability cannot be triggered for the message content. Although the sender endeavours
to maintain a computer virus-free network, the sender does not warrant that this transmission
is virus-free and will not be liable
>> From: Maruan Sahyoun [sahyoun@fileaffairs.de]
>> Sent: 19 April 2013 11:56
>> To: fop-users@xmlgraphics.apache.org
>> Subject: Re: FOP memory growing with a lot of <page-sequences>
>> 
>> Hi 
>> 
>> e.g. we have a banking customer where account statements are produced and sent for
printing. A single PDF has around 100k pages.
>> 
>> Maruan
>> 
>> Am 19.04.2013 um 11:04 schrieb Paul Womack <support@papermule.co.uk>:
>> 
>>> aemitic wrote:
>>>> Thanks for the suggestion.
>>>> 
>>>> This /workaround/ (it's not a solution) cannot be applied. Why:
>>>>  - internal pdf links would not work
>>>>  - pdf bookmarks would not work
>>>>  - page numbering would not be correct
>>>>  - creating over 150000 PDFs and then merging them with an external tool
is
>>>> unacceptable from a performance point of view
>>> 
>>> I cannot imagine a (useful) PDF with 150,000 pages.
>>> 
>>> This may well be a limitation of my imagination :-)
>>> 
>>> Can you tell me a little about this?
>>> 
>>> BugBear
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
> <blank>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

Mime
View raw message