Apache OpenOffice (AOO) Bugzilla – Issue 77972
insert pdf file causes collapse
Last modified: 2017-05-20 10:45:35 UTC
1.create a Calc document; 2.choose insert->Floating Frame; 3.select an unempty pdf file as the contents in the dialogue of "Floating Frame Properties",click okï¼› 4.select "unicode" as "character set" in the dialogue of "ASCII Filter Options",click okï¼› 6.OOo end without error message
Confirm - OpenSUSE 10.2. OOo 2.1
Confirming with 2.3m211 on WinXP - Calc crashes after couple of seconds.
Kubuntu 6.06, OOo 2.2 doesn't silently crash, but consumes about 100% CPU. Maybe it depends on content of PDF. Consider to lower prio to P3, because inserting PDF as text is bad thing, until PDF import filter will be available.
Hi Niklas, don't know who's responsible. Insert Floating rame with pdf does work. Selecting the frame and trying to remove with DEL key results in Crash with SVX on Stack. Version is m217 on Linux. Frank
Target 3.0
I've replicated this bug on Windows XP/ OpenOffice 2.3.1. I tried Floating Frame with other files types; I noticed Floating Frame works with images, text files(.txt, .gif, .bmp). An interesting variation I did was using a PostScript file as opposed to a PDF. Open Office did not crash. I've included a link to a PostScript file. Instructions on how to use the attached PostScript file: * Download "intro.ps" from www.math.mtu.edu/~msgocken/intro/intro.ps * Open OpenOffice. * Click on New --> Spreadsheet(Calc). * Insert --> Floating Frame. * In the Floating Frame dialog box, for contents, choose "intro.ps", click okay. * Select "unicode" as the "character set" for "ASCII Filter Options",click okay.
Created attachment 54336 [details] example file
It has nothing to do with floating frames, the same happens when just loading the file (as unformatted unicode text into Writer). With the attached file, I get crashes similar to crashreporter bug #142015#.
The import filter treating a PDF file as an array of unicode codepoints is not a good idea... Anyway, this seems to be a reproducable way of testing for #142015#: Feed a string of random codepoints to the USP library till it crashes. Only very few real-world strings would cause such a crash, but the attached PDF seems to have that property: if its zlib-compressed byte stream is interpreted as a string than that is confusing enough to throw USP's layout engine or OOo's wrapper around this service off the track.
An unfinished pair of unicode surrogates seems to be involved, here the relevant substring: U+2CDB U+DB6D U+920E
target, this is not a 3.0 showstopper
accepted but retargeting unless somebody else would like to debug this for OOO3.1
Was able to reproduce this issue in Version 3.1.1 OOO310m19 (Build:9420) running Windows Vista-64 SP1.
I am on Windows Vista SP2 using OO 3.1.1 Build OOO310m19 (9420). OO doesn't crash on me however, the pdf file is not in readable format. I test my own created pdf file and also the pdf file give by nn Mon Jun 9 10:28:59 +0000 2008 . Follow Up Test: 1) Changed the character set, still files is not readable.
Tested on 4.0.1 Windows 8 installation, was able to replicate the bug. Program crashed.
Reset the assignee to the default "issues@openoffice.apache.org".