[Upstream] Draw file exported to PDF have erroneous pixel-sized dots in Acroread, not in Evince

[Peter Frühberger]

Binary package hint: openoffice.org
Binary package hint: libreoffice

1) lsb_release -rd
Description: Ubuntu 12.10
Release: 12.10

2) apt-cache policy libreoffice-draw
libreoffice-draw:
  Installed: 1:3.6.2~rc2-0ubuntu4
  Candidate: 1:3.6.2~rc2-0ubuntu4
  Version table:
 *** 1:3.6.2~rc2-0ubuntu4 0
        900 http://archive.ubuntu.com/ubuntu/ quantal-updates/main i386 Packages
        400 http://archive.ubuntu.com/ubuntu/ quantal-proposed/main i386 Packages
        100 /var/lib/dpkg/status
     1:3.6.2~rc2-0ubuntu3 0
        500 http://archive.ubuntu.com/ubuntu/ quantal/main i386 Packages

apt-cache policy acroread
acroread:
  Installed: 9.5.1-1precise1
  Candidate: 9.5.1-1precise1
  Version table:
 *** 9.5.1-1precise1 0
        100 /var/lib/dpkg/status

apt-cache policy evince
evince:
  Installed: 3.6.0-0ubuntu2
  Candidate: 3.6.0-0ubuntu2
  Version table:
 *** 3.6.0-0ubuntu2 0
        500 http://archive.ubuntu.com/ubuntu/ quantal/main i386 Packages
        100 /var/lib/dpkg/status

3) What is expected to happen is when one performs at the Terminal:
cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/689349/+attachment/1763870/+files/classnetwork.odg && unoconv --listener && unoconv -f pdf classnetwork.odg && acroread classnetwork.pdf

is it looks as it does in Evince.

4) What happens instead is acroread displays erroneous pixel-sized dots as per screenshot https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/689349/+attachment/1763844/+files/garbagescreenshot.png , while evince does not.

First reproduced in Maverick 1:3.3.1-1ubuntu3~maverick1, and reproduced in Natty, and Precise.

Unconfirmed OOo WORKAROUND: The upstream version does _not_ produce these effects and is fine.

