OCD export changes color index

[jmacura]

Steps to reproduce

1. Create map in OCAD 10
2. Open in Mapper
3. Export to OCAD 10 (new file, do not rewrite)
4. Open in OCAD 10
5. Copy some objects from map created in step no. 1

Actual behaviour

Index of colors in the table is renumbered => The file is no longer color-compatible with its previous versions. A picture is worth a thousand words:

Objects I am copying from the original file:

Objects how they appear in the new file (exported from Mapper):

How does the table of colors look like in the original file:

How does it look like in the new file (exported from Mapper):

Expected behaviour

The index in table of colors should remain the same. Why this is important? Because many maps are created in teams. Some team-members use OCAD and some use Mapper, these files must remain mutually compatible.

Configuration

Mapper Version: 0.9.20190326 Operating System: Windows 10

[lpechacek]

Is step 5 (copy objects from original map) mandatory or are the display colors skewed in step 4, please?

[dg0yt]

I don't think we do preserve the index numbers at the moment. But we should eventually add a ID field (and the same for symbols, objects).

[lpechacek]

I've just played with OCAD 8 a bit, assuming the behavior is the same in higher versions.

So I set up a new map from orienteering symbol set, created a few objects. Saved a copy of that map, deleted color entries and added new colors with the same indices at their place (Delete color entry followed by New). Opened the previously saved copy, selected an object, copied it and pasted into the modified map. No surprise, the pasted object came out in a different color.

Bottom line is that OCAD blindly references color entries by their indices upon pasting objects from a different map. For good interoperability Mapper should retain the color indices.

P.S. Just made similar experiment with symbols. OCAD does detect modified symbol with the same number and creates a new symbol when pasted objects use the altered definition. If the same logic were implemented for colors, this issue ticket would likely not exist.

[dg0yt]

1. Do we want to add IDs? (Okay for me.)

If yes:

2. Do we want to use simple, auto-increment integers? (Okay for me.)
3. How do we handle IDs in the process of color "merging" (copy-and-paste, symbol set replacement)? It is heuristics anyway at the moment, based on properties and relative position. Unfortunately not well covered in unit tests. (While they are probably less relevant in copy paste, it is more difficult with symbol set replacement, especially if original data and new data are inconsistent with regard to color values, IDs, symbols.)

[ghost]

Do we want to add IDs? (Okay for me.)

How do we handle IDs in the process of color "merging" (copy-and-paste, symbol set replacement)? It is heuristics anyway at the moment, based on properties and relative position. Unfortunately not well covered in unit tests.

While implementing "colors ID" for export/save OCD files would be useful, for open/import OCD files it would be useful that Mapper would use "color ID" only for keep order (but would not use "color ID" in OMAP files), but in OMAP file format "color ID" parameter should be optional (could be empty for each color). Is it possible add next options in settings dialog:

• "Use colors ID for keep colors order from imported OCD"
• "Auto-generate colors ID for keep colors order in exported OCD"

How does the table of colors look like in the original file:

BTW, as for me, this look like a BUG of colors management in OCAD program.

[jmacura]

@lpechacek

Is step 5 (copy objects from original map) mandatory or are the display colors skewed in step 4, please?

Step 5 is mandatory. Up to step 4 everything appears as it should. But you have figured that out already on your own, right? :-)

@Symbian9

BTW, as for me, this look like a BUG of colors management in OCAD program.

If you think that unordered list of colors is a bug in OCAD, than it is a "bug by design" or how to say that. It is intentional and it is the only way how to define your own colors and affect their rendering order (overprint).

[ghost]

If you think that unordered list of colors is a bug in OCAD, than it is a "bug by design" or how to say that. It is intentional and it is the only way how to define your own colors and affect their rendering order

I not mean un-ordered, I mean: if move color "X" from 2 to 1 place, it should change ID from 2 to 1. But in OCAD when move color "X" from 2 to 1 place - color still has ID 2, and all other colors moved down now has ID that not describe their real place in the colors list.

So, it is "bug by design", but I highly NOT recommend add such "bug by design" into OpenOrienteering Mapper (if add such option in the Mapper settings for temporary compatibility - then it's OK)

[jmacura]

I not mean un-ordered, I mean: if move color "X" from 2 to 1 place, it should change ID from 2 to 1. But in OCAD when move color "X" from 2 to 1 place - color still has ID 2, and all other colors moved down now has ID that not describe their real place in the colors list.

That's what I meant by "unordered" ;-) = not preserving the order of IDs. But we both talk about the same thing here.

And I agree that there are certainly better ways how to manage color list.

[lpechacek]

I'm just recording that @zlenhart reported in an e-mail thread that the color entry renumbering is an issue.