lacerto

At export time, uncheck the "Embed ICC profiles". You might also uncheck "Embed metadata" though it has only a minor effect: Typically, when exporting, you might want to have the document color space already the same as the target so that there is minimum of recalculation of color values at export time. So if you are going to produce only for web, you would have the document color mode set to RGB/8 and color profile set for sRGB and just export without embedding profiles.

The actual size effect measured in bytes may be small if it is just a tag to sRGB, but it is all relative and depends on details. Left: AI/PS 4,989 bytes Right: AD 8,896 bytes (neither one contains profile or meta data). As PNG is not lossy, Adobe simply just compresses the image better. Whether this matters depends on the amount of these kinds of images, and how massively they are transferred. The effects of including profiles and meta data: If profiles are device dependent (basically inadvertently included, in case the intention is to produce for web) the effect can be hundreds of KB per image (above including a device profile that does not actually contribute anything to image colors or quality causes just dead weight of 173KB per image). So if the size is the primary interest, of course all these considerations are worth taking into account. As PNG has no lossy compression methods, there are not too many factors. One possible method to achieve smaller file size is using indexed PNG, but there what is won in size is often lost in quality: Indexed PNG, left PS size 2,799 bytes, right AD size 8,103 bytes.

...and here is the short version (that counts a hyphenated word as a word on the next line). It works even if it shows "inadequately" the found instances [not actually since the preceding space is selected and when marked non-breakable is enough to bind the preceding word, but does not prevent hyphenation]: shortversion.mp4 (As above, Windows 11 Pro, APub 2.0.3; I have tested 1.6.10 version, Win, too, and it works similarly; I have not tested macOS versions so far.)

Beats me (Windows 11 Pro, v.2.0.3): longversion.mp4

Odd, I just tested with v1 Publisher document and both versions appear to work: regex.afpub Both versions also work in ID CS6 as RegEx styles. But as you mention, the long version does not work in RB.

By clicking the Sample from Cursor buttons (separate for each sample point). The location samplers still exist and can be reactivated by re-clicking them.

I think these discrepancies are basically results of Affinity apps handling colors (including grayscale) based on HSL, so if you change the color model of Color panel to HSL and use the Color picker tool (even with "Point 1x1" ratio) to sample intensity values, you would get exact readings (100, 95, 90, 80, etc., but "reversed" since they are light values rather than pigment values), while the K value of the Info panel would still show something like 51% or 91% (that is, inaccurate conversion values). NOTE: I am referring to the converted TIFF file that I attached in my previous post.

Personal preferences vary of course. I prefer a style toggle, not anything hard coded. The style variance can also control hyphenation, without touching hyphenation settings [besides: alt formats can be handled by alt styles or simply as local overrides if not applied consistently].

I still played a bit with this. I am pretty poor with regex, but noticed that there is a useful difference between the two versions: I had picked the first one from the Internet so not my "own work". I am not sure if the syntax is correct even if it works. When I put it in Regex Buddy, it explains it as follows: Assert position at the beginning of a word (position followed by but not preceded by a letter, digit, or underscore in the active code page) Match the regex below and capture its match into backreference number 1 Exactly 2 times You repeated the capturing group itself. The group will capture only the last iteration. Put a capturing group around the repeated group to capture all iterations. Or, if you don’t want to capture anything, replace the capturing group with a non-capturing group to make your regex more efficient. Match a single character that is a “whitespace character” (any space in the active code page, tab, line feed, carriage return, vertical tab, form feed) Between zero and one times, as many times as possible, giving back as needed (greedy) Match the regex below and capture its match into backreference number 2 Match a single character that is NOT a “whitespace character” (any space in the active code page, tab, line feed, carriage return, vertical tab, form feed) (matches no characters outside the system code page) Between one and unlimited times, as many times as possible, giving back as needed (greedy) Assert position at the very end of the string The parts in red are marked with red [i] warning tokens in RegEx Buddy -- I used syntax boost::regex (1.66-1.77) -- I have no clue if that is the version that is the most appropriate in context of InDesign and Affinity apps (I have noticed that the two are not fully compatiblem though). Any ideas? Anyway, both options are useful (both examples allow hyphenation and have identical hyphenation settings).

