Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | PDF/A export crashes impress | ||||||
---|---|---|---|---|---|---|---|
Product: | Impress | Reporter: | barthanssens <bart.hanssens> | ||||
Component: | save-export | Assignee: | philipp.lohmann | ||||
Status: | CLOSED FIXED | QA Contact: | issues@graphics <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P2 | CC: | issues, sven.jacobi, thb, wolframgarten | ||||
Version: | OOO320m6 | ||||||
Target Milestone: | OOo 3.2 | ||||||
Hardware: | PC | ||||||
OS: | All | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Issue Depends on: | |||||||
Issue Blocks: | 99999 | ||||||
Attachments: |
|
Description
barthanssens
2009-12-09 11:32:57 UTC
Created attachment 66566 [details]
presentation that crashes impress
Reproducible. Reassigned. Happens also with other docs but not with an empty one. Happens also on XP SP3 without virtual box. taking over For your record, your error report has the following id: rut5s2c target Fixed the crash (stack underflow in PDFwriterImpl), but not the root cause. @sj: someone does one more Pop than he does Push; that needs to be investigated. platform, set sj on CC The Push/Pop disparity is rather unfortunate and is an artifact of the transparency removal method (whence this only happens in PDF/A mode, not in normal PDF). That method reorders paint actions - and needs an overhaul IMHO -, but does not AFAIK produce instances with actual wrong painting (and at least it is rather well tested since it does the same job for printing). Changing it now just before 3.2 release would be too risky since quite involved, so we'll live with the fix for the crash until a rewrite of that code comes around. as discussed with wg: verified in CWS ooo32gsl10 However as we have seen this IS memory intensive and can still crash in tight memory conditions (for instance on a VM with only 1.5 GB memory and 2GB swap on which multiple people are running testtools at the same time ;-) ). Joking aside, changing transparencies into high resolution bitmaps (which is required here) certainly is a memory intensive job; the better approach with PDF/A documents in mind would be to avoid transparencies. Whow, fixed already, I'm Impressed ;-) Great job for getting the fix implemented so soon ! Quite a few presentations and letters have company logos on it, but in that case transparency could indeed be avoided by creating a logo with the desired background color and add that to the presentation / letter template instead of a transparent one... However, avoiding transparency altogether may not always be possible: the particular use case I have in mind are business brochures / reports with Venn- diagrams or other schemas created from within Writer / Draw (although one could export it first to PNG, then add it back to the document, this would be not be accepted by most end-users :-/ ) Verified under Windows, too. integrated in OOO320m8, closing |