PixelEngineer

Hi still having this same issue . . . Hello, I am currently working in v 2.0.4 and am still having the same issue with the Color space info description in Resource Manager not updating properly when converting a graphics color space using a particular method. When using Affinity "StudioLink" as a method in editing a linked image in Affinity Photo and converting the image to another color space using Affinity Photo, the saved image's actual color space does actually change but the description is not updated properly in the Resource Manager dialog revealing a mismatch between the "ICC profile:" description and its "Color space:" description which is incorrect. See image posted on December 26, 2022. There appears to be something wrong in the code that is causing the "Color space" description in the Resource Manager not to update. It is still working in Affinity v 1.06.1665 but not working properly in Affinity v2.0.4. This needs to be updated to give the users proper info and would be great if this can be fixed in a near future update. Thanks.

Hi, I just wanted to share article in case you haven't seen it. Perhaps it may be of some help. Display Colour Management in the Affinity apps - Affinity Spotlight

The reason why I was posting this because I didn't see any problems working in Affinity v2 natively and was thinking that the title descriptions of bug in v2 was not accurate. I thought it was working but was thinking that it was designed based on a different orientation. Sometimes there can be misunderstanding of the actual problem. However, now I see that this had to be fixed and that update will not impacting my work in anyway. Serif has great product and I really appreciate the work that your team does. Looking forwarded to the updates.

Yes thanks I understand now. I was posting exactly the same time you responded.

Hello @Pyanepsion, in regards to the question I was wondering if this occurred when opening the document from within v2 or if copy and paste was used. I decided to run more tests and now see a clearer picture of what is going on. So the question is irrelevant now. I have moved on to using Affinity v2 for my production workflows and didn't understand why there was a bug being reported in the decorations since the values looked normal working natively within the application. Edit: I just saw the moderator post as I wrote this. So that answers my question. Thanks.

Hi, @MikeTO thanks for pointing this out. Ironically, as you saw in my post, the values that I used had no effect. After applying changes based on your description I now see it. So it seems that this issue occurs only when opening v1 files into the major upgraded v2. Is that correct? In my experience, Affinity Publisher v2 decoration Edit: seemed to work correctly when designing files natively from scratch in version 2 while showing the correct numerical values. Opening a copy of a design in a new document within the same version of the application will not present any problems in both version 1 and version 2. This seemed to contradict the title description. In any case I did see the problem now. Thanks again for point that out I wasn't aware of that.

What is the workflow that you are using?

If you squish that InDesign text frame you will get the exact same result as you got with the Affinity text frame in your examples, its no different. if you drop a 30 character word in that same InDesign text box words will get broken in InDesign. As you see here there are no issues. Affinity Publisher gives the designer total control in this regard.

I am not able to duplicate this problem on my end. Hard to tell what is happening without looking at the original file. I did create my own test document in Affinity v1 and I opened that same file in Affinity V2 which gave the normal warning about opening legacy files. Despite the warning, the appearance of the graphic looked identical to its original form with the decoration values matching. I was also able to save the file as a v2 version with no problem. Affinity v1 and v2 with the same file open (notice read only ). This particular file imported with no surprises in v2 other than a warning of opening legacy files.

I am not having any problems with this in v2.0.3 Edit: I just noticed also that in your snapshot that the application is in Beta. I am working with final v1 and v2 versions.

I agree.

When you design your text box to fit Donotbreakthis the word will be pushed to the next line. It will not break unless you break that rule.

It will not extend horizontally because you planned your design.

The word will break up when it does not fit the maximum character length design of the given text box. Design the text box width to accommodate the word that contains the most characters in the database for that field. When this is done, your words will not break unless you break this rule. To accomplish this you will need to go into your database and find the largest word that exist in that field and then plan your design. I ran some simulations and the words did not break when following this method. Preflight will also notify you if the text extends below the base of your text frame. You can check 'preview with record' and look on the bottom left of your screen to see if there are any errors before compiling.

Yes it appears when the word is truncated on my Windows machine. And also appears past the edge of a page.