Description: Since version 6 of Writer, there is a regression were math objects are displayed incorrectly when exporting an RTL document as a PDF file. An example file is attached. If converted to PDF using LibreOffice 6.0+ (fresh), than the formula in the pdf looks messed up. Using version 5.4.5 (still), the bug does not occur. In addition, if the directionality of the text changes to LTR then the PDF is made correctly. This bug occurs in both 6.0.0.3 and 6.0.2.1 which are the oldest and newest versions of LibreOffice 6 which are available in the repositories of Arch Linux. Steps to Reproduce: 1. Set directionality of text to Right-To-Left (Shift+Ctrl+D) 2. Insert -> Object -> Formula... 3. Enter some formula 4. Export file to PDF Actual Results: Formula is rendered incorrectly in PDF file. Expected Results: Formula should have the same rendering as in the odt document. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 6.0.2.1.0+ Build ID: 6.0.2-1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (en_US.utf8); Calc: group User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Created attachment 141020 [details] This file is exported to PDF incorrectly using Writer 6.0 but correctly with Writer 5.4
Seeing this with LO 6.0.3.1 on GNU/Linux Mint 18 - both when exporting to PDF and when printing to file.
Created attachment 141040 [details] bibisection log I performed a bibisection using bibisect-linux-64-6.0 and this is the result: 283c0946ea76b829d4015eaa3145a813d0289036 is the first bad commit commit 283c0946ea76b829d4015eaa3145a813d0289036 Author: Jenkins Build User <tdf@pollux.tdf> Date: Tue Aug 22 18:49:37 2017 +0200 source 302af8c2da58719844d22483b65a9fe5b3674684 source 302af8c2da58719844d22483b65a9fe5b3674684 :040000 040000 ab5c949018f652be4dbb647dc82874d8b309f358 16745f7c6069053b7fbad707a09c367320a1ee23 M instdir
(In reply to Shimi Chen from comment #3) > Created attachment 141040 [details] > bibisection log > > I performed a bibisection using bibisect-linux-64-6.0 and this is the result: > > 283c0946ea76b829d4015eaa3145a813d0289036 is the first bad commit > commit 283c0946ea76b829d4015eaa3145a813d0289036 > Author: Jenkins Build User <tdf@pollux.tdf> > Date: Tue Aug 22 18:49:37 2017 +0200 > > source 302af8c2da58719844d22483b65a9fe5b3674684 > > source 302af8c2da58719844d22483b65a9fe5b3674684 > > :040000 040000 ab5c949018f652be4dbb647dc82874d8b309f358 > 16745f7c6069053b7fbad707a09c367320a1ee23 M instdir I can confirm that reverting 302af8c2da58719844d22483b65a9fe5b3674684 fixes the issue, though I don’t really know how it would have caused such an issue.
Same commit as in bug 115967. Closing as RESOLVED DUPLICATED *** This bug has been marked as a duplicate of bug 115967 ***