Bug 50309 - Libvisio: Multiple sheets from Visio do not import in the same order. Also, unexpected font color changes in import.
Summary: Libvisio: Multiple sheets from Visio do not import in the same order. Also, u...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Drawing (show other bugs)
Version: 3.5.3 release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Fridrich Strba
QA Contact:
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-24 06:48 UTC by Ackbeet
Modified: 2013-11-13 10:49 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Attachment is a fairly simple Visio document, only 5 sheets, but with enough complexity to reproduce both problems. (1.09 MB, application/vnd.visio)
2012-05-24 07:44 UTC, Ackbeet
Details

Description Ackbeet 2012-05-24 06:48:31 UTC
Problem description: 

Steps to reproduce:
1. Import Visio document with multiple sheets (I had 50). 
2. View import in LO Draw.

Current behavior:

All sheets are imported, but not in the same order as they are in Visio. Also, in text fields from Visio that had black fonts, they became yellow in Draw.

Expected behavior: Keep the same order of sheets, as well as the same color of fonts.

Platform (if different from the browser): 
              
x86 32-bit, running Win XP Pro. LO version 3.5.3.2.
Comment 1 Ackbeet 2012-05-24 07:44:52 UTC
Created attachment 62058 [details]
Attachment is a fairly simple Visio document, only 5 sheets, but with enough complexity to reproduce both problems.

Exact steps:

1. Save Visio drawing on your computer.
2. Open LO Draw.
3. File >> Open.
4. Browse to Visio drawing.
5. Select Visio drawing.
6. Click Open.

Expected: sheets in same order as in Visio (1,2,3,4,5). Fonts same color as in Visio. But, what you see instead are sheets in a different order (2,4,5,3,1), as well as a number of font color changes: the sheet coordinates are changed from black to yellow, some of the info in the lower-right-hand corner is changed from black to green, and some of the text in the legend box in the lower-left-hand corner is changed from black to blue.
Comment 2 Valek Filippov 2012-05-24 17:20:29 UTC
Page order problem is clear.
Text colour needs some additional investigation -- LibreOffice does use colours that are actually stored in attached VSD file.
Comment 3 Ackbeet 2012-05-24 17:27:18 UTC
@Valek: Thanks for reply. 

You write, "Page order problem is clear." Do you mean the problem statement is clear, or that the problem solution is clear?

You write, "Text colour needs some additional investigation..." Should I do some investigation? I haven't dived into LO development at all. I could try to narrow it down a bit - a more minimal example that still reproduces the problem, if that would help.

Please advise.
Comment 4 Valek Filippov 2012-05-26 15:45:34 UTC
2 Ackbeet:

Solution is clear for page order.

For text clr I will check why it was overridden by black, no action is required from you at the moment.

Of course if you want to contribute to LibreOffice, you are always welcome!

Check http://www.libreoffice.org/developers-2/ for ways to contribute.
Comment 5 Valek Filippov 2012-05-26 22:19:00 UTC
2 Fridrich/Tibby:

Colours for text/fill/stroke can be set (or locked to defaults) by layer.
libvisio needs to parse LayerIX chunk (probably only layers with colour/transparency and "visible" flag are important at the moment) and LayerMem chunk to apply layer props as required.
Comment 6 Ackbeet 2012-05-27 18:56:07 UTC
@Valek,

Ok, sounds good! Thanks for the clarifications.

Not ready for development work as yet, but I'll keep that in mind. I'm relearning my C right now.

Cheers.
Comment 7 Fridrich Strba 2012-05-29 08:29:22 UTC
OK, I fixed the page order in libvisio git and will be in the next release, which means that this fix will be for sure in LibreOffice 3.6.0. The text colour stuff is a bit more complicated and I will try to have a run on it too, just not sure how much time it will take.
Comment 8 Ackbeet 2012-06-01 08:59:53 UTC
As an update: this 50-sheet document I had imported earlier, all of a sudden shuffled its sheets into some new order, not the one I had put them in (corresponding to the Visio document). I'm wondering if your bug fix will fix this as well.
Comment 9 Valek Filippov 2012-06-01 09:18:21 UTC
Then you create a document in Visio and start to add pages to it, Visio increment page IDs for each new page.
If you remove some pages from the start or shuffle pages, Visio do not re-numerate them internally. To keep proper (for representation) order Visio stores ordered list of page IDs.

Before Fridrich's fix libvisio was not taking this list into account but read pages in the sequence it's stored in the file (with weird results you observed).
With this fix libvisio uses the list to throw pages in the right order.
Comment 10 Ackbeet 2012-06-01 09:45:48 UTC
@Valek,

Thanks for the explanation. So is there a way in LO Draw 3.5 to number the sheets so they stay put in the order I want them in? I suppose one way would be to start a brand-new document in Draw, and then copy and paste the objects into the new file. Would that work, or would these page ID's still come along for the ride?

Cheers.
Comment 11 Ackbeet 2012-06-06 06:32:26 UTC
Please disregard my last comment. I found out today that I was accidentally re-opening the Visio document, instead of the LO Draw document; I was just seeing the bug exactly as originally reported. My LO Draw document has not reshuffled its pages. 

Sorry about the confusion!
Comment 12 Julien Nabet 2013-08-24 06:02:46 UTC
Any update with new LO version (4.0.5 or 4.1.0)? I opened the document on pc Debian x86-64 with master sources updated yesterday but didn't see (certainly missed) the point.
Comment 13 Valek Filippov 2013-08-24 12:15:50 UTC
(In reply to comment #12)
> Any update with new LO version (4.0.5 or 4.1.0)? I opened the document on pc
> Debian x86-64 with master sources updated yesterday but didn't see
> (certainly missed) the point.

Page order was fixed while ago.
Layers are not supported yet, hence color part is not fixed.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.