thomaso

This is the first search result * for "assign convert": (* edit: in the pre 1.8 beta forum) 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: 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

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. 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.

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.

Oh, that doesn't sound healthy. Does it crash immediately – or does it seem before to work for a while? (if it takes time before crash: Would you mind to try the folder-rename-way later again, when you have replaced quit a bunch of the resources).

You seem to mix ink standard (ISO 2846-1) and print machine process standard (ISO 12647-2). The ink is not the reason for profiles, ink can physically be standardised. The machines need the profiles to keep the color, in correct density for instance (to keep 100% = 100%) on various machines and papers. There also is a tolerance in this ink standard, inks may vary within certain values – that doesn't need to become corrected by profiles, it's rather a desired matter of regional taste: 80% of the process inks supplied in 2004 complied with the new colour standard ISO 2846-1 within the given tolerances. Although the ISO standard brings process colours under one roof worldwide, differences in taste between different regions continue to exist. These are expressed by the preference in the Far East and the USA for colder colours and in Europe for warmer ones. Such differences, however, lie within the tolerances given in the standard. We can therefore work on the assumption that inks meeting the target values of ISO 2846-1 can be supplied on demand worldwide. https://www.colourstandards.com.au/intro-to-iso/the-ingredients-of-quality-printing/ And yes, that also means that 20% of the inks supplied in 2004 might be out of standard. Unlikely that in particular those suppliers did create profiles to compensate for their lack, since those are rather products of lower costs and quality. By the way: not only CMYK inks are standardised, the more obvious and known as standardised are PANTONE or HKS for print, or RAL for other coloring processes – independent of their ink manufacturer.

There is an industry standard for CMYK inks: ISO 2846 defines the colour and the transparency of printing inks for process printing. (...) Inks meeting the criteria of ISO 2846 are required for standardised working according to the ProcessStandard Offset and ISO 12647 respectively. https://www.fogra.org/index.php?menuid=95&reporeid=59&getlang=en ... and certification of those inks, of cause. If there would be no standard no profile would know what to achieve.

There are many shades of black. Which one does "100k" represent? fde101, it would be terrible if you were correct. That would mean the 4 pure print colors Cyan, Magenta, Yellow and Black could result different when you print a file with 100 % of each color – just by manipulating the 100% values because of e.g. printers profile. Of cause, on 1 material, a 100 cyan swatch always has to print + look the same, like a 100 K, too.

Indeed confusing. In this preflight of a PDF/X-4 both objects get marked as overprinting (different to my previous screenshots with visual separation):

Do you mean this topics issue is just a matter of Acrobat Separations inspector settings? If yes, how comes that the linked .afdesign does NOT overprint whereas the same item as pasted, not linked, does overprint within the same PDF/X-4?

Good point – and quite disturbing. Related to this I noticed that the copied object also gets this overprinting spot color (< colors panel) but without a swatch in swatches panel. That confuses me because in APub I have no way to generate a overprinting color without defining a global swatch (which additionally demands a document palette). Also confusing is the color icon at the opacity slider: it shows as 0 % opacity the color of a previously selected object. (here: the background picture frame) Sure? Compare my screenshot some posts above = this X-4 pdf: Test_ot.pdf

I find the object as linked causes the knock-out. Whereas the same curved text object as copied/pasted from this linked .afdesign within APub does overprint in a PDF/X-4:

Yes, APub's Beta v.523 will avoid that large file size, and probably prevent your issues, too. – Just a quick test: By the way, although JPG is destructive it might be worth to use for print, too. Even a minimal compression (10-15%) causes a massive saving in file size, while its artifacts are rather theoretical than visual. This site gives you examples of JPG compression + file size, just scroll down to an image with an amount of details of your interest and hover over the compression rate 'buttons' to see compression quality & according file size. regex.info/blog/lightroom-goodies/jpeg-quality

For me this issue obviously shows up in your .afdesign file, too, not only on export. I checked in your artboard 2 the affected area (left white end of center bars) and they already do slightly overlap but their overlapping becomes only visible at a zoom level of 5000 % or above. That means the overlapping is so small that it is like NO overlapping at 100% ; with other words: the area of antialising is wider than your current overlapping: As I mentioned before overlapping does the trick: I also achieve a non-flickering result, like firstdefence, when I increase the stripe's overlapping:

The loading process probably is related to the linked resources. The large .afpub size still makes me wonder. I'm afraid I can't help here and we would need to wait for a reply of a Serif moderator. Although this moderator's hint relates to a former APub version: • What file type are the linked images? * One more thought you could check: was the file increasing that way continuously when working on it? Or is there possibly a previous .afpub version in your TimeMachine which is not affected? If yes you could try to detect any culprit object on the pages you created afterwards (possibly with deleting first all "healthy" pages before those). Finally you could open that .afpub with the current beta v1.8.0.523 to see how it can handle your file ( https://forum.affinity.serif.com/index.php?/topic/103864-affinity-publisher-customer-beta-180523/ ) * EDIT: sorry, I hadn't noticed before this info: "Even though all images are linked, its filesize has grown remarkably since I started placing the first image." – That makes my thought above redundant. But it might be a hint that the linked file types do influence the .afpub size.

Hi rayf, Welcome to the Affinity Forums! 100% CPU usage aren't too much, the possible total max is related to the number of CPU kernels in your mac. But the 6.88 GB .afpub file size sound odd and reminds to a former version of APub. a. What APub version do you use? b. How much space is left on the system disk when this .afpub is opened / and how much when it's closed? c. Is this .afpub stored locally, or on an external / network disk? d. Do you have "Save History ..." activated in menu 'File' for this .afpub?

The software must export as pixelated, rasterized document if you choose PNG as export format – whereas it can show your bars as vector objects before export, if you have created them as vectors. Vector objects simply are both size and resolution independent, whereas pixel images aren't. Antialising isn't just a feature or action of the exporting Affinity app but can also be a service by the viewing app – and even by the computer system, mostly appreciated in font/text appearance. If you would not get this smoothing caused by antialising then you would see the resulting edges more jaggy. For further investigation and a closer look at an exported result before export you also could rasterize these objects within your ADesigner document. For now I just assume a normal, physically natural behavior, not a serious error at all. It could help to help if you upload your ADesigner document for a detailed look how the file was created.

Ja, bisher wurden die User-Einstellungen für jede neue Beta-Version weiterverwendet. Dasselbe gilt für Updates der Kauf-Version. Du kannst – "notfalls" – auch Einstellungen zwischen Kauf-Version und Beta-Version übertragen (– es ist aber sicherer, das zu vermeiden)

This disturbance occurs to me with JPGs in native AfPub documents (= no IDLM conversion). But not with every image replace action; unfortunately I couldn't detect yet in what situations it behaves that unwanted way. – However, according to Callum's respond this property change within a picture frame is not APub's expected behavior. https://forum.affinity.serif.com/index.php?/topic/103051-linked-image-update-command/

For me it works. Here so far Affinity Apps did run in various versions, all APub betas included. The only limitation which I got responded by Serif as macOS 10.12. (Sierra) related bug is the reliable crash on "Save As..." without changing the file name when using 'Separated Mode'. Also I experienced that it can avoid issues when I reboot the mac after an Affinity app install. Could you add/upload a console crash log (as file, not text) to your first post?

Thanks for discovering and reporting that difference. I only had noticed the lack of the preflight panel: https://forum.affinity.serif.com/index.php?/topic/103883-preflight-panel/&amp;do=findComment&amp;comment=559074 'Separated Mode' (and in particular two monitors) still appear less supported in Affinity. Feels a little like discrimination of disabled users - whereas the disability here is the existence of a second screen, like a third eye

No, not a battle, I just don't see dis-accessibility in the increased pinning panel text fields. The overlapping button is rather a localisation issue. (... I just want to avoid a respond like "by Design" for both panels )

A_B_C, yes, but rather a cosmetic issue: the partially covered button in the German version at least can be read via its tool tip: So, in both your Pinning Panel examples you have access to all UI items – different to my experience above with the Paragraph Panel. I don't mind at all the extreme width of some fields if they would show all UI items – like they do in your screenshots: >>>

Walt, thanks for this hint – I hadn't understood the term 'modeless' before. A quick check with some mac apps shows that the "Open..." * window usually is modeless, too. But in all cases it doesn't have the three dots in the upper left corner (but a Cancel button), is resizable, and shows the command File > Close as grayed out as long this window is open, in some apps then even the entire File menu items are grayed out. * in v523 the current use of File > "New..." seems to include the "Open..." options, as kind of a substitute.

I think the File > Close command in no mac application is used to close a dialog window. Instead those windows have a Cancel button + the red dot in the upper left corner. So I would expect the File > Close command to be grayed out (= not accessible) as long the dialog window "New..." is opened – or, at least, just not to react, like it currently behaves when File > Export was selected and its window still is opened.

Du musst nicht ausdrücklich warten; die Beta Version ist voll funktionsfähig, du kannst sie verwenden wie deine Kauf-Version. Wenn sie besser funktioniert (also bugs der Kaufversion beseitigt hat) ist es natürlich sinnvoll, die Beta zu verwenden. Zudem hat die aktulle Beta eine Preflight-Funktion, die evtl. Probleme beim PDF Export entdecken hilft.