ApportVersion: 2.6.1-0ubuntu6
Architecture: i386
CheckboxSubmission: 30b6638832e19720cfe8f7a91e5798a4
CheckboxSystem: 2954e74ba17fb0e37fc942cd1d9fab4e
DistroRelease: Ubuntu 12.10
InstallationDate: Installed on 2012-06-11 (164 days ago)
InstallationMedia: Xubuntu 12.04 "Precise Pangolin" - Alpha i386 (20120131.1)
MarkForUpload: True
Package: libreoffice 1:3.6.2~rc2-0ubuntu4
PackageArchitecture: i386
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Tags: quantal
Uname: Linux 3.5.0-17-generic i686
UpgradeStatus: Upgraded to quantal on 2012-09-14 (68 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

[penalvch (penalvch)]

Peter Frühberger, thank you for reporting this bug and helping make Ubuntu better. This is reproducible in Ubuntu 10.10, LibreOffice Draw at the Terminal:

cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/689349/+attachment/1763870/+files/classnetwork.odg && lodraw -nologo classnetwork.odg

File -> Export as PDF -> Save button

Open in Adobe Reader and notice the dots. Open in Evince, no dots.

lsb_release -rd
Description: Ubuntu 10.10
Release: 10.10

apt-cache policy libreoffice-draw
libreoffice-draw:
  Installed: 1:3.3.0-1maverick1
  Candidate: 1:3.3.0-1maverick1
  Version table:
 *** 1:3.3.0-1maverick1 0
        500 http://ppa.launchpad.net/libreoffice/ppa/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status

 apt-cache policy acroread
acroread:
  Installed: 9.4.1-1maverick1
  Candidate: 9.4.1-1maverick1
  Version table:
 *** 9.4.1-1maverick1 0
        500 http://archive.canonical.com/ubuntu/ maverick/partner i386 Packages
        100 /var/lib/dpkg/status

apt-cache policy evince
evince:
  Installed: 2.32.0-0ubuntu1.1
  Candidate: 2.32.0-0ubuntu1.1
  Version table:
 *** 2.32.0-0ubuntu1.1 0
        500 http://us.archive.ubuntu.com/ubuntu/ maverick-updates/main i386 Packages
        500 http://security.ubuntu.com/ubuntu/ maverick-security/main i386 Packages
        100 /var/lib/dpkg/status
     2.32.0-0ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ maverick/main i386 Packages

[penalvch (penalvch)]

Peter Frühberger, please execute the following command, as it will automatically gather debugging information, in a terminal:
apport-collect 689349
When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

[penalvch (penalvch)]

Peter Frühberger, since this bug has enough information provided for a developer to begin work, I'm going to mark it as Triaged and let them handle it from here. Thanks for taking the time to make Ubuntu better!

[Lars Knickrehm (lars-sh)]

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.

[Jbf-faure-9 (jbf-faure-9)]

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.

[Vitriol-vitriol (vitriol-vitriol)]

(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.

[Vitriol-vitriol (vitriol-vitriol)]

Created attachment 47116
two wrong pixels around object in PDF export

[Libreoffice-z (libreoffice-z)]

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.

[Vitriol-vitriol (vitriol-vitriol)]

Perfectly visible for me. Viewers Foxit Reader and PDF-XChange, LibO 3.4 RC1 under Win7 64 bit.
I attach a PDF.

[Vitriol-vitriol (vitriol-vitriol)]

Created attachment 47120
PDF samle

[Libreoffice-z (libreoffice-z)]

Foxit reader reminds me to
"Bug 31851 - Artifacts (vertical short lines) in PDF-Export" (I never again heard from Foxit).

[Lars Knickrehm (lars-sh)]

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.

[Vitriol-vitriol (vitriol-vitriol)]

(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.

[Fyvaao (fyvaao)]

(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.

[Fyvaao (fyvaao)]

Created attachment 47147
Smiley converted to curve in Points mode

[Libreoffice-z (libreoffice-z)]

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!

[Libreoffice-z (libreoffice-z)]

*** Bug 31851 has been marked as a duplicate of this bug. ***

[Fyvaao (fyvaao)]

@Rainer Bielefeld: I think Thorsten could know this area.

[penalvch (penalvch)]

*** This bug has been marked as a duplicate of bug 34990 ***

[Libreoffice-z (libreoffice-z)]

*** Bug 34990 has been marked as a duplicate of this bug. ***

[penalvch (penalvch)]

Created attachment 48303
classnetwork.odg

.odg attachment from dup https://bugs.freedesktop.org/show_bug.cgi?id=34990

[penalvch (penalvch)]

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

[jperl (johannes-perl)]

Did anybody find a workaround for this issue? I can confirm the bug for latest version of libreoffice in 11.04 from ppa (1:3.3.2-1ubuntu6~ppa1 ).
The same problem arises when creating an .eps figure, which is included into a latex document. This is due to latex converting the .eps to a .pdf file then containing the pixel-sized dots.

[Libreoffice-z (libreoffice-z)]

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 <email address hidden>, because also visible in Presentation.

@Thorsten:
Please feel free to reassign if you do not want to be the assignee.

[Tbehrens (tbehrens)]

Created attachment 50259
pdf sample, fixed version

Should be fixed on master, could someone with a susceptible viewer please try this attachment?

[Vitriol-vitriol (vitriol-vitriol)]

(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...

[Vitriol-vitriol (vitriol-vitriol)]

Created attachment 50260
Screenshot of test.pdf

[Tbehrens (tbehrens)]

ok, thanks for checking. let me get one of those viewers then, here.

[Lars Knickrehm (lars-sh)]

I still see that dot:

latest Adobe Reader release on German Windows 7 Home Premium 32bit

[Libreoffice-z (libreoffice-z)]

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

[Vitriol-vitriol (vitriol-vitriol)]

(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.

[Libreoffice-z (libreoffice-z)]

@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?

[Tbehrens (tbehrens)]

(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.

[Björn Michaelsen (bjoern-michaelsen)]

[This is an automated message.]
There are no new official OpenOffice.org releases in Ubuntu packaging anymore => Won't Fix

If the problem persists, please mark this bug as "also affects project Libreoffice" or "also affects distribution Libreoffice (Ubuntu)" if that has not happened already.

Please leave references to upstream OpenOffice.org bugs in place to allow cross pollination.

[penalvch (penalvch)]

Manuel López-Ibáñez (manuellopezibanez), please do not edit this bug. It already has enough information to deal with the bug and is reported upstream.

[Manuel López-Ibáñez (manuellopezibanez)]

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.

LibreOffice 3.3.4
OOO330m19 (Build:401)
tag libreoffice-3.3.3.1, Ubuntu package 1:3.3.4-0ubuntu1

[Manuel López-Ibáñez (manuellopezibanez)]

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

[Libreoffice-z (libreoffice-z)]

I believe I added Target:3.5 accidently, but we really should get rid of those ugly sly shit dots ;-)

[Libreoffice-z (libreoffice-z)]

fly shit - of course

[Vitriol-vitriol (vitriol-vitriol)]

*** Bug 46820 has been marked as a duplicate of this bug. ***

[Jonas Diemer (diemer)]

I can confirm that the issue still persists in LO 3.4.3, see Bug 46820.

[Vitriol-vitriol (vitriol-vitriol)]

*** Bug 49090 has been marked as a duplicate of this bug. ***

[Libreoffice-z (libreoffice-z)]

*** Bug 48163 has been marked as a duplicate of this bug. ***

[Johannes-sixt (johannes-sixt)]

Created attachment 63511
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.

[Marcelo Guedes (marcelo-guedes)]

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 =/

[penalvch (penalvch)]

Guedes, please do not toggle the version. For more on this please see http://wiki.documentfoundation.org/BugReport_Details#Version .

[Marcelo Guedes (marcelo-guedes)]

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.

[Marcelo Guedes (marcelo-guedes)]

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 .

[Martin Weis (martin-weis-newsadress)]

Created attachment 65060
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

[Martin Weis (martin-weis-newsadress)]

(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

[Martin Weis (martin-weis-newsadress)]

(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

[Vitriol-vitriol (vitriol-vitriol)]

*** Bug 53836 has been marked as a duplicate of this bug. ***

[572cbd7a8424 (572cbd7a8424)]

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.

[572cbd7a8424 (572cbd7a8424)]

Created attachment 67513
Screenshot from okular displaying a rounded rectangle with shadow exported to PDF

[Valentin Zauner (darkdragon84)]

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

[penalvch (penalvch)]

apport information

[Valentin Zauner (darkdragon84)]

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!

[Martin Weis (martin-weis-newsadress)]

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.

[Martin Weis (martin-weis-newsadress)]

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 ----------

[David Leoni (davidleoni-it)]

I incurred into the same problem while working with Kile.

 I modified Martin Weis script to process all the eps files in the directory and to add the suffix -eps-converted-to.pdf by default in generated pdfs , as Kile with the QuickBuild will be looking for those ones. Also it automatically crops files with pdfcrop, at least for my paper it worked fine with no strange parameters.

 Still needs the awk file, see https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/689349/comments/63

--------8<---- eps2pdf.sh ----------

#!/bin/bash

echo "Usage:"
echo
echo "eps2pdf [suffix] [dpapersize]"
echo
echo "Converts all the eps files in the directory. By default, for fname.eps it outputs fname-eps-converted-to.pdf, (which is the suffix looked for by Kile), otherwise fname[suffix].pdf"

if (shopt -s failglob; true *.eps) 2>/dev/null; then
    echo "Found files"
else
 echo
 echo
 echo "ERROR: no .eps found!"
 exit 1
fi

#debug
#set -x

if [ -z "$1" ] ; then
 suffix="-eps-converted-to"
else
 suffix="$1"
fi

if [ -z "$2" ] ; then
 dpapersize="a3"
else
 dpapersize="$2"
fi

for f in *.eps
 do
 echo
 echo "**** Processing $f file..."
 # take action on each file. $f store current file name
 #cat $f

 nf=${f::${#f}-4}

 #if [ -z "$1" ] ; then
 #echo "usage: $0 infile [outfile.pdf] [papersize (default: a3)]"
 #exit 1
 #fi

 pdfoutfile1="$nf-no-dots.pdf"

# if [ -z "$2" ] ; then
# pdfoutfile1="$1-no-dots.pdf"
# else
# pdfoutfile1="$2"
# fi

 nodotseps="$nf-no-dots.eps"

 ./fixodg2pdf.awk $nf.eps > $nodotseps

 # the following all in one line
 gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dNOPAUSE -dQUIET -dBATCH -dSubsetFonts=true -dEmbedAllFonts=true -dPDFSETTINGS=/prepress -sPAPERSIZE="$dpapersize" -sOutputFile="$pdfoutfile1" "$nodotseps"

 rm $nodotseps

 pdfoutfilecropped="$nf$suffix.pdf"

 pdfcrop $pdfoutfile1 $pdfoutfilecropped
 rm $pdfoutfile1

done

--------8<---- eps2pdf.sh ----------

[Stephan-petersen (stephan-petersen)]

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.

[Sven Goossens (sgoossens)]

The bug still exists on Version 3.6.2.2 (Build ID: 360m1(Build:2))
The dots are ALSO visible the editor if anti-aliasing is switched off. (Tools->Options->LibreOffice->view->untick "Use anti-aliasing"
I guess this means it is not the export mechanism that is broken, but instead something else causes the issue.

[Sven Goossens (sgoossens)]

This time running "Version 4.0.2.1 (Build ID: 400m0(Build:1))" in Ubuntu 12.10

[Vitriol-vitriol (vitriol-vitriol)]

*** Bug 63852 has been marked as a duplicate of this bug. ***

[Bugs-6 (bugs-6)]

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

[Bugs-6 (bugs-6)]

Created attachment 79261
Screenshotof dots in pdf export

[CassieMoondust (cassie-lx)]

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!

[CassieMoondust (cassie-lx)]

*** Bug 65127 has been marked as a duplicate of this bug. ***

[CassieMoondust (cassie-lx)]

*** Bug 64100 has been marked as a duplicate of this bug. ***

[Vitriol-vitriol (vitriol-vitriol)]

*** Bug 65831 has been marked as a duplicate of this bug. ***

[CassieMoondust (cassie-lx)]

*** Bug 66460 has been marked as a duplicate of this bug. ***

[CassieMoondust (cassie-lx)]

*** Bug 66146 has been marked as a duplicate of this bug. ***

[Barta-c (barta-c)]

(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.

[Tbehrens-u (tbehrens-u)]

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.

[Pascal-gaggero (pascal-gaggero)]

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

[Barta-c (barta-c)]

*** Bug 71021 has been marked as a duplicate of this bug. ***

[Pascal-gaggero (pascal-gaggero)]

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

[Stgohi-lobugs (stgohi-lobugs)]

*** Bug 73097 has been marked as a duplicate of this bug. ***

[Pascal-gaggero (pascal-gaggero)]

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

[Foss-4 (foss-4)]

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.

[Clemens Eisserer (linuxhippy)]

@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.

[CassieMoondust (cassie-lx)]

@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 !!!

[CassieMoondust (cassie-lx)]

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.

[Pafal (pafal)]

Created attachment 94426
Test Document (ODG)

Here you have the requested test document summarizing the bug...

[Pascal-gaggero (pascal-gaggero)]

Thank you very much for your email.

I am no longer working at the BFH. Thus ,if your email concerns BFH please contact <email address hidden><mailto:<email address hidden>>.

If you are trying to reach me please forward your email to <email address hidden><mailto:<email address hidden>>

best regards,

Pascal

[Mikekaganski (mikekaganski)]

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!

'*_*,

[[e-mail] (julius-fingerle)]

The awk script posted above will remove the 'filling' from all circles. I altered the script so the lines are not removed anymore:

---8<---fixodg2pdf.awk--------
#!/usr/bin/awk -f

# ignore points (pc?) with the lr/ul corner being the same
{if (($1==$4) && ($2==$5) && ($8 != "ef"))
        {next;}
}
{print}
---8<-------------------------

Original post: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/689349/comments/63

[CassieMoondust (cassie-lx)]

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?

[Rb-henschel (rb-henschel)]

Further information in the thread http://lists.freedesktop.org/archives/libreoffice/2014-August/062931.html

[Caolanm (caolanm)]

Created attachment 108959
pptx whose eyes are rendered differently if we revert the patch that adds the dots

[Caolanm (caolanm)]

Created attachment 108960
this removes those dummy polygon docs, but the rendering of the previous example will change a little

[Sven Goossens (sgoossens)]

In case you are a happy user of the workaround proposed by these comments:

https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/689349/comments/63
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/689349/comments/92

I've modified the awk script to ignore some false positives:

#!/usr/bin/awk -f

# ignore points (pc?) with the lr/ul corner being the same
{if (($1==$4) && ($2==$5) && ($8 != "ef") && ($3 == "m") && ($6 == "l") && ($13 != "ct"))
        {next;}
}
{print}

Newest version will be here if I make more changes:
https://github.com/Sv3n/odg2epsfix

[Libreoffice-g (libreoffice-g)]

Comment on attachment 47116
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).

[CassieMoondust (cassie-lx)]

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

[CassieMoondust (cassie-lx)]

Created attachment 117041
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.

[Rb-henschel (rb-henschel)]

*** Bug 92555 has been marked as a duplicate of this bug. ***

[Caver456 (caver456)]

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?...

[Barta-c (barta-c)]

you can help too starting a crowdfunding on https://freedomsponsors.org/

[Thb-b (thb-b)]

*** Bug 101111 has been marked as a duplicate of this bug. ***

[Mikekaganski (mikekaganski)]

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 <email address hidden> 2010-10-26 21:04:44 (GMT)
committer Thorsten Behrens <email address hidden> 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 (th...

[Mikekaganski (mikekaganski)]

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.

[Daniele-raffo (daniele-raffo)]

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?

[Xiscofauli (xiscofauli)]

If I export attachment 94426 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

[Mikekaganski (mikekaganski)]

(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...

[CassieMoondust (cassie-lx)]

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?

[Mikekaganski (mikekaganski)]

(In reply to Papamatti from comment #90)
> What for are these dots necessary?

See comment 86.

[K-bruno (k-bruno)]

(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%

[Libreoffice-g (libreoffice-g)]

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

[Mikekaganski (mikekaganski)]

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)?

[Thb-b (thb-b)]

(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

[Mikekaganski (mikekaganski)]

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!

[Xiscofauli (xiscofauli)]

(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

[CassieMoondust (cassie-lx)]

This fix works for me, I'm so happy with this!

Thank you very much!

[Libreoffice-g (libreoffice-g)]

(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".

[Rb-henschel (rb-henschel)]

(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.

[Libreoffice-g (libreoffice-g)]

(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.

[penalvch (penalvch)]

Confirmed fixed in Bionic.