To reproduce the problem just do the following: 1) Open any LibreOffice application (either Writer, Calc or Draw) 2) Create a figure (e.g. the smiley or an arrow) 3) Export the document as PDF 4) Open the created file Results: Figures always have a black coloured 1x1 pixel at their top/left.
I do not reproduce with LibO 3.4 rc1 under Ubuntu 10.04. But, a black pixel is very small :-) so could you please add an example file, odt and pdf version, showing the problem ? Thanks.
(In reply to comment #1) > I do not reproduce with LibO 3.4 rc1 under Ubuntu 10.04. > But, a black pixel is very small :-) so could you please add an example file, > odt and pdf version, showing the problem ? I can see it :-) Attached screenshot.
Created attachment 47116 [details] two wrong pixels around object in PDF export
NOT reproducible with Writer / Similey PDF export using "LibreOffice 3.4.0RC1 – WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:11)]", lossless or or not. Opening the PDF in AR X I can't see anything unexpected (as visible in vitriol's screenshot, although I use very big zoom). @Lars Knickrehm / all: Please attach a screenshot from PDF viewer with comments and contribute more detailed information concerning your OS, PDF viewer, PDF export settings and what ever might be related.
Perfectly visible for me. Viewers Foxit Reader and PDF-XChange, LibO 3.4 RC1 under Win7 64 bit. I attach a PDF.
Created attachment 47120 [details] PDF samle
Foxit reader reminds me to "Bug 31851 - Artifacts (vertical short lines) in PDF-Export" (I never again heard from Foxit).
Doing some tests I found out the following: 1) The problem occurs on Adobe Reader only. The pdf reader on my Nokia works nice and other pdf readers seem to work (as the others reported), too. 2) It's always 1x1 pixel: In case I zoom in, things zoom as they should, but the single 1x1 pixel dot stays where it is and does not zoom. Note: I used the attachment "PDF samle" for testing. The attached image shows the problem, just the way I see it, too.
(In reply to comment #8) > 1) The problem occurs on Adobe Reader only. It's not an Adobe Reader only problem. As I said I can view pixels in Foxit an PDF-XChange too. I don't use Adobe Reader, and I cannot test with it.
(In reply to comment #6) > Created an attachment (id=47120) [details] With Evince as PDF Viewer the dots are invisible. But the dots are still there, it seems. If you draw a smiley in Draw and convert it to curve, then ungroup the shape and go to Points mode, you can see the dots.
Created attachment 47147 [details] Smiley converted to curve in Points mode
I confirm Clio's observations. That's something new and LibO specific OOo 3.1.1 and 3.4-dev do not show those extra points. I think solving the extrapoint issue will also heal problems with PDF export. Bug 31851 - Artifacts (vertical short lines) in PDF-Export indeed seems to be concerning the same problem like this one, please see my comments there when I mark it at a DUP of this one, because here we have collected much more information. Unfortunately I do not know to whom we can assign this issue. @clio: Good shot!
*** Bug 31851 has been marked as a duplicate of this bug. ***
@Rainer Bielefeld: I think Thorsten could know this area.
*** This bug has been marked as a duplicate of bug 34990 ***
*** Bug 34990 has been marked as a duplicate of this bug. ***
Created attachment 48303 [details] classnetwork.odg .odg attachment from dup https://bugs.freedesktop.org/show_bug.cgi?id=34990
Rainer Bielefeld, this bug did not have an .odg file (the now dup'ed bug 34990 did). Semantics aside, let us move forward on addressing the issue of the pixel-sized dots. :) Problem reproduced in Ubuntu 11.04, 32-bit via the Terminal: cd ~/Desktop && wget -c https://bugs.freedesktop.org/attachment.cgi?id=48303 -O example.odg && unoconv --listener && unoconv -f pdf example.odg && acroread example.pdf lsb_release -rd Description: Ubuntu 11.04 Release: 11.04 apt-cache policy libreoffice-draw libreoffice-draw: Installed: 1:3.3.2-1ubuntu5 Candidate: 1:3.3.2-1ubuntu5 Version table: *** 1:3.3.2-1ubuntu5 0 500 http://us.archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages 100 /var/lib/dpkg/status 1:3.3.2-1ubuntu4 0 500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages apt-cache policy acroread acroread: Installed: 9.4.2-0natty1 Candidate: 9.4.2-0natty1 Version table: *** 9.4.2-0natty1 0 500 http://archive.canonical.com/ubuntu/ natty/partner i386 Packages 100 /var/lib/dpkg/status apt-cache policy unoconv unoconv: Installed: 0.3-6 Candidate: 0.3-6 Version table: *** 0.3-6 0 500 http://us.archive.ubuntu.com/ubuntu/ natty/universe i386 Packages 100 /var/lib/dpkg/status
Still visible with Master "LibO-dev 3.4.5 – WIN7 Home Premium (64bit) English UI [(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43 2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb 6a9633a-931d089-ecd263f-c9b55e9-b31b807 82ff335-599f7e9-bc6a545-1926fdf)]" Act of desperation: Assign to tbehrens@novell.com, because also visible in Presentation. @Thorsten: Please feel free to reassign if you do not want to be the assignee.
Created attachment 50259 [details] pdf sample, fixed version Should be fixed on master, could someone with a susceptible viewer please try this attachment?
(In reply to comment #20) > Created an attachment (id=50259) [details] > pdf sample, fixed version > > Should be fixed on master, could someone with a susceptible viewer please try > this attachment? I use PDF-XChange Viewer and I can see points in test.pdf. Non fixed at all for me...
Created attachment 50260 [details] Screenshot of test.pdf
ok, thanks for checking. let me get one of those viewers then, here.
I still see that dot: latest Adobe Reader release on German Windows 7 Home Premium 32bit
I believe we can close this one again. Lars Knickrehm, @vitriol Information concerning the LibO version you used for your review is required. I would really like to know from where you got the WIN Master build you used for your test. @Thorsten Can you contribute a Git link? I set target due to your Comment 20
(In reply to comment #25) > Lars Knickrehm, @vitriol > Information concerning the LibO version you used for your review is required. > I would really like to know from where you got the WIN Master build you used > for your test. Rainer, I have not used any version of LibO for my last test and comment... I have simply tested attached test.pdf (pdf sample, fixed version) provided by Tor.
@vitriol: Ah, yes, please excuse me - my reasoning was too sophisticated. Indeed, on your screenshot the dots can be found easily, and after I wiped the screen I now in a second attempt I also see them in Tor's PDF iwth AR X (but they really are nearby invisible). So we definitely can NOT close this Bug. @Tor: did you also do clio's test after the fix? may be we had a double-bug, and only one has been eliminated with your fix?
(In reply to comment #27) > @Tor: > did you also do clio's test after the fix? may be we had a double-bug, and only > one has been eliminated with your fix? > Assuming question was directed at me - nope, don't think so, was just mislead by my debugger - my fix was indeed incomplete, working on an updated one.
As I said in launchpad, In Ubuntu's LibreOffice, one can also reproduce this issue with KDE's Okular, and also by exporting to EPS first, and then using epstopdf to obtain a PDF file. So it seems to be something in the way LibreOffice generates the plot (EPS, PDF), that is not visible in EPS or some PDF viewers, but it is shown (or triggers a bug) in other PDF viewers. It can be observed by exporting to EPS a simple arrow. Unfortunately, my knowledge of EPS is not enough to understand what is wrong in the EPS generated. LibreOffice 3.3.4 OOO330m19 (Build:401) tag libreoffice-3.3.3.1, Ubuntu package 1:3.3.4-0ubuntu1
I believe I added Target:3.5 accidently, but we really should get rid of those ugly sly shit dots ;-)
fly shit - of course
*** Bug 46820 has been marked as a duplicate of this bug. ***
I can confirm that the issue still persists in LO 3.4.3, see Bug 46820.
*** Bug 49090 has been marked as a duplicate of this bug. ***
*** Bug 48163 has been marked as a duplicate of this bug. ***
Created attachment 63511 [details] Shows artefacts in the document itself Here is a document that shows the pixel artefacts even in the document. Just open it and you should see small points at the upper left and lower right of many of the graphic elements (not limited to rounded corners). The artefacts vanish for me when the zoom increases above 170%. The artefacts also go away when the header is deleted, or the frame at the right (which belongs to the header) is deleted.
I can confirm this bug on LibreOffice 3.5.5.3 Build ID: 350m1(Build:3) over Ubuntu 12.04 LTS (precise) amd64. And it is pretty annoying =/
Guedes, please do not toggle the version. For more on this please see http://wiki.documentfoundation.org/BugReport_Details#Version .
It is _not_ a solution but maybe it can help you. Export to EPS and then, open it on Scribus, an open source desktop publishing. Go to menu File > Export. There you can export to a new EPS or to PDF. In both cases, the 1x1 pixel dots was gone. Please, confirm if this solution works for you. Scribus version 1.4.1.svn, 6 February 2012, Build ID: C-C-T-F-C1.10.2-64bit, Using Ghostscript version 9.05 over Ubuntu 12.04 LTS (precise) amd64.
Ok Christopher M. Penalver. (In reply to comment #38) > Guedes, please do not toggle the version. For more on this please see > http://wiki.documentfoundation.org/BugReport_Details#Version .
Created attachment 65060 [details] dotscase.eps dotscase.fig dotscase.odg dotscase.pdf These are the files described in my comment (simple diamond shape). dotscase.eps dotscase.fig dotscase.odg dotscase.pdf
(In reply to comment #41) > dotscase.eps dotscase.fig dotscase.odg dotscase.pdf Stumbled upon this bug, too (LibreOffice 3.4.4 OOO340m1 (Build:402)) and looked into the files/exports. Simple diamond shape here, dots shows up in pdf viewed with okular (not evince). this is in the content.xml <draw:enhanced-geometry svg:viewBox="0 0 21600 21600" draw:glue-points="10800 0 0 10800 10800 21600 21600 10800" draw:text-areas="5400 5400 16200 16200" draw:type="diamond" draw:enhanced-path="M 10800 0 L 21600 10800 10800 21600 0 10800 10800 0 Z N"/> export to eps, okular does not show the points, although they are in the file (last two lines): tm setmatrix -1105 -1072 t 1 1 s 1105 1072 m 22104 1072 l 22104 30771 l 1105 30771 l 1105 1072 l eoclip newpath gs 0 0 m 20999 0 l 20999 29699 l 0 29699 l 0 0 l eoclip newpath 0 lw 1 lj 0.000 c 4923 4079 m 5694 4825 l 4923 5573 l 4154 4825 l 4923 4079 l 4923 4079 l pc 4154 4079 m 4154 4079 l pc 5695 5574 m 5695 5574 l pc fig file format is easier to read: pstoedit -dis -f fig dotscase.eps > dotscase.fig #FIG 3.2 Portrait Flush left Inches Letter 100.00 Single 0 1200 2 # polyline 2 1 0 0 0 0 999 0 -1 4.0 1 0 0 0 0 6 1803 588 2167 940 1803 1294 1440 940 1803 588 1803 588 # polyline 2 1 0 0 0 0 998 0 -1 4.0 1 0 0 0 0 2 1440 588 1440 588 # polyline 2 1 0 0 0 0 997 0 -1 4.0 1 0 0 0 0 2 2167 1294 2167 1294
(In reply to comment #42) Just found qpdf to decompress the pdf data to a readable stream: qpdf --stream-data=uncompress --normalize-content=y --filtered-stream-data dotscase.pdf dotscase4.pdf and then you can see the dots in the pdf stream, too: stream 0.1 w q 0 0.1 595.2 841.8 re W* n 1 1 1 rg 0 842 m 595.2 842 l 595.2 0.1 l 0 0.1 l 0 842 l h f* 0 0 0 RG q 0 w 0 J 1 j 126.3 734.1 m 146 714.4 l 126.3 694.7 l 106.6 714.4 l 126.3 734.1 l 126.3 734.1 l h S Q q 0 w 0 J 1 j 106.6 734.1 m 106.6 734.1 l h S Q q 0 w 0 J 1 j 146.1 694.6 m 146.1 694.6 l h S Q Q
*** Bug 53836 has been marked as a duplicate of this bug. ***
Maybe this helps to narrow down where in the processing chain the bug first shows up: If I create a rounded rectangle with a shadow, the dot also has a shadow.
Created attachment 67513 [details] Screenshot from okular displaying a rounded rectangle with shadow exported to PDF
I know we shouldn't switch versions or even applications, but I remember first encountering this problem when LibreOffice hadn't yet forked off of OpenOffice. Back then I was using some OpenOffice 3.2. Other than that I see exactly the same problems as described above on Ubuntu 12.04 LTS 64bit LibreOffice 3.5.4.2, pdf viewer Okular. I find this bug very annoying! Many people have reasoned that a single pixel is very small and hard to notice, but once you zoom out of a document it becomes VERY relevant!
With following process to post-process the crappy 1-pixel stuff generated by LO, I was able to get a relatively clean PDF (Fonts are not exported as fonts, but that is another topic): Save the file/export to EPS format. The EPS is pretty readable, so I remove the lines with the dots with the following awk script: ---8<---fixodg2pdf.awk-------- #!/usr/bin/awk -f # points (pc?) with the lr/ul corner being teh same {if (($1==$4) && ($2==$5)) {next;} } {print} ---8<------------------------- (save and chmod a+x fixodg2pdf) use it like ./fixodg2pdf.awk exported.eps > fixed.eps Then use gv to open it and save as PDF. There were issues with the bounding box for me with other tools, so the last step may be up to your preferred tool. Please, can somebody fix the exports of LO? This makes the whole drawing part of LO pretty unusable.
With gv you cannot save to pdf (it will be eps), so I took this bash shell script with a gs command. You might want to crop the pdf to the bounding box afterwards with pdfcrop (http://www.ctan.org/tex-archive/support/pdfcrop), which comes with latex (also uses gs, so it could be integrated somehow, but did not check that in detail). --------8<---- eps2pdf.sh ---------- #!/bin/bash #debug #set -x if [ -z "$1" ] ; then echo "usage: $0 infile.eps [outfile.pdf] [papersize (default: a3)]" exit 1 fi if [ -z "$2" ] ; then pdfoutfile="$1".pdf else pdfoutfile="$2" fi if [ -z "$3" ] ; then dpapersize="a3" else dpapersize="$3" fi # the following all in one line gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dNOPAUSE -dQUIET -dBATCH -dSubsetFonts=true -dEmbedAllFonts=true -dPDFSETTINGS=/prepress -sPAPERSIZE="$dpapersize" -sOutputFile="$pdfoutfile" "$1" --------8<---- eps2pdf.sh ----------
This bug, reported in May 2011, is still alive and kicking in 4.0.0.3, any idea about an ETA for a fix? I just stumbled across this effect again producing handouts from an ODP file.
*** Bug 63852 has been marked as a duplicate of this bug. ***
Hi there, in LibreOffice Version 3.6.2.2 (Build ID: da8c1e6) I can still reproduce this annoying dots with some pdf readers. The dots seem to be in every shape that is not rectangular (See attached screen shot made from kpdf 0.5.9). Astonishingly, the moon shape has a dot on the upper right (and probably an indivisible one on the lower left). This can also be reproduced with the flip operation (see red boxes). In my case the dots also have the same color and the same size (!) as the line width setting of the object. They also only seem to appear with the line style continuous (see circles on the bottom). I hope this helps fixing this old and extremely annoying bug
Created attachment 79261 [details] Screenshotof dots in pdf export
I'm affected by this issue in all LibreOffice Versions. Surprise - the bug is still alive in V4.1 Beta 1 !!! The bug affects not only the PDF export, it is in the drawn objects itself: 1. Open Draw 2. Draw a circle IMPORTANT: You have to turn OFF antialiasing to see the two dots. 3. Now you can see two dots (upper left and lower right). You see, the dots are present in LibO already (and of course after export it to pdf. That the dots are really there you can do following: 4. Select the circle and convert it in a polygon. 5. Enter the dot edit mode Now you can see, you can edit, move and delete these dots. This is the evidence that these dots are physically there. Deleting these dots is a workaround if you need those objects. I believe these dots are in ALL predefined shapes, also in squares and rectangles. I found this dot-bug in LibO 3.3.4 - 4.1 beta 1 ApacheOpenOffice V3.4.1 and OpenOffice 3.2.0 are not affected by this bug!
*** Bug 65127 has been marked as a duplicate of this bug. ***
*** Bug 64100 has been marked as a duplicate of this bug. ***
*** Bug 65831 has been marked as a duplicate of this bug. ***
*** Bug 66460 has been marked as a duplicate of this bug. ***
*** Bug 66146 has been marked as a duplicate of this bug. ***
(In reply to comment #54) > I'm affected by this issue in all LibreOffice Versions. > Surprise - the bug is still alive in V4.1 Beta 1 !!! > > The bug affects not only the PDF export, it is in the drawn objects itself: > > 1. Open Draw > 2. Draw a circle > > IMPORTANT: You have to turn OFF antialiasing to see the two dots. > > 3. Now you can see two dots (upper left and lower right). > > ... snip ... > > This is the evidence that these dots are physically there. > Deleting these dots is a workaround if you need those objects. > I believe these dots are in ALL predefined shapes, also in squares and > rectangles. > > ... snip ... @Papamatti you are absolutely right. the problem is inside the predefined basic shapes. issue still present in 4.1.1.2 final release (tested under Windows) and in 4.2.0.0.alpha0+ Time: 2013-09-03_05:51:28. interestingly extra 1x1 pixels affect only basic shapes and symbols with dropdown lists. I mean, if you click the elipse from the basic shapes supgroup you got that extra pixel, while if you click the elipse single button it doesn't have such pixel.
Apologies for not having gotten around fixing this bug yet; unfortunately in future I'll have even less time at my disposal for this, so I'm freeing up ownership for other volunteers to take over.
Thank you very much for your email, unfortunatly I am out of office with irregular access to my emails until 17 September 2013. I will attend to your email on my return. best regards, Pascal
*** Bug 71021 has been marked as a duplicate of this bug. ***
Thank you very much for your email, unfortunatly I am out of office with irregular access to my emails until 2nd December 2013. I will attend to your email on my return. best regards, Pascal
*** Bug 73097 has been marked as a duplicate of this bug. ***
Thank you very much for your email, unfortunatly I am out of office with irregular access to my emails until 28th December 2013. I will attend to your email on my return. best regards, Pascal
Can someone clean up all those Attachments and create a simple test document called "test document" to test this against new LO version? Or does the drawing have to be created for the bug to appear? This bug is becoming somewhat messy. Also @all please turn of any auto-replies or use another mail address for bugzilla. It's pretty unpolite to clutter a bug tracker with useless auto-replies.
@Foss: The bug report is becoming messy, because quite a lot of users suffer from it and it has stayed unfixed for a long time.
@FOSS: You need no testdoc, just open draw, draw a circle, make the line thick enough and you see two dots (upper left and lower right). Unfortunately if you convert this shape into a polygon you can edit these dots also. So it is in fact a bug how LO handle these shapes. In OpenOffice 3.20 and before this bug isn't existent. It was indruduced in OpenOffice 3.3 during the fork of LO3.3. This Bug is fixed in AOO 3.4.1 and up so far as i know. And this bug is still existent in LO 4.2.0 RC1 !!!
Forget to mention that you have to turn antialiazing off in the options and you have to zoom in or out to see these dots. But you can print these dots, or export them to pdf and so on.
Created attachment 94426 [details] Test Document (ODG) Here you have the requested test document summarizing the bug...
Thank you very much for your email. I am no longer working at the BFH. Thus ,if your email concerns BFH please contact volker.koch@bfh.ch<mailto:volker.koch@bfh.ch>. If you are trying to reach me please forward your email to pascal@gaggero.ch<mailto:pascal@gaggero.ch> best regards, Pascal
Adjusting the earliest affected version to 3.3.0 (according to comment 54 and my own testing - already REPRODUCIBLE with 3.3.0.4 under Win7x64). Adjusting the component: this problem not only affect Draw, but also any other module capable of using shapes, connectors etc. Tested with Version 4.3.0.0.alpha0+ Build ID: 335a8a84fe6349fd716d4978346cfff9c884dd9b, both Writer and Calc produce PDFs with dots around smileys (although there seems to be no way to convert them to polygons). Not sure if "graphic stack" is a proper component, maybe should be more generic Libreoffice? Removing defunct CC address with autoreply robot on other side (expecting one more unwanted message). I have a proposition. What if we don't fix this, but simply call it feature: imagine the new LO logo having smiling face and those two (not so tiny) dots! '*_*,
Bump. The same problem exists in the release of LO 4.3.0.4 The mysterious dots (top left and lower right) are still there. Why are there these dots, which I can edit, delete, move? Is this the outboundary (offset, e.g. 0,0 and 20,20) of the rectangular area of the object, which will be mistakenly interpreted as part of the object and display them as dots on screen or convert/export them mistakenly as additional dots? You can simply reproduce them: - open LibreOffice Draw - draw a circle - convert the circle into a polygon - enter the dot edit mode (double click or button in the lower panel) - edit the dots (they are mostly invisible on screen, because of antialiasing, but they are there for sure!) You can now move them around, or delete them. In which source file are the releated code?
Further information in the thread http://lists.freedesktop.org/archives/libreoffice/2014-August/062931.html
Created attachment 108959 [details] pptx whose eyes are rendered differently if we revert the patch that adds the dots
Created attachment 108960 [details] this removes those dummy polygon docs, but the rendering of the previous example will change a little
Comment on attachment 47116 [details] two wrong pixels around object in PDF export I am also very annoyed of these dots as they do not only appear in PDF export, but also when printing the document(onto paper).
So these dots are in the current master build (Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-07-04_01:25:39) also and of course in LibreOffice 5.0 RC2. Will this bug ever be solved? ;-p
Created attachment 117041 [details] This pdf shows how you could see the bug easily and simply redo it yourself. This file has been created with LibO4.4.4 and saved as a hybrid-pdf, it can be opened in LO Draw. The screenshot is from current LO 5.1 master build (4.7.2015). The bug itself exists since LO3.3.0.
*** Bug 92555 has been marked as a duplicate of this bug. ***
just discovered this bug in 5.0.1.2 on Vista 32 home basic. Please please help fix it. If I had the knowledge I would help. Thank you, Four and a half years?...
you can help too starting a crowdfunding on https://freedomsponsors.org/
*** Bug 101111 has been marked as a duplicate of this bug. ***
The problem caused by following lines in EnhancedCustomShape2d.cxx: > if( !bLineGeometryNeededOnly ) > { > // hack aNewB2DPolyPolygon to fill logic rect - this is > // needed to produce gradient fills that look like mso > aNewB2DPolygon.clear(); > aNewB2DPolygon.append(basegfx::B2DPoint(0,0)); > aNewB2DPolygon.setClosed(true); > aNewB2DPolyPolygon.append(aNewB2DPolygon); > > aNewB2DPolygon.clear(); > aNewB2DPolygon.append(basegfx::B2DPoint(aLogicRect.GetWidth(), > aLogicRect.GetHeight())); > aNewB2DPolygon.setClosed(true); > aNewB2DPolyPolygon.append(aNewB2DPolygon); > } Disabling this codepath stops adding the points. Current AOO code doesn't contain these lines. This is added by: author Thorsten Behrens <tbehrens@novell.com> 2010-10-26 21:04:44 (GMT) committer Thorsten Behrens <tbehrens@novell.com> 2010-10-26 21:04:44 (GMT) commit f64ef72743e55389e446e0d4bc6febd475011023 tree 13dacfb392466476bbe647c74520fa1e4eb860af parent 5e1626f2cf40d4b52128d4464e838b8df0be55a7 > Better shading algo for customshapes, better gradients > Some custom shapes can have shaded parts, like for example 3d can, > the bevelled buttons etc. Those shaded colors are calculated > internally, and have been way off at times. Now using HSV color > space & the originally documented luminance modifications in steps > of 10 percent. Compared to MSO, still no 100 percent match, but > that seems due to gamma correction there. > Additionally, starting with MSO12, gradients on those shaded surfaces > look much better; adapted code to display gradients equally nice. > > Note that most of this patch also applies to ooxml import; note as > well that customshapes from *all* kind of input files (including ODF > docs) now look different than before; no real way of changing this > in a backward-compatible way, since behaviour of custom shapes is > mandated (mostly) by internal tables, and not stored in a file. > > Applies patches/dev300/ppt-customshape-shading-fix (much of it was > accepted at OOo already, via i#102797) > > Applies patches/dev300/ppt-customshape-shading-fix.diff: fixed prob > with line arrows - the extra-added single point polygons lead to > extra arrows randomly around the custom shape. i#105654 The problem isn't in PDF export, so removing filter:pdf keyword. To see it on screen, one needs to disable OpenGL and AntiAliasing in Tools->Options->LibreOffice->View. In older versions, one may look for AntiAliasing in Expert Configuration or in config files. The code was applied to OOo in i#102797, and was reverted later in i#105654. However, they still were reproducible in Linux distros before LO, possibly as part of GoOO (in 3.1 and 3.2 versions of OOo under SUSE and Ubuntu: see https://bz.apache.org/ooo/show_bug.cgi?id=108658 and https://bz.apache.org/ooo/show_bug.cgi?id=115511). The OOo issue didn't contain any clear specifications or test cases, only patches, neither are there any unit tests on this, so I cannot check if reverting this part of commit breaks something. A patch (that reverts these lines) is submitted for review: https://gerrit.libreoffice.org/35498. Thorsten, I added you as reviewer.
The patch mentioned in comment 85 is abandoned because of breakage of https://blog.thebehrens.net/2009/07/21/selected-interop-improvement-how-to-fill-ppt-autoshapes/. Reassigning to default as I haven't resources to work on this.
This bug has been around for more than 6 years. Actually present on v5.3.4.2 under Win10. Is there any estimate for a fix? Or at least a workaround?
If I export attachment 94426 [details] to PDF, I don't see the dots. Could someone confirm ? Version: 6.0.0.0.alpha0+ Build ID: cfbb8b5090537e79ba70e250ddee86d53facbe15 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
(In reply to Xisco Faulí from comment #88) I still see the dots at some zoom levels (e.g., 12,5%) in PDF viewer. Same as in LibreOffice itself...
The bug ist still in LO 6.0 Dev from 2017-10-19. I cannot see these dots, but if I convert a shape (e.g. a diamond) into a polygon you have two additional dots left top and right bottom. What for are these dots necessary?
(In reply to Papamatti from comment #90) > What for are these dots necessary? See comment 86.
(In reply to Xisco Faulí from comment #88) I did not play much with it, but yes, I cannot see the dots with LO 5.4.4.2 x64 on windows 10, viewing with Adobe. With a document of mine the dots are not visible at zoom > 75% if the default style line width is set bigger than 0.03 cm. With zoom < 75% the dots are visible. With default style line width 0.03cm or less, dots are visible at zoom 100%
Just tested 5.4.4.2 (x64) in Win 7 environment. Opening an "old" file, printing using FreePDF. Dots are still there, now short lines. Using direct PDF exporting still results in dots, but now tiny small. Klaus
Armin, seeing your last commits, can't they be ultimately applicable here (since the problem here is that the fill must use the same geometry for different paths, and the dots are created to define the fill geometry boundaries - see comment 85 and comment 86)?
(In reply to Mike Kaganski from comment #94) > Armin, seeing your last commits, can't they be ultimately applicable here? > Yep, that's the goal of that feature branch
Finally fixed by commits https://cgit.freedesktop.org/libreoffice/core/commit/?id=9886a69c472f212d88f11cfa0f3835e5dcf485b2 - https://cgit.freedesktop.org/libreoffice/core/commit/?id=8d107b8d3b33b16436fbe64a5e296ec5a2c69e5d (tellingly codenamed OperationSmiley :) ) Thank you Armin and Thorsten!
(In reply to Mike Kaganski from comment #96) > Finally fixed by commits > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=9886a69c472f212d88f11cfa0f3835e5dcf485b2 - > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=8d107b8d3b33b16436fbe64a5e296ec5a2c69e5d (tellingly codenamed > OperationSmiley :) ) > > Thank you Armin and Thorsten! Closing as RESOLVED FIXED then
This fix works for me, I'm so happy with this! Thank you very much!
(In reply to Papamatti from comment #98) > This fix works for me, I'm so happy with this! > > Thank you very much! Sorry for bothering, where can I download a version with fix for testing? I am not a software guy, cannot build my own ".exe".
(In reply to Klaus Müller from comment #99) > Sorry for bothering, where can I download a version with fix for testing? > I am not a software guy, cannot build my own ".exe". Daily builds for master can be downloaded from https://dev-builds.libreoffice.org/daily/master/ After a patch is applied you need to wait two days until it is visible in these builds.
(In reply to Regina Henschel from comment #100) > Daily builds for master can be downloaded from > https://dev-builds.libreoffice.org/daily/master/ > After a patch is applied you need to wait two days until it is visible in > these builds. Thank you for this link. Also many thanks for fixing the bug. Problem is also gone with my application using Win-x86_64@42/2018-03-21_02.51.57.
Created attachment 143829 [details] Faint pixels on the edges of each rounded rectangle Sadly, the bug is still there. Now the dots are very faint but can still be seen (have a look at the attached screenshot).
Copy&paste of "About LibreOffice": Version: 6.0.5.2 (x64) Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16 CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc:
(In reply to dr01 from comment #103) > Copy&paste of "About LibreOffice": > > Version: 6.0.5.2 (x64) > Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16 > CPU threads: 8; OS: Windows 10.0; UI render: default; > Locale: en-US (en_US); Calc: Hello dr01, this fix for this issue is only in 6.1.0 branch. Please, try with LibreOffice 6.1 RC2 from https://wiki.documentfoundation.org/QA/GetInvolved#Test_Pre-releases Setting back to RESOLVED FIXED
Thanks. It was unclear to me which version fixed the bug. I confirm that v6.1 RC2 works well.