Bug 54189 - [FILEOPEN] Image cropping not implemented in .pub import
Summary: [FILEOPEN] Image cropping not implemented in .pub import
Status: NEW
Alias: None
Product: Document Liberation Project
Classification: Unclassified
Component: libmspub (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 78733 (view as bug list)
Depends on:
Blocks: Image-Crop
  Show dependency treegraph
 
Reported: 2012-08-29 07:56 UTC by ape
Modified: 2017-10-30 11:35 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
archive with files (1.04 MB, application/zip)
2012-08-29 07:56 UTC, ape
Details
The option 'Format Picturie > Crop form' isn't imported. (42.57 KB, image/gif)
2012-10-28 05:06 UTC, ape
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ape 2012-08-29 07:56:58 UTC
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.
Comment 1 ape 2012-08-29 12:36:23 UTC
Fridrich, Brennan! I added you to "CC," because you have developed this filter. Correct, please, if I'm wrong.
Comment 2 Brennan Vincent 2012-08-30 06:35:03 UTC
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.
Comment 3 ape 2012-08-30 18:02:19 UTC
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.
Comment 4 Brennan Vincent 2012-08-30 18:36:00 UTC
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 :)
Comment 5 ape 2012-08-31 11:47:26 UTC
(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.
Comment 6 Fridrich Strba 2012-08-31 12:41:45 UTC
(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.
Comment 7 Brennan Vincent 2012-08-31 14:25:36 UTC
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.
Comment 8 ape 2012-09-01 06:28:18 UTC
@Fridrich:
Thanks for the clarification on the topic and information about future development of filters.
--
@Brennan, Fridrich:
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?
Comment 9 Brennan Vincent 2012-10-28 02:14:05 UTC
@ape

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.
Comment 10 ape 2012-10-28 05:06:22 UTC
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]).
Comment 11 Brennan Vincent 2012-10-28 05:18:48 UTC
@ape
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.
Comment 12 Fridrich Strba 2012-10-29 04:35:22 UTC
Adding David Ostrovsky since he is working on the image cropping implementation.
Comment 13 kunda 2016-03-21 13:22:16 UTC
This seems to be a duplicate of https://bugs.documentfoundation.org/show_bug.cgi?id=78733
Comment 14 David Tardon 2016-03-22 06:02:20 UTC
*** Bug 78733 has been marked as a duplicate of this bug. ***