Persist OCD color numbers #2158
Conversation
|
Marking the pull request as draft. There are problems in symbol import - the newly created colors can have duplicate id's which in turn breaks OCD export. I'll update the patch set soon. |
lpechacek
force-pushed
the
issue-1245-color-numbers
branch
from
b04ea99 to
29a4b10
Compare
|
FWIW, this implementation has served me well for a few months. I'm not saying it's perfect. There are many spots in the code where improvement might be desirable. On the other hand, this exercise has uncovered a few defects. The fixes may be cherry-picked on its own. That said, I'm removing the draft status. |
|
Libor, thank you for solving that issue. In addition I noticed that the Registration black color changed its id from 1 to 45 during the course of import from and export to .ocd (OCAD12), although 1 is not used in the exported map. |
Ack. I noticed in some OCD files that zero is used as an ID. The Viewer also allows that value. But start at one is more common and it's also aligned with the Pascal view of the world. That's why zero is allowed but not preferred.
Yes, likely a bug in the code. :) I'll have a look. |
The number accepted by getMapColor() and similar methods is not exactly an index. The value is treated as the color rendering priority, it is synced into the color Priority member and should be treated as such. Namely, reordering the color table changes the priorities invalidating any previous parameter values. This commit makes it obvious what value we are using for the color lookup.
The color id value will help us reference the map color in file format context. Currently colors are addressed by its rendering priority. The goal is to address colors by its stable id in a future file format. For now, we do not compare the color id in MapColor::equals() as there is no use for it. The id is not part of the color identity, much like its priority says nothing about the color itself.
The introduction of color id makes the tests alter example and symbol set sources.
Use the color id to store the OCD color number. We know that the registration black may move in the table, get a new number, or might be dropped. The thing is that Mapper has registration black as a special color that cannot get an OCD color number, and we merely guess whether we need the color in the table in the export path. Closes OpenOrienteeringGH-1245.
CMYK color component values can include fractional parts. The v8 format expresses the component values as a number in the range 0-200 that maps to percentages therefore component values are recorded with 0.5 % precision. The higher format versions use strings for the color definition, and the numbers can include one decimal place. This patch makes Mapper export the fractional part as needed.
Although the official docs do not mention the color overprint property, the program dialog contains this setting. A quick experiment shows that the checkbox controls a reserved struct member. This patch implements color overprint import and export in OCD v8 format.
Mapper is unable to detect Registration black in absence of spot colors. This patch fixes the defect, loosens the name matching criterion and aligns the matching criteria along the supported OCD format versions.
Transparent (semi-opaque) colors are supported only in later format versions. This patch makes Mapper write out a warning when the color opacity value gets dropped.
lpechacek
force-pushed
the
issue-1245-color-numbers
branch
from
29a4b10 to
30a443e
Compare
Fixed and rebased the patch set. The thing is that spot colors were assigned new id's in the OCD import path. The export path saw the low id numbers as used and searched for a new id for the registration black. Thanks again for testing the change reporting your findings! |
This is a working implementation addressing issue 1245. The introduction of a stable color id uncovered some room for improvement in the native Mapper format and the new tests discovered bugs and limitations in the OCD format implementation. The first four patches introduce the stable color id required for smooth interoperability with the other software. The next four ones address defects and limitations in the OCD support routines.
There is certainly number of points for discussion in the patch set which I'm leaving for a possible review round.