Created attachment 66263 [details]
archive with files
A filter decodes WMF files as shapes. Therefore, the picture is distorted: violated the proportions, the color palette is set to "Default". These files must be inserted as images. This will allow correctly decoding WMF file contained in the publication. (See GIF animations in an attachment.)
The content of an attachment:
1) Two publications (color of the WMF changed in the second file);
2) Source (color) the WMF;
3) ODG file as a result of import PUB file with addition WMF file to which applied the same parameters as “dog_2.pub”;
4) Two GIF animations that explain which settings (MS_Publisher 2002 and LibO_Draw 3.7.0) were used to the WMF file.
Fridrich, Brennan! I added you to "CC," because you have developed this filter. Correct, please, if I'm wrong.
Thanks. I will look at this soon.
I believe this is a duplicate (we already know about several problems with decoding images as shapes, but for various reasons it's simplest to do it that way). I will either add more information to this bug soon if it turns out to be new, or mark it as a duplicate.
Brennan! I see an error that you insert the image by defining it as "Area ... > Bitmap". You already have a picture, which you can set options are the same as in the publication. Why insert a picture into a shape? This (bitmap into shape) will not allow you to edit a *.wmf in the settings MS_Publisher.
As I said, there are various reasons why our code is much simpler if we can use area fills instead of actually outputting shapes. Notably, that it works the same way for non-rectangular shapes. It might be better just to fix the bugs in LibreOffice area fills than to switch to outputting images. But if that proves infeasible, we can change how the filter works. Again, I am busy with school and can't look at it for a few days; be patient :)
(In reply to comment #4)
> As I said, there are various reasons why our code is much simpler if we can use
> area fills instead of actually outputting shapes. Notably, that it works the
> same way for non-rectangular shapes. It might be better just to fix the bugs in
> LibreOffice area fills than to switch to outputting images. But if that proves
> infeasible, we can change how the filter works. Again, I am busy with school
> and can't look at it for a few days; be patient :)
Brennan, changing the object type for speed is a success. But this is a tactical advantage. It seems to me that this decision significantly complicate reverse exports to *.pub format that will lead to a strategic defeat.
(In reply to comment #5)
> Brennan, changing the object type for speed is a success. But this is a
> tactical advantage. It seems to me that this decision significantly complicate
> reverse exports to *.pub format that will lead to a strategic defeat.
Forget about reverse exports to *.pub format, unless you feel like spending some years with hexadecimal editor to understand the function of *every* byte in the format and understand why Publisher does not agree with your file-format understanding that is a result of reverse-engineering.
Very frankly, we are lucky that we have already a knowledge that allows us to read the files. The import filters we have for publisher, visio or corel draw are the best approximation and result from long months of work of 2-3 people constantly. And fixing something like rotation and shape of a raster image in Draw is not as simple as that and might lead to serious regressions, just by touching it. So it is not like one can do it after a couple of beers during rainy fall evening.
I am willing to write a Publisher export filter for $1,000,000 USD. If that money is hard to come by (I understand money is scarce in today's economy...) then your best bet if you need to collaborate with people by sending them .pub documents is either to convince them to change to .odg, or to simply buy a copy of Publisher yourself (as much as I dislike the idea of people having to resort to this!) The development of a .pub export filter is simply too difficult to be on the table at this time.
Thanks for the clarification on the topic and information about future development of filters.
I guess, to split this error and change the names of this error and bug 53469, which Brennan wrote, to avoid duplication and to describe the two different errors in a single message:
1. This bug is a violation of geometrical proportions *.wmf file whose settings are changed by the Publisher.
2. Bug 53469 about incorrect color when importing Windows Meta Files.
What do you think about this?
Sorry, I finally got around to looking more closely at this bug.
You are correct in saying that the color issues are due to Bug 53469.
Could you tell me what you mean about the proportions being wrong? The proportions looked the same in LibreOffice as in Publisher to me. Could you be more detailed about what you mean?
Thanks for your work reporting this bug.
Created attachment 69179 [details]
The option 'Format Picturie > Crop form' isn't imported.
Brennan, look, please, GIF animations (creating_ms-pub.gif and wmf_in_odg.gif) from the archive (attachment 66263 [details]).
You are correct. I've changed the status and title of this bug appropriately.
I can't give you a timeline on when the fix will be implemented, unfortunately.
Thanks a lot for taking the time to report this.
Adding David Ostrovsky since he is working on the image cropping implementation.
This seems to be a duplicate of https://bugs.documentfoundation.org/show_bug.cgi?id=78733
*** Bug 78733 has been marked as a duplicate of this bug. ***