Peter M Dodge

Yeah, I get Publisher and Designer mixed up all the time. Sorry about that. I meant Publisher.

While I have indeed run into that particular fun issue, I don't think it's the case here. Untouched text boxes will still have that issue. I think what's happening is it's erroneously applying some supposed default style, instead of the styles specified in the TOC window.

I am composing a book on behalf of a client where I am attempting to use the TOC function to automatically generate the tables of contents. This table of contents goes over two pages, so it is placed in a text frame that overflows onto the next page. Whenever I regenerate the TOC, the first page is the correct styles and formatting, however, on the second page, it has added a bunch of superfluous style overrides, making the text super large. I then have to go throw and slowly remove all of it - slowly, as Publisher does not allow me to select everything including the overset text this generates. This seems like a bug, though I'm not sure what's causing it. There are no text styles in the document with text as large as this. I am unable to share the document directly as it is copyrighted by the end client. However, if there are any diagnostics you would like me to try, or suggestions you may have, I'm all ears.

What I'm meaning to say is that, even with an embedded profile, some browsers will disregard it if it "thinks" your monitor expects another one. For example, Safari on most but not all Apple devices will force it to Apple RGB. However, for best chances, make sure the ICC profile is set to your target one. Beyond that, you cannot control it if software disregards your set profile in favour of another. It's out of your hands at that point. Your specific issue seems to be some sort of conversion at your provider's end though; you might consider asking them if there is a way to override or discard it. To expand: What I think is happening here is that the web service you are using is re-encoding your image. When it is, it either is discarding colour information used by the profile (causing the browser/OS to use its defaults), or transcoding it to their own preferred profile.

Compression in images will introduce colour issues, because the compression often "shorthands" the colour information within the file; webp as a container format is especially notorious for this. (Such as the bug linked above) Web colours are not a particularly reliable method of practical colour management; most browsers will render any web colours not in CSS differently. For web, you're better-suited working just in RGB directly and embedding the profile. Even then, some browsers will discard this profile. Unfortunately, the degree of precise colour management you'd have in print is not as viable online.

Adobe will, in certain circumstances, override embedded profiles. There are also situations where it may assign a different prodile than actually written to the file. If you have a test file this works on, I could see if that's what's happening here.

You may also want to check that there isn't an object "above" the layer you are trying to select that overlaps it. In the case such an object exists, you may end up selecting just the overlapping item, not the item you are trying to actually select.

Yes, that seems to be the function that does what I was looking for, though I never would have guessed that from the names. I'd agree the names of these functions could be clearer. Yeah, if I had to do this over again, that's definitely the route I will take. In attempting to make sure this wasn't just an Affinity quirk, I took the text into Corel WordPerfect, Adobe InDesign, and OpenOffice, and all of them had very different style interpretation problems. So Word has definitely done something very weird with the formatting. I suspect what has happened is whenever something was copied and pasted within word, "segments" were created in the document which it sectioned off the formatting in. I don't really have a way to test that hypothesis however.

@Old Bruce Indeed, with the benefit of some hindsight I would have prepared the styles in Affinity Designer ahead of time, though it's still a bit of an onerous task to go through a 200 page manuscript to replace all the inline character styles. Ideally what I would have done in this case is destroyed the formatting entirely, ie set all the text to the same style, and then reapplied everything, much in the way you are suggesting. However, when I attempted to do that I was finding a lot of things that still do have formatting in spite of my attempt to clear it all. These individual overrides were retained. In Adobe InDesign there is an option to clear all text overrides that, while a scorched-earth approach, was in line with my approach here anyways. I prefer not to use Adobe for a variety of reasons (my many hours in Illustrator are punctuated with at least that many expletives), but it would be nice if the expected behaviour of "resetting the styles" mirrored this actual "clearing" of the overrides as is present in Adobe; or, in the alternative, if a clear option was thus presented. If there is such a thing, I missed it; resetting the styles is as close as I could find.

I found this thread trying to diagnose my own problem. I was able to figure out what was happening. The expected behaviour is that all formatting is removed from the text when using "Reset Formatting". The actual behaviour is that it removes all paragraph and character styles from it. This is pretty much the inverse of the desired result. I am currently typesetting a document provided by an end customer in word and the text formatting is a mess in it, largely due to Word, so I was trying to take it into an actual composition program and correct it and clean it up. Instead of applying styles, Affinity applied the text styles as individual overrides, compounding the problem. What I was looking to do was discard all these individual overrides, and apply specific paragraph and character styles. However, what I end up with is a series of disjointed and inconsistent formatting, because it does not discard these individual overrides. You can get around this by specifying paragraph styles within an inch of their lives and then applying them liberally, but this is not appropriate for mid-sentence emphasis, for example, and character styles do not seem to fare as well. That this seems to be a three-year-old issue is troubling.

For what it is wirth, the one time I have run into this problem is when using fonts downloaded and licensed from Adobe Fonts. While I cannot prove it, I believe that this is as a result of DRM (digital restrictions) placed on the font to prevent them being redistributed. In elementary terms: I believe Adobe is using a proprietary method of storing these fonts that makes them unavailable to the OS (I also cannot use them in MS Word, Corel WordPerfect or Corel Draw, etc).

I would not find rasterising the file to be the solution here. First of all, any pantone spot colours will be lost when they are rasterized. Secondly, converting from vector text and images, to raster text and images, removes any ability to losslessly resize the document to a larger size. I wouldnt call the current method particularly egregious, but I will say its frustrating to have Illustrator do this so effortlessly when Affinity makes it trouble some in a pain. In Illustrator, a certain key combination when placing them will fill the document with placed pages of the source PDF, and create additional pages where neccesary. Meanwhile as it presently is in Affinity, I must copy the paste frame and manually change the page number - unless there was something I missed?