Created attachment 172041 [details] Example of PDF with wrong line wrapping on Linux and Windows I have collected many PDF document which have the line wrapping problems with Draw. All these PDFs are displayed correctly in other viewers. I checked on Linux (Ubuntu 20.04) with Adobe Reader, Chrome / Chromium, Firefox, Evince, Okular, GIMP, and ImageMagic, and others. On Windows 10 with Adobe Reader, Chrome / Chromium, Firefox and Edge. Only Draw has this problem on both platforms. I've attached an example with an actual PDF file and a screenshot that compares the view in one of the above viewers to the view in Draw. Incorrect line wrapping prevents DRAW from being used directly for work with these files. Also, I believe there is another problem related to this. In the most of my PDF examples with unwrapped text Draw displays files equally wrong on Windows and Linux. However, some PDF texts are displayed differently on Linux and Windows. Let's just look at the file from Bug 49697. I have attached the file from this bug report and a second screenshot comparing the page 4 views of this file on Windows and Unix. On Windows, the text is wrapped correctly, but on Linux it is not. It might be a problem with the default font. However, all other viewers in the above list display this PDF file the same way on both platforms. Steps to reproduce: 1. Open attached file with Draw on Linux and Windows and open attached file with any of above viewers 2. Export the open in Draw file as PDF. 3. Open the file from Bug 49697 with Draw on Windows and Linux. Current behaviour: 1. The document open in Draw has wrong formatting due to unwrapped lines. Compare with any other viewer. Or see my screenshot. 2. When the document, opened in Draw, is being exported as PDF the new PDF has corrupted content because all long unwrapped lines are right trimmed. 3. The page 4 of the file from Bug 49697 looks differently on Windows and Linux. Expected behaviour: 1. The text formatting is correct. All lines are wrapped per the document design. 2. After being exported from Draw, as PDF, the new PDF document looks identically to the original document. 3. The file from Bug 49697 looks identically on Windows and Linux.
Created attachment 172042 [details] Screenshot with wrong line wrapping on Linux and Windows
Created attachment 172043 [details] PDF file from Bug 49697
Created attachment 172044 [details] Screenshot showing different line wrapping on Linux and Windows
*** Bug 142309 has been marked as a duplicate of this bug. ***
LibreOffice is not a PDF editor, nor a PDF viewer! Rather we filter import the structure, and depending on filter will either render PDF to image (with high fidelity to layout); or will render PDF text runs and layout to appropriate Draw objects. Text runs not being justified or wrapping to match the source PDF representation in Draw objects is not a bug.
If text runs not being justified or wrapping to match the source PDF representation is not a bug, then I see several public misconceptions here. - In many sources, including libreofficehelp (https://www.libreofficehelp.com/modify-edit-pdf-free-libreoffice-draw/), is mentioned as the first tool for fast PDF modification, especially on Linux. - All Ubuntu versions since at least 2015 include Draw in the list of recommended applications for opening PDFs. Draw then needs to inform users that the PDF representation in Draw may not be accurate. GIMP and ImageMagic only render PDF to image and do it very accurately. Perhaps Draw should give options: render to image with the guarantied layout, or render to appropriate Draw objects.
(In reply to yury.dubinsky from comment #6) > If text runs not being justified or wrapping to match the source PDF > representation is not a bug, then I see several public misconceptions here. The public misconception is that PDF is anything more than a presentation format. It is not intendeted to be editable, and its internal structures reflect that. Inadequicies of the filter import arise from the non-editable nature of PDF presentation which has no embedded sytactic details. For a legitimate bug against the pdfio filter see bug 104597 where RTL script text runs are reversed on import. LibreOffice is not a PDF editor _and does not claim to be_ trying to make it such is abusing the application. @Miklos, Thorston any opinion you'd like to add?