Description: A frame with any value of transparency ( but 0%) in a page affect the export aspect of the whole page. The page is transform into an image. As result : 1-The text is an image ( in pdf selecting text is impossible ) 2-The size of the resulting pdf differ according to the image export options of the export pdf formular. Under certain circumstances only part of the page, at the level of the frame is affected by the transformation in an image. It is more likely to be an artefact of the algorithm which transform the frame with transparency into an image: everything that is in reach of the frame, as a whole paragraph ( even if only a part of it is under the frame ) is transform into an image. Which is quiet unexpected.... I have 2 files as examples: 1) the first files affected 2) a simple reproduction of the bug Steps to Reproduce: 1. some text in a page 2. a frame with color filling with transparency above 0% ( plain color with X% transparency or gradient ) 3. pdf export ( with jpeg compression : ex: 30% 75 dpi ) Actual Results: Frame with transparency becomes images in pdf ! and The text in it is an image ! The resulting pdf file is partially transform into an image nearby the frame. Expected Results: Text in frame as normal text. Text in file as a normal text. Transparency or color gradient as object not as image. As workaround : 1 ) a flat image as background ( with or without text) 2 ) above the text in transparency ( or 1% shade of police color ) Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Windows / Firefox 50: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/50.0
Created attachment 133673 [details] two odt files and their pdf export Simple Reproducing file with the bug as pdf exportation Report_bug_Simple.odt Report_bug_Simple.pdf part of original odt file with the resulting pdf bug Report_bug.odt Report_bug.pdf
$ uname -r 4.4.0-78-generic libreoffice Version: 5.1.6.2 Build ID: 1:5.1.6~rc2-0ubuntu1~xenial2 Threads CPU : 2; Version de l'OS :Linux 4.4; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group OS ubuntu 16.04.LTS Proc AMD A6-5400K APU
As curiously as it sounds: It may depend on the quality DPI of compression 1st test: file.AAA export pdf ( JPEG compression quality 30% 150dpi ) Result: -Frame with linear gradient OK -Text within the frame can be selected - everything fine AFAIK 2d test: export pdf ( JPEG compression quality 30% 75dpi ) Result: -Frame with linear gradient as image -Text within the frame as image - block of text at the same position in page as image ( but the end of thoses lines (numbers) ) - closing writer and open it again = restoration data available for the file. - return to 150 DPI don't help anymore.... 3d test: --- -re-open file.AAA and
3d test: - erase recovery data ( lock. ) - open original file.AAA without recovery - result = as test 1 everything seems perfect
after renaming the profile /home/user/.config/libreoffice/4/user a brand new profile appears AND I am NOT able to reproduce the problem for the moment It seems that the profile was corrupted (?) How a corrupted profile leads to such phenomena ? I keep the corrupted profile for a while. He has: -very big "backup" ( as expected ) -a more complete "config"
(In reply to mikael_monnier from comment #5) > after renaming the profile > /home/user/.config/libreoffice/4/user > > a brand new profile appears > > AND > I am NOT able to reproduce the problem > for the moment > > > It seems that the profile was corrupted (?) > How a corrupted profile leads to such phenomena ? > > I keep the corrupted profile for a while. > He has: > -very big "backup" ( as expected ) > -a more complete "config" Sometimes the profile gets corrupted and it leads to unexpected behaviours. That's why we always ask reporter to reset their profile. There is nothing we can do here. Closing as RESOLVED WORKSFORME