Description: The track changes redline in the margins is perfectly visible on my screen, but when printed or converted to pdf, it outputs very thinly, I suspect at about 0.05pt. The resulting line is barely visible on paper, and hence not useful. Looking for a way to set the line properties (e.g. make it 2pt wide), similar to setting the other track changes properties. Steps to Reproduce: 1. Create new document, add line of text. 2. Turn on track changes (Menu: Edit; Track Changes; Tick 'Record'; Tick 'Show') 3. Change line of text, redline appears at left. 4. Output as pdf (Menu: File, Export as PDF) 5. Open pdf, zoom in as much as possible. Actual Results: In the zoomed in pdf, you can see the text stroke thickness increases, but the redline thickness remains the same (thin). Expected Results: The thickness of the redline should increase to maintain visibility at high resolution, or the thickness should be user-settable. Reproducible: Always User Profile Reset: Yes, happens on new install on virtual machine. Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 136369 [details] Sample document with redline
I've attached a sample document with both a redline and a 1pt table border. If you zoom in 600% you can see the redline remains a hairline. This is nearly invisible when printed. I've also simplified the reproduction steps: Steps to Reproduce: 1. Create new document, add line of text. 2. Turn on track changes (Menu: Edit; Track Changes; Tick 'Record'; Tick 'Show') 3. Change line of text, redline appears at left. 4. Zoom in 600% (Menu: View, Zoom) Actual Results: In the zoomed in doc, you can see the text stroke thickness increases, but the redline thickness remains the same (thin). Expected Results: The thickness of the redline should increase to maintain visibility at high resolution, or the thickness should be user-settable.
Created attachment 136370 [details] Not a great photo, but shows the almost invisible redline after printing
Created attachment 136515 [details] test file exported as PDF Tested PDF export of the test document with Version: 6.0.0.0.alpha0+ Build ID: 14b057b7fe224ebf9409bf834e0c4c1a83187f76 Threads CPU : 4; OS : Linux 4.4; UI Render : par défaut; VCL: gtk3; Ubuntu_16.04_x86-64 Locale : fr-FR (fr_FR.UTF-8); Calc: single On the PDF the red line seems more thick than in LO on my screen FullHD (1920x1080). In LO zooming increases the thickness of the red line. Best regards. JBF
Please could you: - attach you own PDF exported from your test file - give the resolution of your screen - confirm the LO version in which you observed this behavior. Set status to NEEDINFO, please set it back to UNCONFIRMED once requested informations are provided. Best regards. JBF
Created attachment 136531 [details] Photo of printed Jean-Baptiste Faure PDF Sorry, I can't attach the requested pdf for the reasons in the next post, but I agree that my pdf looked like your pdf, and I can reproduce the problem with your pdf. My screen resolution is 4k (3840x2160). The problem occurs on my production LO 5.3.1.2 and on the development version 6.0.0.0 alpha. Sorry, I'm not sure I understood what you tested, but just to re-state: this is not a problem with the screen rendering of the redline, it is a problem with the PRINT rendering of the redline BECAUSE the line is too thin in the PDF. If I print your pdf, then the redline (black line in your pdf) is so thin it is almost invisible. I've attached a jpg photo of the printed paper and you can see the top redline is almost invisible.
Created attachment 136532 [details] Patch that makes the pdf line thicker The reason I can't attach my own pdf of the problem is that with some very helpful advice from the nice people at collabora (Thanks Eloy), I have managed to solve the problem to my satisfaction. They suggested drawing a rectangle instead of a line in: sw/source/core/text/frmpaint.cxx The attached patch does this with a rectangle width of 32. This works very well and is very visible on my printer. I have not submitted the patch for review yet because I am very new to all this, and I'm not a c++ programmer, so I'm dancing in the dark. Also, I think the width of the rectangle (32) should be an option, just as the position and colour of the line is an option, and that will take a long time for me to learn how to program. Also, I don't know if I have introduced any leaks with the tools::Rectangle construction. Thank you for your interest in my problem. A.
Created attachment 136533 [details] PDF that shows the result of the patch - a thicker redline. This pdf shows the redline (now a rectangle). I have not uploaded a photo of the printed result - but it is clearly visible. Best regards, A.
Sorry I misunderstood the problem, confusing the red line (table border) on your test file and the track change mark. Setting as NEW. Best regards. JBF
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
@Xisco: there is a patch in attach. Can we use it to fix this bug?
Dear awyvern1983, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still reproducible with LibreOffice 6.3.4.0+ under Ubuntu 18.04 x86-64 Is the attached patch usable to fix this bug ? Best regards. JBF
Dear awyvern1983, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to awyvern1983 from comment #0) > The track changes redline in the margins is perfectly visible on my screen, > but when printed or converted to pdf, it outputs very thinly, I tried exporting to PDF (Ubuntu 20.04), and it looked as clear as in LO.