When writing .ocd file all color layers are have the "overprint" flag set

[FinnAr]

Steps to reproduce

1. Save a file as .ocd

Actual behaviour

The written file has the "overprint" flag set for all color layers

Expected behaviour

The color layers would be marked with "overprint" if the "KO" flag is not set for that color layer in Mapper, and vice versa

Configuration

Mapper Version: 0.9.5
Operating System: Windows 11

[dl3sdo]

@FinnAr: I did the following test with Mapper 0.95 and OCAD12:

• Export forest_sample as .ocd (OCAD12) file
• Check color settings in OCAD: colors in Mapper with 'K.o.' set are imported as 'Ov.' not set and vice versa
• Save forest_sample.ocd in OCAD
• Open file in Mapper to check the round-trip behaviour => everything is working as expected

Thus, I cannot reproduce the issue and also the code to export to .ocd has no pecularities.

Can you provide more details or even test files?

[DaveIR]

I have the same issue.
I have a map that is originally in OCAD (version unknown).

I can open the map and save it as omap

I can also save the map as OCAD but when I import the map into CONDES (10.5.11) I get the error saying that all colour layers have overprint set. I can see the effect in CONDES in the attached example where the road junction in the E doesn't have the black edges suppressed and the dark green overlaps the road to the NE of the building.

If I export to OCAD 8 format this does not happen, but any higher OCAD version export (9 to 12) does have the issue.

Windows 10 Pro
Mapper 0.9.5

[dl3sdo]

I notice in the Condes history of version 10.5.9:

When printing, overprint flag on white OCAD map color layers was NOT ignored. White OCAD map color layers flagged as “overprint” would not be visible when printing.
Note: OCAD files edited in Open Orienteering Mapper will get overprint flags on all colour layers. This can be considered a bug in Open Orienteering Mapper – be careful to check this.

[FinnAr]

Hi MatthiasI did not do any tests with Open Orienteering Mapper myself.  My report was entirely based on input from Condes users - and the OCAD files exported from Open Orienteering Mapper they sent me. I apologise for not providing you with sufficient info to reproduce the issue.Thanks to Dave for rectifying this.

[dl3sdo]

Hi @FinnAr: I still can't reproduce the issue:
I just imported an .ocd12 file (which was never touched by Mapper) and exported it to .ocd12 => 'overprint' flags are ok. The same happened for an .ocd18 file which I exported to .ocd12.

The code looks good to me: "\to" << (color.getKnockout() ? '0' : '1')
Actually the 'Knockout' resp. 'K.o.' setting in Mapper is the opposite of the 'overprint' property of OCAD.
Thus, when you open any of the affected .ocd maps before and after exporting to .ocd: Are the 'K.o.' checkmarks in Mapper ok?

Could you provide such a map to me (maybe by exporting a small piece?) since the issue should be independent from the number of objects and just depend on the colors.

[FinnAr]

Hi Matthias I think the best bet is to ask Dave for an example – I only have the resulting ocd file exported from Open Orienteering Mapper, not the input file.

[dl3sdo]

@FinnAr: I just installed Condes (I assume that you are the author) and got no warning, which is not surprising as the maps look good in OCAD (i.e., not all 'overprint' flags are set).
@DaveIR: can you provide a sample?

[dl3sdo]

@DaveIR: I deleted your attachment, as it contains the whole map which was not intended I guess. Always clear the undo history, otherwise the original map can be restored.
P.s.: editing your comment does not help, thus I deleted your comment and pasted it below. Sorry for the confusion.

[dl3sdo]

from @DaveIR:
Hi Both,

Thanks for engaging with this.
The attached zip contains a map extract in mapper, and two exports of the file, one to OCAD 8 and the other to OCAD 12. The OCAD 8 opens fine in CONDES and looks OK, but the OCAD 12 has warnings when opened in CONDES and looks a mess e.g. the road junctions.
I don't have the untouched original OCAD, but hope this is enough to highlight the issue.
Thanks
Dave

[dl3sdo]

At a first glance: the .omap does not contain any spot colors, thus the Knockout property will always be not set and thus the 'overprint' flag will always be set when exporting to .ocd.
Regarding the road junctions:
In the .ocd file the 'Street infill' is above the 'Street borderlines' in the color order, thus hiding the black color. If you swap these colors, then OCAD renders it as Condes does.
How does Condes handle the order of colors?
However, if you unset overprint on these two colors, then Condes renders as OCAD and it looks fine.

[FinnAr]

Hi Matthias Condes processes the color layers in the same order that OCAD does, i.e. from the bottom to the top Condes does respect the “overprint” flag, and thus applies overprint effect to the color layer on which it is set, which will then “blend” with the underlying layers. I’m not sure I understand the rationale for not setting the knockout property on all color layers when there are no spot colors. I would have thought that ‘knockout’ would be on as a default.

[dl3sdo]

On export don't set the 'overprint' flag for colors without spot colors?

[FinnAr]

That would seem to resolve the issue for the case at hand. From: Matthias Kühlewein ***@***.***> Sent: 25. august 2024 12:34 To: OpenOrienteering/mapper ***@***.***> Cc: FinnAr ***@***.***>; Mention ***@***.***> Subject: Re: [OpenOrienteering/mapper] When writing .ocd file all color layers are have the "overprint" flag set (Issue #2228) On export don't set the 'overprint' flag for colors without spot colors? — Reply to this email directly, view it on GitHub <#2228 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUCJJTBKFY5XC7U7GEN4ULZTGXIVAVCNFSM6AAAAABGGJQ55KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYG43TCMZVHA> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AAUCJJVMDMFNOHLQBB72RBLZTGXIVA5CNFSM6AAAAABGGJQ55KWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUJTUHB4.gif> Message ID: ***@***.*** ***@***.***> >