Jump to content
Ecifircas

Symbol synchronization - text unlinks after color change

Recommended Posts

1. Create symbol containing text

2. Stop synching

3. Change symbol colour

4. Reactivate synching

 

> Expected behavior: Everything except the color should be synching.

 

> What happens: Text no longer synchronizes across instances.

Share this post


Link to post
Share on other sites

Hi Chris,

 

This is happening with any color.

 

I make a symbol containing a rectangle and text, uncheck sync, change the colour of the whole symbol an recheck sync. Hovering over the rectangle now shows "Unlinked Attributes: Fill" while hovering over the text shows "Unlinked Attributes: Text".

 

In other wordt, when trying to unlink the color of text, it unlinks the entire element rather than just its color.

 

Cheers :)

Share this post


Link to post
Share on other sites

Ok i see. I hope you add it someday because integrating text behavior in the same way would be more consistent and useful in quite a few cases. But it's just a small thing and I can imagine you might have other priorities :)

Share this post


Link to post
Share on other sites

For what it's worth, this is somethign I'd like to see change too, one day. Tomorrow would be great, hahaha! ;)

 

The current behaviour is a problem when you have to reverse your design, placing back text on black background, or build a grey newspaper ad and want to adjust your text colour for optimal contrast: Red should be replaced by black, and yellow by white, or black, depending on background colour. With the current functionality, we need to build two versions of the symbols, which defeats the purpose.

 

As is, we can cheat the system by applying a Colour Overlay effect to the text layer. However, using effects on text means that it will either be rasterised when exported to a PDF, or, if you specify Nothing to the Rasterise option in the export setting, could produce unexpected results such as Pure White that becomes 60% black (0,0,0,60) or Registration Black (100-100-100-100) that becomes 51% black (0-0-0-51).

 

On a user perspective, I think that Ecifircas first post is what we'd expect to happen. It surely would be more practical :)

 

 

 

 

 

Share this post


Link to post
Share on other sites
On 2017-10-10 at 6:29 AM, MEB said:

This is working as intended (by design) for now.

 

I'm still looking for a case where that functionality could be useful, but that aside, I found some two workarounds. They are definitely not ideal and each have major drawbacks

 

I'm still looking for a case where that functionality could be useful, but that aside, I found some two workarounds. They are definitely not ideal and each has major drawbacks.

 

Workaround 1 : Convert to curves

1 - Duplicate the text layer.

2 - Hide the original text layer — It will be hidden on all instances. Keep it so if you have a master to edit later if needed.

3 - Convert the new layer to curves — You will be able to change this colour while sinking is off.

 

Pros : 

That produces a clean output files (PDF), keeping your text (curves) vectorial and allows you to control the colour value when exporting.

Best practice for print material and vector output.

 

Drawback :

If you need to edit the text, you'll have to delete the duplicated layer (The curves), turn the original text layer on to edit your text and redo the procedure above, including any colour adjustment you made per instances. Not great, but at least the rest of the symbol is still intact and sinking.

 

Workaround 2 : Colour Overlay Effect

 

Simply add a colour overlay effect to the text layer. That can be changed per instances.

 

Pros : 

Simple and it keeps the full flexibility of symbols

Best practice for raster output (JPG, TIF, PNG, etc.)

 

Drawback :

Unreliable for printing. There is no way to output the text properly for printing in a PDF file. The text gets either rasterized, or you have to push your luck with transparency attributes which can produce unexpected results (I have seen cases where white turns to 60% grey, and rich black turns to 51% grey). I don't know how different printing RIP software will interpret the transparency either, that's always a hit and miss scenario.

 

Trick: 

If you have a mix project, with black and white, print and digital artboards. It's best to start with the printed items. Especially for newsprint B/W ads where your text is likely to become 100 black or pure white in order to have a clean printout. You want this text to output as vector, not raster. Yellow text on a dark background, for example, would print better in white. So it's best to create your symbol in white and apply the Color Overlay effect to the digital instances where it does not matter if the text gets rasterized. Also, if you have a small run of posters printed on a laser printer, the output is usually acceptable too. In short, build your original for the variations that go on a press, and apply the effect for everything else.

 

Edited by arkinien
Added a trick to one of the procedures. I think it's best to keep all the info in one consistent instruction set than to add a disjointed new post.

Share this post


Link to post
Share on other sites
12 hours ago, arkinien said:

 

I'm still looking for a case where that functionality could be useful, but that aside, I found some two workarounds. They are definitely not ideal and each have major drawbacks

 

Hi arkinien,

It isn't about being useful. It's just a part of the code that's still needs to be expanded/implemented.

Symbols can become quite complex when nested/mixed etc. We need to ensure they work flawlessly before moving things forward.

Share this post


Link to post
Share on other sites

Thanks for the clarifications, it makes sense.

 

I must have misinterpreted the "by design" part. Often, software developers have to decide if a function will operate a certain way or another. For example,  dragging a window could select everything completely within the window, or anything crossing it. Sometimes, we are so focused on a specific case that we don't see how a behaviour could be useful in a case we are not aware of. Both have advantages in specific situations. (I know Affinity does both, thanks for that, but that's the first example that came to my mind). So I think I was looking for that case where that specific text behaviour could help me. I understand that sometimes, developers need to purposely sacrifice some functionality in order to keep the software working properly, or on schedule.

 

Hopefully, one day we'll be able to adjust text attributes in Symbols independently. :)

Share this post


Link to post
Share on other sites
On 2/2/2018 at 4:12 AM, MEB said:

 

Hi arkinien,

It isn't about being useful. It's just a part of the code that's still needs to be expanded/implemented.

Symbols can become quite complex when nested/mixed etc. We need to ensure they work flawlessly before moving things forward.

This seems to be true for other software, also. I remember Sketch, when it had still newly introduced symbols, had a similar amount of bugs, some (mis-)behavior was similar to those in Designer, now.

Although, it would be reassuring to see a listing of the known bugs

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×