Jump to content
You must now use your email address to sign in [click for more info] ×

copy between documents changes colours (b523)


Recommended Posts

20 hours ago, fde101 said:

If the standardization of the ink could be trusted at the VERY high-end of this market...

I think the discussion about how we don’t need user-defined compositions of colour since the printing process itself is flawed (and paper variations making it even worse) is beside the point.

Yes, there are many variables that can render a colour different than intended. But that doesn't mean relying on one’s own colour definitions is superfluous. It is a necessity for reasons like rastering or tinting or overprinting or for simply passing them on.

Link to comment
Share on other sites

41 minutes ago, fde101 said:

If the standardization of the ink could be trusted at the VERY high-end of this market...  why would anyone bother with that?

I don't bother with that, and you shouldn't, too. – You initially said, that 100% Black can't be 100% in all different situations and color spaces (profiles) because of variations in ink. And you said, these ink variations were the reasons for CMS and profiles and therefore the reason for the need of a value change of a 100% black in Affinity.

Whereas I said, ink is standardized but CMS is necessary because of the print machine and its process and the print material (paper), to make sure that 100 % of an ink remains 100% in any process, which can be tricky because these inks are translucent.

So, back to the topic, finally there is no useful reason for Affinity to alter a 100% K when such an object gets copied/pasted or placed from one CMYK document to another, as mentioned by the OP.

And, of cause, there is also no reason to change a Black's definition from Under Color Removal (UCR) to Grey Component Replacement (GCR), as Affinity currently always does when it's altering a 100 % K.

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

8 minutes ago, Matthias said:

It is a necessity for reasons like rastering or tinting or overprinting or for simply passing them on.

If the documents have the same color profile, it already works as is being requested.

If you copy an object between documents the color is converted when the profile is different, in order to make sure it is the same actual color (or as closely as possible) in both documents - that makes sense, because with different profiles, different numbers are needed to achieve the same color in the end.  I I am placing the same artwork on two different documents and they are being printed using two different profiles (media, etc.) then I probably want the artwork to look the same on both, but it won't unless the numbers are adjusted to compensate.

If you change a document to a different profile, you have a choice of converting the colors (change the numbers to keep the colors the same) or of re-interpreting the colors (keeping the numbers the same and accepting that they will look different in the end).

If you want to copy the objects to another document and it has a different profile and you are more concerned about the numbers than the appearance of the colors, change the color profile of the source document to match the target one and re-interpret rather than convert the colors.  That way the profile and the numbers will match, and you can copy the object(s) over without the numbers changing.

Link to comment
Share on other sites

On 12/19/2019 at 4:55 PM, fde101 said:

If the documents have the same color profile, it already works as is being requested.

True.