It is likely that Affinity saving routines by default embed the sRGB profile which is normally "assumed" if omitted, so just dropping the profile might give you what you expect.

It is related to the original file probably being viewed as a grayscale image using Dot Gain 20% profile (which might have been the default grayscale profile in your Adobe environment). Affinity apps do not come with equivalent grayscale profiles but can use them, though. I attached below a conversion of the original RGB file to grayscale/8 TIFF using the Dot Gain 20% target but saved without a profile. When you open this in Affinity Photo, it will by default assign it with the D50 profile and view it as a neutral Gamma 2.2 image, and you should get readings that in K scale show the expected values (give or take the rounding errors). half letter 3-step tab test_dotgain20.tiff Note though that if you open the original 16-bit RGB file in Photoshop and use the K-scale to read the values, you will get similar values as in Photo (ones you mention in your post) also in Photoshop. The file may have been inadvertently converted at some point, explaining the differences.

It is not that useful in English (as prepositions and articles most often give you balanced wrapping even when not using hyphenation). In languages like Finnish it is a different thing as there are practically no prepositions nor articles, and compound words are written together without a space or a hyphen. In texts where the publisher is likely to comment e.g. English hyphenation, it would be a kind of a professional suicide to use paragraph composer, since correcting one point typically causes immediately multiple points that potentially require correction...

Yes, we have (mostly in vain) tried to base our non-two word exceptions on these kinds of typographic "excuses"! But first line indent definitely makes the gap worse, and is probably the prime cause for this "rule of thumb", expanded into a categorical rule.

I must quote this next time I am asked to do something like in my first example (trying to show my "case" with long words, abundantly available in my mother tongue), that is, categorically including two words no matter how long

So you two are telling what is and what is not relevant in discussion and implying that I am not welcome as a participant in this discussion of yours? As you both are addressing these silly comments to me, there seems to be some ontological problem. Did you know that you can ignore users that constantly annoy you?

Here is my take, I'll bet it is deemed too straight forward on this forum even if it IS a work around. I suppose it is not off-topic, though: implications_of_forced_two_words.mp4

Is that a royal we? Of course there is point in showing implications of a feature that is wished to be automated. Even if it were available, it would often work poorly within Affinity apps because it would inevitably cause issues with word wrap, unless there is a counter-measure like paragraph composer that alleviates problems caused by forcing at least two words on the last line of a paragraph. That is, automation in one region requires manual adjustments in another (typically with manual hyphenations or prevention of hyphenation of single words, until balanced wrapping is reached). I really cannot see the point of policing around the arena and trying to dictate what exactly belongs and what does not belong in the scope of each topic.

I can see that you cannot see 🙂 My example uses identical spacing settings and forces at least two words on the last line (it does not use forced line breaks). The difference is that InDesign uses paragraph composer to calculate even spaces. There is no such feature in Affinity apps. Here is a clue: top paragraph uses Adobe Paragraph Composer, the bottom paragraph Adobe Single-line composer. See the difference?

Even if GREP-controlled wrapping were possible, I think it would require that words are wrapped as per paragraph (rather than per line) to get even spacing:

In the context of PANTONE policy change, it is not likely that they are willing to distribute up-to-date color data, or even legacy or fractional one (the kind included in Affinity apps) in color profile independent formats like L*a*b, and especially in kinds of open database formats as .csv (= the format in which Affinity apps distribute their PANTONE data). L*a*b based PANTONE data has always been information that is distributed selectively, but at the moment it is something that the company guards vigorously and only allows spreading in pieces and via controllable channels (e.g. by way of PANTONE Connect).

I do not think that there is, but depending on the kind of the publication, you could make the K black darker by using a Soft Proof adjustment (which would need to be applied as per object), or simply just defining a global swatch called e.g. "Black", and initially define it as a four-color-black (or even RGB 0, 0, 0). That would then show black while you work, but when you create the final export, you would redefine the swatch as K100. In the screenshot the left side lower blacks (rectangle and text) have SoftProof adjustment for PSO Coated v3, which makes them regular black. On the right hand side the equivalent elements have been assigned with "Black" swatch. The upper elements use just K100 from the Color Panel and are a bit brownish (as you mentioned). UPDATE: The custom "Black" basically emulates the {Black] swatch of InDesign, which automatically outputs as RGB 0, 0, 0 when exporting to RGB and K100 when exporting to CMYK. Additionally it kind of "resolves" the appearance of black issue. A poor workaround, all the same, but probably the only kind that there is available to emulate the InDesign kind of variable multifunctional context black.

