Created attachment 114861 [details] file that breaks your toys (like sid) Hello everyone, I have this imported file from ppt, which you can find attached. It was a complex one, but I've been stripping everything off and by test and error the only thing left is a buggy text box. If you remove that, the presentation can export to pdf well, and a with new text box also works. However, with this box, not only the export fails, but my desktop session crashes. I have an XFCE desktop environment that rarely crashes, and I have also experimented this on Openbox, and in both it brings me back to the login screen. Also, I tested it at LibreOffice for Windows (v 4.4.2) and the export crashed, but without harming Windows. However, to give more accurate info about it I have to do more data on Windows platform. I can't find any log giving me any clue about what happened, and executing it from a console is useless as the console itself is killed when the error rises, so that no message can be saved. How could I get the error message? I suspect on font types, because the original one brought Calibri inside, which I don't have installed, and I used "non common" font types in the other text boxes, namely, Fujiyama2[1] and Cantarell[2]. I can attach them if needed. Key facts: - originally ppt file - rare fonts - reproductible error - constrained to the text box - crashes whole desktop Please, help me find why this happens! 1: http://www.azfonts.net/load_font/fuji2n.html 2: http://www.google.com/fonts/specimen/Cantarell
I have just tested it in Windows XP, with LibreOffice 4.4.2, and the export also fails. The message reads something that, translated, is "Error when saving the document X. Write error. The file could not be written" I can confirm that the disk is not full, and that if the text box is removed, the pdf can be exported. Wait there, there's something more! I originally filled the textbox area with a custom parallel lines pattern, literally translating, "shadowing". If you open the file you may see violet lines at 70º with 0,7cm spacing, as background. The funny thing is that I removed that background... only aparently. Now I can overlap a solid color to this apparently removed lines background! It's cool! My final hypothesis is that, somehow, I saved a textbox with more than one background, and LibreOffice only can imagine one background per box at a time, and therefore it explodes in pieces when it sees multiple backgrounds in a box. Hope it helps!!
Created attachment 114862 [details] Buggy presentation with textbox coloured yellow This file has been edited on LO v4.4.2, Windows. Previously it was "broken" in LO v4.3.3.2, Debian, and originally it was a ppt template, without text boxes.
Created attachment 114863 [details] Buggy presentation with textbox coloured yellow viewed in LOv4.3.3.2 This file has been edited on LO v4.4.2, Windows. Previously it was "broken" in LO v4.3.3.2, Debian, and originally it was a ppt template, without text boxes. This is how I see the file in version 4.3.3.2. Note that at the right side there is no "Area" tab. However, in options, it says that the background is yellow.
Created attachment 114864 [details] Buggy presentation with textbox coloured yellow viewed in LOv4.4.2 This file has been edited on LO v4.4.2, Windows. Previously it was "broken" in LO v4.3.3.2, Debian, and originally it was a ppt template, without text boxes. This is how I see the file in version 4.4.2. Note that you can see the "official" yellow background plus a cool violet line pattern.
First, the file isn't valid. See http://odf-validator.rhcloud.com/ buggy-presentation.odp/styles.xml[2,26369]: Error: attribute "draw:fit-to-size" has a bad value. Possible values are: false,true buggy-presentation.odp/styles.xml[2,63444]: Error: attribute "draw:fit-to-size" has a bad value. Possible values are: false,true With which LO version did you convert your ppt file? Could you attach the original ppt file not odp file)? On pc Debian x86-64 with master sources, it makes my entire machine freeze. Impossible to kill process (switching session is not possible), must restart.
(In reply to Julien Nabet from comment #5) > ... > With which LO version did you convert your ppt file? LO v4.3.3.2, Debian Jessie, installed from apt > Could you attach the original ppt file not odp file)? Yes, in the next comment. > > On pc Debian x86-64 with master sources, it makes my entire machine freeze. > Impossible to kill process (switching session is not possible), must restart. Ha! It broked your toys, too. I'm attaching the original template. However, I created the textbox with "double background", and filled it with "paragraph breaks" (enter-key) so that it was high enough. I don't know how to force a box size, by the way. I suspect that there's something wrong in the coordination between the options through the menus and the options in the side-panel. The hypothetical concurrent error could have been exploited by me during the slow performance of my machine rendering the A0 loaded with a big image and a large box with line pattern. I haven't been able to reproduce the error of creating such an uggly textbox.
Created attachment 114985 [details] Buggy presentation template
Created attachment 114994 [details] ppt file converted in odp with master sources updated today
I can't debug anything since it freezes my machine. So I can't help here. Certainly someone will be able to.
I can open files from comment 7 and comment 8, also export these to PDF. I see no problem with these. The original file from description has some problems. It contains a WMF with about 72kb, probably containing bitmap infos (pixelated when zooming in). Zooming in already crashes at some point. When trying to export to PDF I get a dialog saying 'Error saving the document ...'. The doc contains a text box and the graphic. The text box is empty, top-left of the graphic (press TAB to cycle through selected objects to find it). The graphic has the WMF as content, plus the text 'text'. Breaking (context menu) the object shows that it contains all those single lines as vector geometry, not as bitmap. I would guess that the problem in handling that graphic may have to do with handling it as bitmap. Taking a deeper look...
Zooming in deeply can already crash the office, need to check how this graphic is rendered internally.
The WMF as metafile is not decomposed and painted using primitives, but a bitmap gets created using the canvas. This is for UI dependent of the zoom since it gets created in full size always, not clipped to the visible area. For PDF export the PDF resolution is used and tries to create a canvas of tenthousands pixel width and height what fails and thus throws an exception and breaks the PDF export. This is done by purpose, there is a flag at the metafile 'bUseCanvas which is set to true in ReadGDIMetaFile for EMF_PLUS WMFs and WinMtfOutput::PassEMFPlusHeaderInfo(). Thus pixel output and quality is created instead of vector graphic quality. When not setting the flag display is better and faster and PDF export works. Looking for the reasons for the flag, probably quality reasons since the WMF import is not too good quality. In a case like this, it would be perfect, but when more complex WMF features are used it might be inadequate.
Discussed internally, found the reason: There is emf and emfplus functionality that gets imported to vcl metafiles (as comments including the data stream), but not rendered by the normal metafile users. It is only implemented to be used in the canvas metafile renderer. To use emf and emfplus in all scenarios (break object, use vector data preferred to bitmap data, avoid crashes like this, ...) it would be necessary to interpret these info not in canvas renderer, but in the metafile-to-primitive converter. Then all geometry could be used (and thus rendered) in the usual (primitive) way with all its possibilities. Even when it would work to add a 20000x35000 pixel 24bit bitmap to the exported PDF, nobody would want that if it is also possible to get the geometry as vector data. Question is how much work it would be to change this. the emf and emfplus is already imported at the standard vcl metafile, the canvas renderer and how he interprets that stuff can be used as blueprint for how to convert to primitives. Conversion to primitives already has a class, there it would need to be added.
Checked on 64bit linux. System gets very fast unresponsive to seriously blocked when zooming in, zoom above 500 (used 800%) crashes the office. PDF export not possible, also crashing. When zooming very deep the lines are not painted anymore (canvas renderer throws exception) and warnings appear like: warn:vcl.gdi:14639:1:vcl/source/gdi/alpha.cxx:69: Bitmap should be 8bpp, not 24bpp warn:vcl.gdi:14639:1:vcl/source/gdi/alpha.cxx:70: Bitmap isn't greyscale warn:legacy.tools:14639:1:vcl/source/outdev/bitmap.cxx:977: OutputDevice::ImplDrawAlpha(): non-8bit alpha no longer supported! warn:legacy.tools:14639:1:vcl/source/gdi/bmpfast.cxx:545: FastBmp BlendImage: unusual MSKFMT Even when using/forcing to primitive decom,position and rendering there is something like warn:vcl:14722:1:vcl/unx/x11/xlimits.cxx:23: overlarge pixmap: 26907 x 34848 thus linux will need some care anyways. Did not check mac, but probably similar.
Looked at https://msdn.microsoft.com/en-us/library/cc230826.aspx, ImplRenderer::createActions, ImplRenderer::processEMFPlus and EnhWMFReader::ReadEnhWMF(). To get that functionality to the prinitive decomposer (MetafilePrimitive2D::create2DDecomposition) is a lot of work.
Version field must correspond to the earliest version when the bug has been encountered.
Dear developer, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
Created attachment 143009 [details] buggy in LOO6051 win10-64 double size of file lines in text box now like vector lines, double size of file in win10-64 and LOO 6.0.5.1 i cannot change the backgrounf from white to yellow or change the lines in angles
Created attachment 143010 [details] buggy template in LOO6051 win10-64 half size of file i found no problem in windows 10-64 in printing pdf or zoom in LOO6.0.5.1-64
Created attachment 143011 [details] buggy template as pptx of MS-Office2016 win10-64 half size of file buggy template file in pptx reduced with MS Office 2016 to half file size. possible way of workaround also for actual LOO on linux with newer pptx.
i see significant changes between Version 5.4.7.2 and 6.0.5.1 on windows by this files. Pdf printing and zoom is without problem in windows. Background file is changed in better lines. File sizes have significant changes. With MSO2016 converted pptx should tested by linux users. So the problem is perhaps solved or partly solved.
buggy presentation with textbox coloured yellow is new buggy ok for me in 6.0.6.2 for win10-64 yellow background is in main and in side icon preview not ok in 6.1.0.3 for win10-64 yellow background is is not in main window only in side icon preview
not ok in 6.1.0.3 for win10-64 yellow background is is not in main window only in side icon preview but after a click on the object, yellow background color is seen in main window.
I didn't get any crashes with both presentation files (odp and ppt) in Version: 6.1.2.1 Build ID: 65905a128db06ba48db947242809d14d3f9a93fe CPU threads: 4; OS: Windows 6.1; UI render: default; Locale: ru-RU (ru_RU); Calc: group threaded Xisco, may be close this bug as WFM and open new with filter/specification problem?
Sorry for not testing extensively but attachment 114861 [details] that used to show error with LO 5.0 in Windows can be exported to PDF fine in LO 6.3+. I'll set WFM.