Issue 107554

Summary: PDF/A export crashes impress
Product: Impress Reporter: barthanssens <bart.hanssens>
Component: save-exportAssignee: 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 Flags
presentation that crashes impress none

Description barthanssens 2009-12-09 11:32:57 UTC
Win7RC (build 7100) inside virtualbox

Exporting presentation to PDF/A crashes Impress.
(range: all, images: lossless compression + reduce image resolution 300 dpi, 
general: PDF/A-1a + export bookmarks)

Exporting to PDF/A works in OOo 2.4 on same machine, and exporting to "just" 
PDF with tags also works in 320m6
Comment 1 barthanssens 2009-12-09 11:34:42 UTC
Created attachment 66566 [details]
presentation that crashes impress
Comment 2 wolframgarten 2009-12-09 11:53:16 UTC
Reproducible. Reassigned.
Comment 3 wolframgarten 2009-12-09 11:58:03 UTC
Happens also with other docs but not with an empty one.
Comment 4 wolframgarten 2009-12-09 12:15:12 UTC
Happens also on XP SP3  without virtual box.
Comment 5 philipp.lohmann 2009-12-09 12:36:14 UTC
taking over
Comment 6 wolframgarten 2009-12-09 13:09:44 UTC
For your record, your error report has the following id: rut5s2c
Comment 7 philipp.lohmann 2009-12-09 13:27:42 UTC
target
Comment 8 philipp.lohmann 2009-12-09 15:07:45 UTC
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.
Comment 9 philipp.lohmann 2009-12-09 15:26:17 UTC
platform, set sj on CC
Comment 10 philipp.lohmann 2009-12-09 18:18:35 UTC
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.
Comment 11 philipp.lohmann 2009-12-10 12:59:59 UTC
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.
Comment 12 barthanssens 2009-12-10 13:57:01 UTC
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 :-/ )


Comment 13 wolframgarten 2009-12-11 10:18:52 UTC
Verified under Windows, too.
Comment 14 philipp.lohmann 2010-02-05 14:35:13 UTC
integrated in OOO320m8, closing