Sometimes of course it is ideal to be able to simulate the printed inks (to the extent it can be done) and in those cases Lab representations (and a wide-gamut display) are the best choice (that is, if the app also can show them; I think that Affinity apps will always limit display of spot colors within sRGB, even if the document color space is a wider RGB gamut space; when working in CMYK color mode -- typically with still more desaturated colors -- this is quite restricting and also unrealistic). It is also valuable to be able to simulate the difference in typical client screens and wide-gamut print. But most often it does not much matter, and special "inks" like varnish of course need to be faked anyway. EDIT: To be exact, it is the document color space (within Affinity apps) that defines the gamut of the spot colors, so their gamut is not inherently limited to sRGB. But inbuilt PANTONE library colors are (in Affinity apps, but not e.g. within Adobe apps, where definitions are L*a*b based). But if custom spot colors were defined using a wider color gamut than sRGB, this color space would be used provided that the current document color mode covers the gamut.

This is to shed some light to darkness... I share this to help present Adobe users to be able to deal with misinformation that is spread on the Internet, also on this forum. Whenever spot swatches are used, they typically have a reference to the library color (so that their meaning is clear whenever separated for print). It is a simple matter to reassign colors to them (in case their original color representation is broken). The color representations do not need to be accurate but the following video clip shows how sRGB representations can easily be picked by using the PANTONE Connect Plugin also when using a free PANTONE account: dontpanic.mp4 Missing non-spot colors would simply just be resolved to their standard composite colors. The files containing library spot colors can still be placed and exported for production even without proper color representations (dependent on missing libraries), so they would be shown in grayscale e.g. in InDesign and Adobe Acrobat: I hope this helps to get a bit firmer grasp on what the notorious PANTONE change means. As mentioned, most users probably just continue using legacy libraries (they were warned about the forthcoming change for about a year before it happened and should accordingly have realized to create backup copies). The legacy libraries will most probably be available from various other sources, as well, some of which no doubt a bit dodgy. But as shown, the missing representations can be retrieved in sRGB relatively easily, and without extra cost. The mapping might become easier once there is a proper PANTONE plug-in. Scripting tools could also be used to automate the task. UPDATE: In addition to what is said above, it should be noted that all pre Nov 22 created Photoshop files with PANTONE colors will open non-disrupted in Photoshop post Nov 22 versions (so the disruption will only affect Photoshop files with most but not all PANTONE book colors used in Photoshop files created in post Nov 22 versions). So the situation demonstrated above on the video would not happen when opening a PSD file containing these colors in a file created in pre Nov 22 version of Photoshop [I confirmed this with one created in PS2002 and CS6], even when opened in a Photoshop version dated from Nov 22 or later that no longer ships with .acb libraries. Similarly all InDesign and Illustrator files containing swatches from PANTONE color books will open and are placeable as before, without disruption. In a nutshell this means that disruptive behavior has been reduced to the minimum. https://helpx.adobe.com/photoshop/kb/pantone-color-books-photoshop.html https://helpx.adobe.com/illustrator/kb/pantone-color-books-illustrator.html https://helpx.adobe.com/indesign/kb/pantone-color-books-indesign.html UPDATE: As of Feb 24 2023 PANTONE Connect plug-in seems to allow direct addition of any spot color as a Photoshop channel, using a free account, so one nuisance less. Direct creation of swatches however still requires a PANTONE subscription.

Yes, I have had a free account about forever as I have purchased a dozen or so printed libraries in the past, and also have X-Rite calibrator and free PANTONE Color Manager (now a legacy app). But this is irrelevant, any user can create a free account and get the benefits of the basic account mentioned above, and more specifically here [benefits of the premium account are truncated in the image but what is included in the free account is shown in full]: If you asked specifically about PANTONE Connect Plug-in for Adobe apps, yes, its basic usage (similarly as in context of web browser) is free of charge. No one would probably even purchase it as it is a legacy add-in, its UI is poor and full of sales clutter, and it has duly been rated at 1 star (as zero is not possible) on Adobe CC plug-in section.