Created attachment 106692 [details] sample doc Steps: 1) Open attached file 2) Notice that it is blank 3) Test same file in MS Word Tested in 4.4 master on Linux.
Created attachment 106693 [details] pdf export of the sample file in Word 2007
The author of the document stated that they created these hand writing objects using a Windows PC tablet with active digitizer pen, but that this could also be achieved with any touch screen using Word's pen tools.
tested under Win7x64 DocX reader 1.0 can read the file which is shown as blank in LibO 4.4.0.0+ master, 4.3.2.2 I tested older releases and I can tell that image looks almost fine in 3.6.6.2, then image starts disappearing in 3.6.7.2 and is definitively gone in 4.0.4.2 (I don't have early 4.0.x releases to test) here's the list of bugfixes in 3.6.7.2: https://wiki.documentfoundation.org/Releases/3.6.7/RC1 https://wiki.documentfoundation.org/Releases/3.6.7/RC2 maybe we can see something suspect that caused the regression
Created attachment 108136 [details] 3.6.6.2 vs 3.6.7.2 screenshot
Thanks for checking older versions as that didnt come to mind when i filed this one. Just assumed it never was able to render it. :)
bibisected: 3c257431da2650bf0d4ca7460af1b082c773816d is the first bad commit commit 3c257431da2650bf0d4ca7460af1b082c773816d Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed Nov 27 14:49:38 2013 +0000 source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d commit 1581b1fc3ac82a7bd62df968226e98604a4ca52d Author: Miklos Vajna <vmiklos@collabora.co.uk> AuthorDate: Mon Nov 25 17:24:39 2013 +0100 Commit: Miklos Vajna <vmiklos@collabora.co.uk> CommitDate: Mon Nov 25 17:32:36 2013 +0100 CppunitTest_sw_ooxmlexport: make it possible to use ..._TEST_ONLY with -Werror Change-Id: I451f81495a8e8535c8e0194198602ee5732164c6 :100644 100644 c290891590efa4fb28a6f86ef0cbe29a4b8baeff 8a8a92069ddd70a98210a44a33f652a4c3d06df4 M ccache.log :100644 100644 d0fcf4dc73a5a91def3e71fad9035807fbe84906 34c3ffcb2c754173b10dd0b1766dc5e2daecf91e M commitmsg :100644 100644 95386163339b3b232c8b0232a7d819ff40328f91 60671c4bff3b778b99dccbb9ca02b6d06a34b333 M make.log :040000 040000 8758436160d305aca069f7ba2a13436b30690d61 3a872c6b5794222bcd89d77b1ee2c7f6f75cac7d M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574 # bad: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b git bisect bad 4850941efe43ae800be5c76e1102ab80ac2c085d # skip: [a043626b542eb8314218d7439534dce2fc325304] source-hash-9379a922c07df3cdb7d567cc88dfaaa39ead3681 git bisect skip a043626b542eb8314218d7439534dce2fc325304 # skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6 # skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6 # good: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930 git bisect good c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31 # good: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930 git bisect good c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31 # bad: [30cde618212ecaf5725321372bd1b8339f8e2b9f] source-hash-137f872aa8e6e598e7c7ed1ffa4d21e580e22bdb git bisect bad 30cde618212ecaf5725321372bd1b8339f8e2b9f # bad: [30cde618212ecaf5725321372bd1b8339f8e2b9f] source-hash-137f872aa8e6e598e7c7ed1ffa4d21e580e22bdb git bisect bad 30cde618212ecaf5725321372bd1b8339f8e2b9f # good: [c8a5658505930ebcd7ac5bc6057a6f7204f4e1d3] source-hash-547750e8c2d001f92e3e303ebfda9b395538e741 git bisect good c8a5658505930ebcd7ac5bc6057a6f7204f4e1d3 # good: [c8a5658505930ebcd7ac5bc6057a6f7204f4e1d3] source-hash-547750e8c2d001f92e3e303ebfda9b395538e741 git bisect good c8a5658505930ebcd7ac5bc6057a6f7204f4e1d3 # good: [3f7dffadbdabcc8730fd19598afa9f5f70dca5b5] source-hash-2abcff25137c7c9af007554c97a4512319ec2e4d git bisect good 3f7dffadbdabcc8730fd19598afa9f5f70dca5b5 # good: [3f7dffadbdabcc8730fd19598afa9f5f70dca5b5] source-hash-2abcff25137c7c9af007554c97a4512319ec2e4d git bisect good 3f7dffadbdabcc8730fd19598afa9f5f70dca5b5 # bad: [641c999c8334a92273589d1a7931e8733fb265ef] source-hash-22029c7e17b4cb48acb058d47ec9c3b6b8b6b294 git bisect bad 641c999c8334a92273589d1a7931e8733fb265ef # bad: [641c999c8334a92273589d1a7931e8733fb265ef] source-hash-22029c7e17b4cb48acb058d47ec9c3b6b8b6b294 git bisect bad 641c999c8334a92273589d1a7931e8733fb265ef # good: [281e169052453119b46507f37bbb6cdebc45904c] source-hash-6ab3148d965be12592e8927b4c7868634e714932 git bisect good 281e169052453119b46507f37bbb6cdebc45904c # good: [281e169052453119b46507f37bbb6cdebc45904c] source-hash-6ab3148d965be12592e8927b4c7868634e714932 git bisect good 281e169052453119b46507f37bbb6cdebc45904c # bad: [3c257431da2650bf0d4ca7460af1b082c773816d] source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d git bisect bad 3c257431da2650bf0d4ca7460af1b082c773816d # first bad commit: [3c257431da2650bf0d4ca7460af1b082c773816d] source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d
The behaviour appears to have changed across the below two commits Adding Cc: to kendy@collabora.com. Could you possibly take a look at this? Thanks commit 9d3c0aa1e64ae97ddc305df3873f977051f0b317 Author: Jan Holesovsky <kendy@collabora.com> Date: Wed Nov 20 21:17:50 2013 +0100 Related fdo#61272: Revert "wmf-mm-text.diff: Fix WMF rendering, n#417818" This approach to WMF breaks EMF reading, need to revert it, and fix a different way. This reverts commit db1b08d217ebbdd1b0296e1da260bf314a77acf5. Conflicts: vcl/source/filter/wmf/winmtf.cxx vcl/source/filter/wmf/winmtf.hxx Change-Id: I8f779791153f2e1faa086c91b82b3e8b93304f3b commit 198b17dc5e182dfb2e5c930458764c7b3e6c914f Author: Jan Holesovsky <kendy@collabora.com> Date: Wed Nov 20 21:11:24 2013 +0100 Related fdo#61272: Revert "wmf-mm-text-1.diff: Fix WMF rendering, n#417818" This approach to WMF breaks EMF reading, need to revert it, and fix a different way. This reverts commit 16eaa5e7c1208034bb3244fea9e6d9491ccb5501. Conflicts: vcl/source/filter/wmf/winmtf.cxx Change-Id: I59076d0a65d91ba3a1f3ebb48d8f7a542859d351
The Beziers in some of the embedded EMFs have 12 points! That's just not possible, because the number of points must be: (number of curves x 3) + 1 As per the spec in [MS-EMF], see section 2.3.5.17. Whether that is the issue, I don't know. But it does tend to indicate some issues with the EMF file, however we should actually just detect this and ignore the extraneous points in the Bezier.
Oh, I see. After that record there is a close figure record. Good to know about this, because I'll quote what Microsoft say in their own documentation about MS-EMF: 2.3.5.17 EMR_POLYBEZIER16 Record Count (4 bytes): A 32-bit unsigned integer that specifies the total number of points. This value MUST be one more than three times the number of curves to be drawn, because each Bezier curve requires two control points and an endpoint, and the initial curve requires an additional starting point. They neglected to mention that if you have this close figure record directly after then it acts as the extra point they mentioned - you need to use the first point as the end-point.
Migrating Whiteboard tags to Keywords: (filter:docx, bibisected) Add Whiteboard tag 'filter:EMF'
Hi Chris, I'm setting this ticket back to NEW as it has been inactive for more than 3 months. Feel free to assign it back to you if you're still working on this. Regards
Adding Cc: Jan Holesovsky
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Repro 7.1+.
Created attachment 171957 [details] Extracted EMF image with wrong bezier curve
It is stated that when the attachment 106692 [details] is opened, it is is displayed as it would be blank. If we read all the comments, we see that there are actually 2 problems: 1. In some versions of LO, the shape does not display at all (blank display) + This problem seems to be fixed in the recent versions 2. In most versions of LO, the shape displays with some holes inside it (wrong display) + This problem still exists.
Created attachment 174119 [details] ink-sample.docx converted to PDF by LO 3.6.6.2
Created attachment 174120 [details] ink-sample.docx converted to PDF by LO 3.6.7.2
(In reply to tommy27 from comment #4) > Created attachment 108136 [details] > 3.6.6.2 vs 3.6.7.2 screenshot The "3.6.6.2 vs 3.6.7.2 screenshot" is misleading, because the display of shapes is nearly identical in both versions, when zooming in enough. Please look at attachment 174119 [details] and attachment 174120 [details], which are created using RPM versions of official LO binaries: https://downloadarchive.documentfoundation.org/libreoffice/old/3.6.6.2/rpm/x86_64/ https://downloadarchive.documentfoundation.org/libreoffice/old/3.6.7.2/rpm/x86_64/
(In reply to Xisco Faulí from comment #6) > bibisected: This bibisect is not useful, because there is no commit-by-commit bisect repository for LibreOffice 3. Also, it is not obvious what symptom is actually the subject of this bibisect.
(In reply to Hossein from comment #16) > there are actually 2 problems: > > 1. In some versions of LO, the shape does not display at all (blank display) > + This problem seems to be fixed in the recent versions > > 2. In most versions of LO, the shape displays with some holes inside it > (wrong display) > + This problem still exists. I've created minimal examples out of attachment 106692 [details], and it seems that the second problem is actually the lack of SetPolyfilMode implementation. There are 2 modes for PolygonFillMode: Alternate = 1 Winding = 2 First one is implemented, and the second one is ignored. So, the remaining problem is actually tdf#142021
(In reply to Hossein from comment #20) > (In reply to Xisco Faulí from comment #6) > > bibisected: > > This bibisect is not useful, because there is no commit-by-commit bisect > repository for LibreOffice 3. Also, it is not obvious what symptom is > actually the subject of this bibisect. the issue was introduced in this range: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=6ab3148d965be12592e8927b4c7868634e714932..1581b1fc3ac82a7bd62df968226e98604a4ca52d
(In reply to Xisco Faulí from comment #22) > (In reply to Hossein from comment #20) > > (In reply to Xisco Faulí from comment #6) > > > bibisected: > > > > This bibisect is not useful, because there is no commit-by-commit bisect > > repository for LibreOffice 3. Also, it is not obvious what symptom is > > actually the subject of this bibisect. > > the issue was introduced in this range: > https://cgit.freedesktop.org/libreoffice/core/log/ > ?qt=range&q=6ab3148d965be12592e8927b4c7868634e714932.. > 1581b1fc3ac82a7bd62df968226e98604a4ca52d Commits from Jan Holesovsky in the range look related
> (In reply to Hossein from comment #16) > > > there are actually 2 problems: > > > > 1. In some versions of LO, the shape does not display at all (blank display) > > + This problem seems to be fixed in the recent versions > > > > 2. In most versions of LO, the shape displays with some holes inside it > > (wrong display) > > + This problem still exists. > I've created minimal examples out of attachment 106692 [details], and it > seems that the second problem is actually the lack of SetPolyfilMode > implementation. There are 2 modes for PolygonFillMode: > > Alternate = 1 > Winding = 2 > > First one is implemented, and the second one is ignored. > > So, the remaining problem is actually tdf#142021 The first problem is fixed now, and the source of the 2nd problem is known: lacking in EMF feature SetPolyfilMode in import/export/display, and it is not a regression. I'm working on it, and I hope I can fix it soon. The problem is more clearly discussed in tdf#142021. Xisco, Do you want to call this a duplicate, or mark this one as resolved (no longer blank display), and continue work on tdf#142021?
Created attachment 174225 [details] Minimal EMF image on which the issue is visible
Created attachment 174226 [details] Minimal EMF image exported to PNG via Paint
Created attachment 174227 [details] Minimal EMF image without SetPolyfillMode record
Created attachment 174228 [details] Minimal EMF image without SetPolyfillMode record exported to PNG by Paint
The record responsible for drawing is EMR_FILLPATH: https://github.com/LibreOffice/core/blob/master/emfio/source/reader/emfreader.cxx#L1430 and https://github.com/LibreOffice/core/blob/master/emfio/source/reader/mtftools.cxx#L1310 which is using DrawPolyPolygon method to draw the polygons https://github.com/LibreOffice/core/blob/master/vcl/source/outdev/polygon.cxx#L36 @Hossein Did you find which Primitive should be used for control of Filling mode?
Created attachment 174258 [details] Minimal EMF file containing two circles overlapped, one is the result of saving another in LO Draw @Bartosz Thank you for uploading the minimal examples. My minimal examples were mostly similar to what you've created, but at last I removed everything and kept only one circle. Other than that, I saved an EMF with LibreOffice, then opened the original and the changed file in Inkscape, and then put both of them at the exact same position. In this way, I could see the differences, that was 1-2 pixel in positions, and then I found the difference in SetPolyfillMode. It is currently ignored by LO. You can check for yourself by invoking 'printemf minimal5-mix.emf', and see the differences. https://github.com/LibreOffice/core/blob/master/emfio/source/reader/emfreader.cxx#L1033 case EMR_SETPOLYFILLMODE : break;
(In reply to Bartosz from comment #29) > The record responsible for drawing is EMR_FILLPATH: > https://github.com/LibreOffice/core/blob/master/emfio/source/reader/ > emfreader.cxx#L1430 > and > https://github.com/LibreOffice/core/blob/master/emfio/source/reader/mtftools. > cxx#L1310 > > which is using DrawPolyPolygon method to draw the polygons > https://github.com/LibreOffice/core/blob/master/vcl/source/outdev/polygon. > cxx#L36 > > @Hossein Did you find which Primitive should be used for control of Filling > mode? To make sure that the problem is the SetPolyfillMode, I temporarily changed the fill mode in the Cairo back-end, and the problem went away: There was no hole in the handwriting anymore. Check it for yourself: Look at SvpSalGraphics::getCairoContext(), and change this: cairo_set_fill_rule(cr, CAIRO_FILL_RULE_EVEN_ODD); to this one: cairo_set_fill_rule(cr, CAIRO_FILL_RULE_WINDING); Yes, the DrawPolyPolygon method is doing most of the rendering of the handwriting shapes here. I am working on a patch to fix the problem. My approach to fix this bug is to understand what svgio does for the FillRule (comparable to FillMode here) and re-create it in emfio. I am uploading a WIP patch to Gerrit soon.
Nice catch Hossein! It seems that FillRule could be set by using SvtGraphicFill: https://git.libreoffice.org/core/+blame/master/emfio/source/reader/mtftools.cxx#1589 It could be done through constructor: https://git.libreoffice.org/core/+blame/master/include/vcl/graphictools.hxx#203 SvtGraphicFill( const tools::PolyPolygon& rPath, Color aFillColor, double fTransparency, FillRule aFillRule, FillType aFillType, // TODO: Multitexturing const Transform& aFillTransform, bool bTiling, HatchType aHatchType, // TODO: vector of directions and start points Color aHatchColor, GradientType aGradientType, // TODO: Transparent gradients (orthogonal to normal ones) Color aGradient1stColor, // TODO: vector of colors and offsets Color aGradient2ndColor, sal_Int32 aGradientStepCount, // numbers of steps to render the gradient. gradientStepsInfinite means infinitely many. const Graphic& aFillGraphic );
The ongoing Changes during review: https://gerrit.libreoffice.org/c/core/+/120477
*** Bug 138147 has been marked as a duplicate of this bug. ***
*** Bug 142021 has been marked as a duplicate of this bug. ***