Created attachment 49137 [details]
Example file for issues #5 and #6
Below is a list of issues found in LibO WMF importer.
1. Hatches are ignored in CreateBrushIndirect record.
(Check "188.8.131.52 Brush Object" of [MS-WMF] document, HatchStyle enum should be used only if BrushStyle is BS_HATCHED)
2. CreateDIBPatternBrush doesn't seem to be implemented
3. SetBKColor seem to be misinterpreted as Fill (Brush) color
4. SetBKMode seems to be ignored (see "184.108.40.206 META_SETBKMODE Record" and "220.127.116.11 MixMode Enumeration"). Probably it's an effect of ignored hatches.
5. CreateFontInderect -- Escapement and Orientation each treated as Escapement . The middle row in a matrix should not be rotated. For GM_ADVANCED mode each symbol in that row could be rotated individually, MS Office 2007 doesn't rotate it at all.
6. MS "Symbol" encoding and/or "MT Extra" fonts are not converted.
(matrix braces symbols should be translated from non-standard encoding/font to UTF).
7. Caps/Join seems to be ignored in CreatePenIndirect.
8. SetPolyfillMode Mode 2 -- "winding" ("18.104.22.168 META_SETPOLYFILLMODE Record" and "22.214.171.124 PolyFillMode Enumeration") seems to be ignored.
Also compare "ppgfm2.wmf" and "ppg.wmf" (the difference is record #10 in "ppgfm2.wmf")
9. Pen width seems to be ignored for PolyPolygon.
Created attachment 49138 [details]
Example file for issue #7
Created attachment 49139 [details]
Example file for issues #1 to #4
(from libwmf test files)
Created attachment 49141 [details]
Example file for issue #8 and #9
(default SetPolyfillMode, it matches with LibO defaults => works fine)
Created attachment 49142 [details]
Example file for issue #8 and #9
(SetPolyfillMode to 'winding', it doesn't match with LibO defaults => incorrect result)
Created attachment 49143 [details]
How "capjoin.wmf" should look like
Created attachment 49144 [details]
How "ppgpfm2.wmf" should look like
Created attachment 49145 [details]
How "1p0000001.wmf" looks like in MS Office
For compatibility with MSO it's probably better to ignore Orientation value.
Created attachment 49146 [details]
How "fulltest.wmf" should look like
Created attachment 49147 [details]
Hatch patterns at different zoom level, to verify how it should work
I do not see a good chance that someone will find the time to check your observations, it's simply too painful to find through. I will not try to find out what you might have seen however using your sample documents with unknown LibO versions and OS and how it might have looked with an other application and what .png might be the corresponding one ...
May I ask you to read hints on <http://wiki.documentfoundation.org/BugReport> carefully?
- Create separate reports for each problem
- Attach a sample document (not only screenshot) demonstrating the problem
- Attachscreenshots with comments (you can add information using LibO DRAW
and then attach your screenshot with comments as PDF) if necessary.
These screenshots should compare your result with LibO and an other program
in 1 document, you see in tester8's document in Bug "38580 - EMF/EMF+ file:
import issue" how that can be done
- Contribute a step by step instruction containing every key press and every
mouse click how to reproduce your problem
- add information
-- what exactly is unexpected (The visible effect and the expected root
-- and why do you believe it's unexpected
-- concerning your PC (especially: video card)
-- concerning your OS
-- concerning your LibO version and localization (UI language)
–- Libo settings that might be related to your problems
(video hardware acceleration ...)
-- how you launch LibO and how you opened the sample document
–- If you can contribute an OOo Issue that might be useful
-- everything else crossing your mind after you read a.m. URL
Can you please file Bug reports with status UNCONFIRMED if your are not absolutely sure that you contributed all required background information and that the problem will be reproducible with information you can provide?
2 Rainer Bielefeld
Thank you for your valuable comment.
I guess you are the person who would fix those issues if bugs were submitted as you described.
Unfortunately I had a wrong assumption, that the only person who _probably_ will work on that is Radek Doulik. That's why I discussed with him on IRC how he prefers this to be reported: one bug per visual discrepancy, one per WMF record, one per test file or all in one. Anyway, I shouldn't make it as he told, right? "Ask and ignore the answer!", sounds as a good idea!
You are also absolutely right about LibO version...
I should NOT assume that
- if those issues were here 4 years ago (when I filed a bug for OO.o something.something version),
- if it's still here in 3.3.something,
- and there was no changes in WMF code recently,
when it's "ANY" version.
How could I know and claim that it's not fixed automagically in the git HEAD...
And you know what... I agree with you about "an other application". How could one guess, what is the application for compatibility with which LibO needs improvements in WMF support? It could be Borland Paradox, Apache or OpenVMS...
Sorry by mistake I put something misleading in the comment #7 and (oh. sh...) in description to issue #5 ...
Now for other lines in "Then please:"
> - Attach a sample document (not only screenshot) demonstrating the problem
Oh... LibO saves screenshots in WMF format, I didn't know that.
Great feature by the way... Does it vectorize content by tracing it?
Is it good enough to vectorize photos of my friends to cut stamps on plotter
as xmas presents?
>- Attachscreenshots with comments (you can add information using LibO DRAW
You are mostly right. I described which WMF records have what types of issues.
Attachments were not needed at all. They actually distract attention from the problem. Of course you know what WMF records are and what they do, so instead of puzzling with images to figure out what is different and why, you can go directly to fix mentioned record's implementations!
Will take it into account.
>- Contribute a step by step instruction containing every key press and every
> mouse click how to reproduce your problem
Err.. I thought that whoever (ah, now I know it will be you) is going to fix it have some basic idea about opening files in application he or she makes fixes for. That was a wrong assumption again, sorry about that.
What do you think about screencasts?
Should I cover application installation, how to run it, folder navigation, basics of saving attachments from bugzilla by using web browser?
Just in case developers need that...
> -- what exactly is unexpected (The visible effect and the expected root
Probably you lost me here. "Hatches are ignored in CreateBrushIndirect record".
Doesn't it sound like "what exactly is unexpected"?
May be some of my expectations are wrong though (same as assumptions).
> -- and why do you believe it's unexpected
Ah... up to wrong expectations (see above), I assume basic MF records should be implemented for MF importer to be useful.
Yeah.. very arguable position... 'Usefulness' is not quantitative metric...
Let's say you win this one too.
> -- concerning your PC (especially: video card)
> –- Libo settings that might be related to your problems
> (video hardware acceleration ...)
That's sooo creative... 'SetPolyfillMode is ignored because of VideoCard'...
I have to think about it...
> -- concerning your OS
WMF importer code seems to be the same on all platforms.
Anyway, you are right. It's not fair to leave any place for doubts.
With all that history of my mis-assumptions and mis-expectations, I worry to assume that it could be just one bug for any OS, or identical bugs one per OS (I deduce that 'one per' wins over 'all in one' based on your comment! See? I'm learning new things today! =) Thank you very much!)
> concerning your LibO version and localization (UI language)
Yes, yes... Fully agree with you. Wrong assumption again, commented at the start. Just a question... one bug per localisation, right? For each and every of them, just in case.
> how you launch LibO and how you opened the sample document
Now I'm not even sure I did launch it.
One bug per method of launching for each way to open for each LibO application, no matter results are always the same, correct?
We are not going to confuse developers with qualificators like "all" and "any".
English is not a native language for some of them, so they probably from the group of people who don't understand what's funny about "any key" anecdote.
> If you can contribute an OOo Issue that might be useful
Who cares about 4 years old one?
Oh... that's was wrong assumption, right?
Two actually: do not assume ppl don't care and do not assume rodo remembers old bug.
> everything else crossing your mind after you read a.m. URL
Yeah... There is one thing I should take into account first of all:
I'm NOT an OO.o/LibO user, hence there is no reason to report bugs.
> Can you please file Bug reports with status UNCONFIRMED if your are not
Please, please, don't involve me into discussion about "default status for bugs opened for LibreOffice". I'm not interested to participate and/or be counted for, against or instead.
I'm working on the set of EMF testing files to make a review of EMF/EMF+ support in different applications. I had plans to file a bug for LibO related to EMF implementation, but it looks like I'm completely out of the skills to report bugs.
So, do it yourself and/or ask tester8 for help. I know you can easily generate original content, make comprehensive review and properly file bugs based on it.
So do it! That would save time for everybody.
And to be honest, I don't care if anybody will fix issues listed in that bug or not. Feel free to close or remove it.
I will not comment here any more, want to discuss -- join #libreoffice-dev.
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
Björn, it has all required info (since time this bug was filed).
If no one is going to work on it, close it with WONTFIX, so I could make a note for myself to not consider LibO implementation in the future tests.
Dear bug submitter!
Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.
To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement
Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.
Okay thank you for your info, but I, as well as Rainer, have the problem to reproduce the bug. Is it possible to make a simpler test case, like
In test1.zip are two files
1) File to insert into LibreOffice
2) PNG how it should look like
3) Maybe a description what is the difference, if it is difficult to see.
I am very sorry, but without that info I am not able to set it to NEW...
> Okay thank you for your info, but I, as well as Rainer, have the problem to
> reproduce the bug. Is it possible to make a simpler test case, like
You are kidding me, right?
Open file "fulltest.wmf" (attachment "Example file for issues #1 to #4"), compare it with attachment "How "fulltest.wmf" should look like".
If you don't see the difference, close this bug with any resolution.
I will try it ASAP...
It was just to complicated, but I will give it a try....
> It was just to complicated, but I will give it a try....
That's because it's targeted to any person who knows about WMF format internals. I'm sure Caolan or Radek would have no problem with it.
In case you would like to make your hands dirty:
Reproduced problem with first attachment in 3.6.1 on Fedora 64 bit
(other not tested, I guess that problems remain)
Sorry but I am out of office until January 6th, 2013.
All messages will be forwarded to my personal email address.
In very urgent cases I will respond.
Best regards, merry Christmas, and a happy new year,
– Software Development –
Sensor-Technik Wiedemann GmbH
Am Baerenwald 6
Phone +49 (0) 8341 9505-724
Fax +49 (0) 8341 9505-55
Registered with: Amtsgericht Kempten, HRB Nr. 1863
Managing Directors: Katharina and Wolfgang Wiedemann
During the Christmas period, we will shutdown from the 22nd of December until the 6th of January.
We thank you for a successful and harmonious year working together, and for the trust you have placed in us in 2012. We wish you a peaceful holiday and happiness and success in the New Year.
Your STW/KMW Team
I think this bug should be meta bug for WMF/EMF problems, or there should be another meta bug for that. Those problems are numerous.
Submitted a patch for #5 to gerrit: https://gerrit.libreoffice.org/28684
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":
tdf#39256: Fix "Orientation treated as Escapement"
It will be available in 5.3.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
this bug report is incorrect as there are many problems described here. It should be split up into different report where each report described one problem.
I would suggest, if problem 5 is fixed, to close this one as RESOLVED FIXED and open follow-up bugs.
So, #5 should be fixed or looks so, and #6 is reported as Bug 101889.
Xisco is quite right, these are separate issues.
I'd close this one and open follow-up bugs myself, but I can't say which of these remaining can be grouped together.
(In reply to Timur from comment #29)
> So, #5 should be fixed or looks so, and #6 is reported as Bug 101889.
> Xisco is quite right, these are separate issues.
> I'd close this one and open follow-up bugs myself, but I can't say which of
> these remaining can be grouped together.
Practically each one is about different record type in WMF.
Nevertheless, 1&2 and 3&4 are likely somewhere close to each other.
Everything else is independent.
I've seen an update about new EMF renderer in LibO. WMF is very similar, so probably code from the new EMF renderer can be consulted or partially reused to fix whatever left broken in WMF.