But I think as long as it is a colour that I have defined as a global colour it should always stay the same, regardless of the document’s colour profile. I’d also expect the according swatch to show up in the new document (which it doesn't).

I’d prefer my global colour looking weird in a different colour space. Numerically (but kind of secretly) changing the actual colour values is a recipe for disaster when you have to work with people that are not so much into colour management (I’d guess it is the majority). Because once the app has benevolently changed ”my“ colour’s numerical values in order to keep it’s appearance a third party cannot ever trace it back to it’s original values (which might have been there for a reason). Whereas it’s easy to change the document’s colour profile anytime to match the intended output (or the global colour itself, provided the swatch is being copied over, too).

Since numerical colour definitions (not colour appearances) are a customary thing in corporate design I am actually baffled that this is a topic that’s being discussed at all.

Link to comment
Share on other sites

19 minutes ago, thomaso said:

no useful reason for Affinity to alter a 100% K when such an object gets copied/pasted or placed from one CMYK document to another

That depends on why the object is 100% K.

  • If I were trying to match the color of an object to a color I found in an image and the color in the image happened to be 100% K, then my objective is to keep a specific color - the appearance of the color, not the numbers - and if I move to a document with a different profile, I need the color to be converted (translated) to continue to match the color from the picture.
  • If I am trying to save cost/time by only using black ink (because color is more expensive or slower to print) then I would want the color to stay 100% K and not be converted.  For this case I am willing to accept a slight variation in the appearance of the black.

 

Currently, there is no mechanism to tell the Affinity apps which of these situations is the case for a particular use of 100% K whether in a swatch or otherwise, so it is assuming the first case I listed - that the color should be kept the same at the expense of the numeric values.  I do think this is a reasonable default when the color is specified directly as a color value (CMYK or RGB).

I continue to suggest that the solution is to create a special "K Only" swatch type, similar to the way spot colors work, which represents a 100% K value that does not get converted when moving the color between documents.  This would handle the second case, which seems to be the one most of you are looking for.  I do agree that option is currently missing and there is room for improvement, but I do *not* agree that the current behavior is a bug.  It is needed to cover the first case I listed.

Link to comment
Share on other sites

48 minutes ago, Matthias said:

I’d prefer my global colour looking weird in a different colour space. Numerically (but kind of secretly) changing the actual colour values is a recipe for disaster when you have to work with people that are nor so much into colour management (I’d guess it is the majority). Because once the app has benevolently changed ”my“ colour’s numerical values in order to keep it’s appearance one can never trace it back to it’s original values (which might have been there for a reason). Whereas it’s easy to change the document’s colour profile (or the global colour itself, provided the swatch is being copied over, too).

Since numerical colour definitions (not colour appearances) are a customary thing in corporate design I am actually baffled that this is a point that’s being discussed at all.

I agree with every you say, and especially this. The conversion is happening without my knowledge - baffling to me that anyone would want this.

Link to comment
Share on other sites

6 hours ago, fde101 said:

That depends on why the object is 100% K.

Dude. 100k is not a colour. It is a function. It is a decision by the designer to only print ONE ink and dont‘t do raster points in an otherwise colourful brochure. 
There is no reason to change this function by any profile and it has nothing to do with how the colour impression on screen is. 
You are reasoning to never use cmyk-values and instead use RGB, as this "colour impression" will get converted anyways? So why do you think the Affinity team made the effort to include cmyk? 

This is ridiculous. Lets please get back to the point. 
 

The final, obvious question: how does InDesign do it (or Illu, fwiw) Spoiler: I know the answer.

  • Main machine: iMac 2019 (21,5-inch 4k, 6core), 64GB RAM, 1TB nvme + 2TB ssd, running on Mac OS 13;
  • Display setup: 28" 5k Display (primary) + 21,5" iMac4k-Display for studio panels (secondary);
  • Keyboard layout: german apple extended keyboard (aluminium);

 

Link to comment
Share on other sites

7 hours ago, Matthias said:

Since numerical colour definitions (not colour appearances) are a customary thing in corporate design I am actually baffled that this is a point that’s being discussed at all. 

7 hours ago, fde101 said:
  • If I were trying to match the color of an object to a color I found in an image and the color in the image happened to be 100% K, then my objective is to keep a specific color - the appearance of the color, not the numbers - and if I move to a document with a different profile, I need the color to be converted (translated) to continue to match the color from the picture.
  • If I am trying to save cost/time by only using black ink (because color is more expensive or slower to print) then I would want the color to stay 100% K and not be converted.  For this case I am willing to accept a slight variation in the appearance of the black.

(...) but I do *not* agree that the current behavior is a bug.  It is needed to cover the first case I listed. 

Corporate Design color definitions are a good example.

Imagine a corporate logo with 100 % Magenta (e.g. "Telekom"). Currently Affinity converts this 100 % M even with a profile change from only a total max ink of 330 to 300 [ as with "ISO coated v2 (ECI)" –> "ISO coated v2 300% (ECI)" ]. Then the 100 Magenta gets converted to 100 M + 1 Y (= an additional print channel). And, with same profile change, a 100 K goes mad and gets converted into 4 channels. (see screenshots of OP's 1st post).

Only if this 100 % Magenta gets created as a spot color swatch it will keep its value in Affinity. This way Affinity forces the workflow to more than just the 4 CMYK print channels. That's a bug.

Another example could be a duotone layout with 2 colors only, let's say 100 Cyan and 100 Black. And let's say it shall get printed on a 2 color offset printing machine. In Affinity with a profile change it will result in 4 channels and rasterize both the cyan and the black (+ add magenta and yellow) with no need, and therefore with unwanted result. That's a bug.

As woefi pointed out above several times: a photo is an RGB image of thousands merged colors and tints/tones which need to get separated for print. – But a CMYK color swatch gets defined as separated already. So, while an image gets judged visually on screen (with monitor profile !, not document or print profile), a swatch may get defined numerical and judged by a 'dictionary' of printed cmyk color charts.

dcs-book-cmyk_torso.jpg.9e656a15f9430e0ea6013bd0b6df4f5c.jpg

1 hour ago, woefi said:

how does InDesign do it

Possibly this isn't very important and not a fair comparison; Affinity is much younger, has a quite different UI and is no copy of InDesign.

But it should work properly. As far I experience Affinity sticks too much in RGB and it still has deficiencies in the ability to make a difference between profile conversion and profile assignment. There are these two buttons in document prefs but to me they seem to have no function. Also the application preference of profile warning never pops up though it's activated. And Affinity seems to lack in the ability for fine-tuning on conversion, e.g. by an option to either keep a visual impression or numerical values.

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

25 minutes ago, thomaso said:

and it still has deficiencies in the ability to make a difference between profile conversion and profile assignment. There are these two buttons in document prefs but to me they seem to have no function.

In the document preferences, when you change the color profile that is established:

  1. Convert is supposed to reinterpret the color values into the new color profile space, to give the same visual experience.
  2. Assign is supposed to keep the color values and just assign the new color profile.

Or, from the Help (which should mean the same as I said above): "For applying a different colour profile, Assign adopts the new profile but leaves the values of the colours/pixels as is. Convert converts each colour from the old profile to the new one—colour/pixel values may change as a result."

I do not recall seeing any discussion in the forums that those two options do not work as documented.

30 minutes ago, thomaso said:

And Affinity seems to lack in the ability for fine-tuning on conversion, e.g. by an option to either keep a visual impression or numerical values.

On profile conversion, that is (respectively) Convert (keep a visual impression) or Assign (keep numerical values).

But the discussion in this topic does not seem to be about profile conversion. Rather it is about copying colors from one color space to another.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

Following on to my immediately prior post: If you have two documents of the same color mode (e.g., CMYK/8) but differing color spaces, and you need to copy objects between them keeping the same numerical values for their colors, the following works (only tested in Designer, only tested for CMYK/8):

If copying from document 1 (source) to document 2 (target) and they have different profiles, and you must keep the exact color numbers from document 1,

  1. Make a copy of document 1 for safety.
  2. In document 1, if in Designer, use File > Document Setup. In the Color tab, Assign document 2's color profile.
    Or in Photo, use Document > Assign ICC Profile and specify document 2's color profile.
  3. Copy your objects. The on-screen appearance of their color will change, but the color numeric values will be kept.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

1 hour ago, walt.farrell said:
  1. Assign is supposed to keep the color values and just assign the new color profile. 

(...) I do not recall seeing any discussion in the forums that those two options do not work as documented.

This is the first search result * for "assign convert":
(* edit: in the pre 1.8 beta forum)

Quote

One reason might be an issue in profile handling in AfPub. I noticed in earlier betas that the button "Assign" next to "Convert" seems to have no function. The default value is "Convert". If "Assign" gets selected then after closing + opening this window again "Convert" appears as selected. 

https://forum.affinity.serif.com/index.php?/topic/86658-fixed-100-becomes-cmyk-build-when-exporting-to-pdf/&do=findComment&comment=459095

This "Assign" button still doesn't work for me. Possibly for others, too:

1 hour ago, walt.farrell said:

the discussion in this topic does not seem to be about profile conversion. Rather it is about copying colors from one color space to another.

This topics issue *is* conversion – which converts a 100 K into the Affinity typical 4c-Black. Instead of keeping the *value*. Just look a the two screenshots in the first post.

 

EDIT: here's a more detailed topic with this "Assign" / "Convert" issue:
(also in pre 1.8 beta forum)

https://forum.affinity.serif.com/index.php?/topic/73230-colour-management-rgb-profiles/


And a recent topic with this response of MikeW:

  • "It is an issue. (...) In the document set up you can choose to assign versus convert.  However, it doesn't work as I would expect and keeps reverting from assign back to convert and thereby altering color values."

https://forum.affinity.serif.com/index.php?/topic/103828-color-changes-when-copy-n-pasting-from-one-cmyk-doc-to-another/&do=findComment&comment=558235

 

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

41 minutes ago, walt.farrell said:

If you have two documents of the same color mode (e.g., CMYK/8) but differing color spaces, and you need to copy objects between them keeping the same numerical values for their colors, the following works (only tested in Designer, only tested for CMYK/8):

Do I understand your recipe right that you change the documents color space just before copying an object from a different Affinity document without getting its color values changed?

Doesn't just using the button "Assign" (instead changing the profile) work for you, too?

It doesn't sound practical to change a documents color space every time you want to paste or place an item from a different color space. Imagine you want to collect various objects of various files with various colors spaces ... Instead of switching the documents color space again and again I'd expect the button "Assign" to care for this, keep the swatches values and respect and calculate any varying profiles just on export.

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

49 minutes ago, thomaso said:

I'd expect the button "Assign" to care for this, keep the swatches values and respect and calculate any varying profiles just on export

The Assign/Convert options are only for changing the color space of the document they are used in.  I've never seen anything to suggest they would have any effect on copy/paste.

Link to comment
Share on other sites

1 hour ago, fde101 said:

The Assign/Convert options are only for changing the color space of the document they are used in.  I've never seen anything to suggest they would have any effect on copy/paste.

Aha. So these buttons only work when I change this same document's color space? Means: only for already in this document existing objects?
If yes, I tend to call this another symptom of this topic's issue/bug.

– Why does this button not stick to "Assign" once selected but always jump back to "Convert" when I reopen this window?

– Where is the Assign/Convert option for in-coming objects? For resources I place and/or paste?

– And what is the application preference doing in Color > checkbox "convert" & checkbox "warn"? I would expect if "convert" is *not* ticked then an incoming item gets the profile just assigned (no conversion > no value change). And I would expect to get a warning message when "and warn" is ticked: Do *not* convert but (and) warn. Both appears not to work, they rather behave like having no function.

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

8 hours ago, thomaso said:

– Why does this button not stick to "Assign" once selected but always jump back to "Convert" when I reopen this window?

The purpose of that window (or, that tab on that window) is to change the profile. If you start with a document in, say, US SWOP v2 and Assign FOGRA 39 to it, and click OK, you have changed that document so its existing color values are interpreted as FOGRA 39.

If you then reopen Document Setup, the document is already in FOGRA 39. Yes, the Convert button is active, but so what? When you click OK if it converts FOGRA 39 to FOGRA 39 nothing happens. (Nothing would happen in this scenario either, if Assisn were the chosen default for that button. But in (most?) other scenarios Convert is what the user would want, so that is the default. For you, in this scenario, it doesn't hurt, so don't worry about it.)

8 hours ago, thomaso said:

– Where is the Assign/Convert option for in-coming objects? For resources I place and/or paste?

There is no option for that. Copy/pasting always uses Convert. That's why you need to use the method I suggested if you want to preserve the absolute colors when your source and target documents differ. You must do the assignment of the color space in the source, as then there is no conversion needed.

 

8 hours ago, thomaso said:

And what is the application preference doing in Color > checkbox "convert" & checkbox "warn"? I would expect if "convert" is *not* ticked then an incoming item gets the profile just assigned (no conversion > no value change). And I would expect to get a warning message when "and warn" is ticked: Do *not* convert but (and) warn. Both appears not to work, they rather behave like having no function.

Above that you have specified your working color profiles for the various color spaces. Suppose you have said that your working CMYK color profile is US SWOP v2. Then you Open a document that is in FOGRA 39. If the Convert box is checed, Affinity will Convert that FOGRA 39 document to US SWOP v2. Further, if the Warn box is checked it will tell you it has done that. If the Convert box is not checked, the document just opens as FOGRA 39.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

1 hour ago, walt.farrell said:

There is no option for that. Copy/pasting always uses Convert.

Well, I think there is.

This is from Affinity Publisher Help:

To convert the colour space of file to be opened to the current working space:

  • Prior to opening the file, from Affinity Publisher>Preferences (Colour option), check the Convert opened files to working space option.

Options exist to warn that a file's working space will be converted, or that an unprofiled file will be assigned the current working space's profile.

2017 27” iMac 4.2 GHz Quad-Core Intel Core i7 • Radeon Pr 580 8GB • 64GB • Ventura 13.6.4.

iPad Pro (10.5-inch) • 256GB • Version 16.4

Link to comment
Share on other sites

5 minutes ago, Seneca said:

Well, I think there is.

This is from Affinity Publisher Help:

To convert the colour space of file to be opened to the current working space:

  • Prior to opening the file, from Affinity Publisher>Preferences (Colour option), check the Convert opened files to working space option.

Options exist to warn that a file's working space will be converted, or that an unprofiled file will be assigned the current working space's profile.

That applies only to opening a document. It does not apply when copying/pasting between opened documents that have different profiles. (I've tried it.)

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

23 hours ago, walt.farrell said:

Copy/pasting always uses Convert

See, that's where I think some misconceptions shows: The App has to differentiate between objects with colour profiles attached and swatch-opjects (usually cmyk) which are not colour managed aka "source"-values.

A source must never be changed. You should only attach some colour profile, which maybe changes colours at PDF output. 

While designing and copy pasting this should not convert by default, although you may have the option. 

When exporting you would have the option, like in InDesign, to temporarily "convert colours" or pass the values thru (preserve numbers) -> which only applies to swatch colours, not RGB-Images.

  PDF_colormgmt.jpg.dff3a3aef857ff35e1354ea3c3a7495f.jpg 

The ID Info Text reads:

"Colors will be converted to the destination profile space only if they have embedded profiles that differ from the destination profile (or if they are RGB colors and the destination profile is CMYK, or vice versa). Color objects without embedded profiles and native objects (such as line art or type) are not converted, so that the color numbers are preserved."

 

  • Main machine: iMac 2019 (21,5-inch 4k, 6core), 64GB RAM, 1TB nvme + 2TB ssd, running on Mac OS 13;
  • Display setup: 28" 5k Display (primary) + 21,5" iMac4k-Display for studio panels (secondary);
  • Keyboard layout: german apple extended keyboard (aluminium);

 

Link to comment
Share on other sites

On 12/21/2019 at 5:02 AM, woefi said:

swatch-opjects (usually cmyk) which are not colour managed

 

EDIT: I stand corrected from what I previously posted in this space.  A global color swatch in the Affinity designer does in fact retain its values if you convert the color space of the document, and you can see the objects using the swatch shift colors accordingly within the document.  Interesting...  I'm not sure if I like that as a default behavior, but it seems to be what is being requested here...

Link to comment
Share on other sites

4 hours ago, fde101 said:

A global color swatch in the Affinity designer does in fact retain its values if you convert the color space of the document (...) it seems to be what is being requested here

Hm? According to the screenshots of the OP's 1st post a global black got converted with changed values. *That* was the reason for the thread: that it did not work as requested.

Also in my experience a global color does not retain its value with a profile change. Only a global *spot* color does. Unfortunatly a spot color adds an additional channel besides CMYK.

 

 

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

26 minutes ago, thomaso said:

According to the screenshots of the OP's 1st post a global black got converted with changed values.

@fde101 commented about a global swatch keeping its definition if you change the document's color profile.

The OP commented about an object changing its color definition when copied from a document with one profile into a document with another profile.

One is talking about changing the document's definition; the other is talking about copying between documents.

As I understand it, if you assign a global color to an object, then copy that object to a different document, the copy in the new document has a normal color, not a global color.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

4 hours ago, walt.farrell said:

 As I understand it, if you assign a global color to an object, then copy that object to a different document, the copy in the new document has a normal color, not a global color.

Actually, it gets stranger than that.  I just did this in Designer since I happened to have it open, but I suspect Publisher would be the same?

 

I had a simple rectangle with a global color assigned to it.  I copied it and pasted it into a new document that has a different color profile assigned.

In the new document, if I select that rectangle, the Color panel shows the "Global Color 1" assigned to the rectangle - but there is no document palette in the document, and thus no global colors.

Somehow the rectangle is keeping the assignment of the global color across the copy, even though the global color doesn't exist in the target document.

 

 

Based on that, I am forced to agree that there is definitely a bug here somewhere.  As to the global color itself not being copied over to the new document, I would consider that a missing feature.  However, if the object remains assigned to a color that does not exist in the new document, that is definitely a bug.

Link to comment
Share on other sites

  • 4 weeks later...

So, eagerly awaiting the new beta (531) I now tested, and although much was improved (thank you team!) this specific, but critical issue is not resolved!

If this is some sort of new philosophy in handling color swatches, so it be... :(  thou I cannot think of someone keying in specific color values with something in his mind and not be annoyed to later find out they are all changed BEFORE export...

But only, if you make it at least an option in preferences, as I and many others dealing with printing several documents of the same artwork to different targets have to rely on my color values not to change unless exported to the specific medium (which may change until 5 minutes before output).

 

No. THIS IS A BUG.

 

 

  • Main machine: iMac 2019 (21,5-inch 4k, 6core), 64GB RAM, 1TB nvme + 2TB ssd, running on Mac OS 13;
  • Display setup: 28" 5k Display (primary) + 21,5" iMac4k-Display for studio panels (secondary);
  • Keyboard layout: german apple extended keyboard (aluminium);

 

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.