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

Bug #689349 reported by Peter Frühberger on 2010-12-12
50
This bug affects 10 people
Affects Status Importance Assigned to Milestone
libreoffice (Ubuntu)
Medium
Unassigned
openoffice.org (Ubuntu)
Undecided
Unassigned

Bug Description

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

description: updated

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

tags: added: lo33
summary: - Circles and Elliptic Shapes get red extra dots when exporting to pdf
+ Draw file exported to PDF have erroneous red dots in Acroread, not in
+ Evince

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.

description: updated
Changed in openoffice.org (Ubuntu):
status: New → Incomplete
Changed in df-libreoffice:
importance: Unknown → Low
status: Unknown → Confirmed
summary: - Draw file exported to PDF have erroneous red dots in Acroread, not in
- Evince
+ Draw file exported to PDF have erroneous pixel-sized dots in Acroread,
+ not in Evince
description: updated

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!

description: updated
Changed in libreoffice (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
summary: - Draw file exported to PDF have erroneous pixel-sized dots in Acroread,
- not in Evince
+ [Upstream] Draw file exported to PDF have erroneous pixel-sized dots in
+ Acroread, not in Evince
2 comments hidden view all 122 comments

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

Changed in df-libreoffice:
status: Confirmed → Invalid
Changed in df-libreoffice:
importance: Low → Unknown
status: Invalid → Unknown
Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Confirmed
19 comments hidden view all 122 comments
jperl (johannes-perl) wrote :

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.

20 comments hidden view all 122 comments

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.

Changed in df-libreoffice:
status: Confirmed → In Progress

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

Changed in df-libreoffice:
status: In Progress → Confirmed

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.

Changed in openoffice.org (Ubuntu):
status: Incomplete → Won't Fix
28 comments hidden view all 122 comments

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

summary: [Upstream] Draw file exported to PDF have erroneous pixel-sized dots in
- Acroread, not in Evince
+ Acroread and Okular, not in Evince
29 comments hidden view all 122 comments

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.

summary: [Upstream] Draw file exported to PDF have erroneous pixel-sized dots in
- Acroread and Okular, not in Evince
+ Acroread, not in Evince

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

tags: added: maverick natty precise quantal
description: updated
tags: added: i386
tags: added: apport-collected
description: updated
42 comments hidden view all 122 comments

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

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!

'*_*,

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

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?

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

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

Sven Goossens (sgoossens) wrote :

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

1 comments hidden view all 122 comments

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

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

Download full text (3.2 KiB)

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

Read more...

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

(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

Changed in df-libreoffice:
status: Confirmed → Fix Released

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.

23 comments hidden view all 122 comments

Confirmed fixed in Bionic.

Changed in libreoffice (Ubuntu):
status: Triaged → Fix Released
no longer affects: df-libreoffice
Displaying first 40 and last 40 comments. View all 122 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.