Lagarto

That is an interesting question and one that could be elaborated a bit here. I do not have Illustrator CC but just for the sake of interest ran a quick test in CS6 to produce an antialiased raster image of the same picture, and then a radial gray gradient from both Illustrator and Designer, and got the following: Things have probably changed in Illustrator but as can be seen it produces RGB 96, 96, 96 as a middle gray (so darker, not lighter) between the black and white (instead of RGB 127, 127, 127 shown in Info color picker used for the equivalent AD produced image), and when producing a radial gray ramp, it has much more dominance in darker tones than Designer, which I think is correct, as the human eye can discern better differences in dark tones than in light, so grades are much lost in the lighter tones if gradience is applied linearly. But I have no idea whether what Illustrator does is applying an sRGB curve for the radial gradience. But Designer seems to do just linear gradience without any kind of adjustment? I could reproduce what you mention above about Photoshop when converting a 32-bit middle gray to 8-bit sRGB using the default HDR Toning scheme of Photoshop. I wonder if Illustrator CC has today similar tools when producing bitmaps from vectors. I'd imagine these kinds of settings are quite important in UI design where there is need to render to small sizes like 16x16px complex graphics containing gradients and transparencies. UPDATE: I realized later that Designer does just the same as Illustrator when the document is in 8-bit color format, so no point in that comparison. As Designer allows direct export from 32-bit document color mode to 8-bit raster formats, it would really be quite useful to have gamma adjustment control in context of export.

Yes, placing an Excel sheet will create an Affinity table also on Windows, so there is no text ruler associated with text contained in cells. You need to enter a tab character in a cell by placing a text cursor within a cell and choosing Text > Insert > Spaces and Tabs > Tab (or copy paste a tab character), and then use the Tab Stops section of the Paragraph panel to specify the positiona and alignment of the tab stop.

You can get easy and perfect node snapping if you first select all affected curves and then enable snapping to nodes of selected curves (see below "Align to nodes of selected curves" icon): None of the object snapping features need to (or should) be turned on. After that, you get perfectly aligned nodes very easily (no need zooming in and no disturbing snapping to anything else): ...after which you would fill the polygons and just set stroke attributes to none.

Do you mean specifically placing (File > Place) an Excel table? This kind of table is imported (on macOS) as an Affinity table so you would need to add tab character manually (Text > Insert > Spaces and Tabs > Tab) and then specify using the Paragraph panel's Tab Stops section the alignment type (Decimal) and position of the decimal tab wihin the cell. This kind of table does not have text rulers. On the other hand, if you paste an Excel table via Clipboard, a different kind of simulated table is created which constists of text frames placed within a grid (on macOS; on Windows this would be a regular tab and paragraph break separated text flow). These text frames do display text rulers which you can use to add tab stops. You would need to enter a tab character manually similarly as above.

The standard procedure to lower the TAC to the desired level when using commercial press would be using a color profile created for the specific stock. E.g., here an image that has darkest tones around TAC 320 (values shown as implicitly converted from RGB to underlying default CMYK profile ISO Coated where RGB 0, 0, 0 is converted to TAC330) (Photo by Pierpaolo Lanfrancotti | unsplash.com): Here is the CMYK histogram with the underlying ISO Coated v2 (ECI) that allows max TAC330 (compare it below with the histogram of the ISONewspaper-based conversion and see how the component inks have been adjusted): After the image has been converted to CMYK using ISONewspaper26v4 as the profile, the darkest values are around TAC220: This method is a sound starting point. You could then adjust manually the image if the profile conversion seems somehow unsatisfactory (e.g. if there are narrow streaks of light that are in danger of getting lost when printed, contrast could be increased; or if an important part of the image gets too desaturated, the area could be locally changed while keeping the colors within the TAC limit). This is much more effective than playing with channels or HLS controls and trying to do manual adjustments. For most images, color profile based conversion could be applied automatically at PDF export time: if color is critical, it is best to process such images beforehand in Photo.

Yes, I noticed it also with R C-R's example.

Affinity apps do limit TAC when performing color conversions at PDF export time, which can easily be seen if the attached.afpub document with ISO Coated v2 (ECI) (basically a TAC330 profile) as the document profile is used to export to e.g. ISO Coated v2 300% (ECI) (TAC limit 300), or ISO Newspaper26v4 (TAC limit somewhere around 230). a) No profile conversion, so no TAC limit: b) Conversion to ISO Coated v2 300% (TAC limit 300%), mouse pointer at the intersection of CMYK circles set to overprint, so defined TAC 400, actual coverage 273%): c) Conversion to ISO Newspaper26v4 (TAC limit somewhere around 230%), mouse pointer at the intersection of CMYK circles set to overprint, so defined TAC 400, actual coverage 178%): I have no clue whether color reduction methods like GCR and UCR are properly applied but when I exported an equivalent test file from InDesign using the conversion option to not preserve colors, I got nearly identical results both for TAC limit and color values of overlapping overprinting CMYK circles. When the document profile is not changed, TAC limit is not applied (if the color space is the same, but e.g. for RGB images that are specified to be converted to CMYK, it would be applied), but that is as it should be (and this is how it is also when exporting from InDesign). In Affinity apps it is not possible to switch color profile at export time without causing remapping of colors and applying TAC limit, in InDesign this is possible if "Preserve Numbers" conversion option (the default) is applied (in which case the target profile is simply just assigned). So it would appear that it is technically possible to e.g. convert to TAC240 limit profile without making changes to the document objects, but whether this can be successfully be used e.g. for jobs without a proper ICC target or recommendation (or when stock is not close to one for which the ICC profile was initially designed) is of course unsure, so especially for images I would prepare conversions separately and preview the changes and adjust if needed (manual ajdustments are often needed anyway when printing the same document for highly different stocks so we practically always prepare separate version e.g. for newspapers) . tac.afpub tac_isocoated_330_w_imageconversion.pdf tac_isocoated_300_w_imageconversion.pdf tac_isonewspaper_w_imageconversion.pdf UPDATE: As shown in the demo, doing on-the-fly color conversions is not recommended if the user has no clue what happens in the conversion. E.g., K100 definitions (typically text) will be converted to rich black unless the black is specified as a spot color, and such arrangements are not necessarily ok by the printer and should at least be negotiated before delivery. So if a publication has objects or images that exceed the recommended TAC, and the recommenation is as low as 240, it is definitely better to always prepare manual conversions and color definitions, if color is at all critical for the job.

If you'd have this kind of situation (separate polygons aligned by their definining nodes and having stroke colors defined): ...then you could swap stroke and fill colors shape by shape by clicking the black curved arrow button in the Color Panel (or by pressing Shift + X), but I think you'd need to do that for each shape separately. I do not think that there is a shortcut for just copying fill color from stroke or vice versa. But you could have a copy of colored outlines placed on top of colored fills to have both.

I am not sure if I understood your technique or what you are trying to achieve, but if creating perfectly aligned polygons, there might be point (so far in lack of Illustator kind Shape Builder Tool) in creating them by using Boolean tools (e.g. adding, subtraction, intersection and division). On the other hand, if you need to align separate already existing shapes manually, line segments are best aligned by using nodes, so I would just align the polygon shapes using the node alignment, then define fill colors for each separate shape and finally select all shapes and remove their strokes. But if you already have aligned abutting shapes visually by their (middle or outside aligned) strokes, or if you need to have shapes partially overlapping each other, it might make the job a bit smoother if you first define colors for the strokes, then expand them in one go (Layer > Expand Stroke), then separate the strokes (Layer > Geometry > Separacte Curves), and finally delete the redundant residue shapes from the middle of polygons.

I am not sure if I understood what your problem is but you can have decimal tabs both in tab-based table and a true table. a) Tab based table (here you specify decimal tab for each tab separated column): b) True table (note that the tabs specified as part of paragraph definition are defined in relation to the cell; tab characters need to be entered manually; at least on Windows, there is no text ruler that could be used in context of table cells so you just use the Paragraph panel to enter the tab positions and alignments): If you paste from Excel, you probably get tab separated text (though on macOS, you might get a true table, similarly when importing tables from Word).

Yes, I am not sure if it is meant to be but it can be considered as a kind of "constraining". In CorelDRAW Ctrl is used to constrain the scaling and Shift is used for mirrorring (flipping) from the center, which I personally like better. But if you want to flip horizontally you need to do it as a separate step using the side handles.

I think the most common meaning is though (in print industry and graphic design) an 8-bit (or 16-bit) one-channel bitmap (plus possibly alpha, duotone etc. information), which basically should not be rendered in multiple inks (CMY colors) in any condition (other than when used for tinting). The problem with Affinity apps grayscale model is that it is not well suited for CMYK based print production. D50 (the only grayscale profile that comes with the package) is not color managed in a sense that different stock (newspaper, coated and uncoated paper) would be properly handled when using grayscale images. D50 images gray values are just passed through without color management, and when color conversion happens at export time, they typically convert to four-color grays. E.g. in the "Katze" image in OP's document a 16-bit grayscale image with D50 embedded had K100 definitions for strokes, but their grayscale representation is G14 (as K100 is first translated to RGB and then to equivalent grayscale value). On the other hand, the Flugzeug image, also a 16-bit grayscale image with D50 had G0 defiinitions made to the strokes, which in Affinity is same as RGB 0,0,0, and translates as C100, M100, Y100, K100. So in one grayscale image K100 translates to G14 and in another G0 translates to registration black or pure RGB black. This is pretty absurd for anyone who has done page layout with apps like InDesign or QuarkXPress. There are ways to deal with this, but one could say that the user will get as a bonus gray hair in the process...

Holding down the Shift performs horizontal flip WHILE you in the same process have first flipped vertically (by dragging over).

Not really. It has that mysterious U.S. Web coated profile embedded which always happens when D50 based grayscales are exported to CMYK PDFs, so its probably Affinity internals working in a way that keeps a grayscale black as K black. This probably works ok if the whole job is done similarly but I'd feel quite insecure mixing these in a job that also has colors in CMYK even when exporting using PDF/X3 or X4 with all involved color profiles included. I was too tired yesterday to have a proper look on this, but examined it closer now. You are absolutely correct, it should not be this difficult to keep grayscales K-based in a CMYK job. Here are some further comments: 1) As already mentioned, the file has both grayscale (16 bit) and CMYK files linked in a CMYK document, and the mix easily results in generation of four-color blacks at export time. Linked b&w/grayscale files behave as expected only if they are monochromes (which Affinity apps do not support), or if they have profiles such as Dot Gain % profiles from Adobe embedded (rather than D50, which is basically non-color managed in CMYK jobs); vector objects should preferably be defined in CMYK. An easy workaround is to try to force grayscale conversion at export time, but this is not always possible (e.g. when the same job or pages also have objects that are wished to be printed in four color). As I tried this, this worked ok but the barcode showed mostly gray 86 values instead of K100 so conversion was done for this object even when using D50 document color profile in the publication. The other graphs stayed as K100 (and grayscale fills at points where defined). 2) The other method, and one that requires much more work, is to keep the document as CMYK file and make changes to individual files: a) 2RK - grau with Coated Fogra 39 has four-color black strokes defined, but can be easily converted to K100 by selecting all strokes and making the definition. b) 2Katze Skizze - grau is Grayscale/16 with Grayscale D50 profile embedded can also easily be converted to K100 by first converting it to CMYK/8 (with Coated Fogra 39 profile) and then defining all strokes as K100. c) Flugzeug mit Strahlen - grau is also Grayscale/16 with Grayscale D50 profile embedded, and should be converted to CMYK/8 and then define all strokes with K100 and a few fills with K100, and one with K50. The picture has a bitmap mask that causes the rays to become rasterized. The bitmap mask should be replaced with a vector and as cutting may be problematic I would just place a curve with white fill in the middle to cover the parts of the rays that are not wanted. The ray strokes should also be defined as K100. d) Barcode 3 - grau is also Grayscale/16 with Grayscale D50 profile embedded and it has complexity that causes the graphic to become rasterized. It could perhaps be fixed with careful compositional changes so that the graphic stays in vector format but I would convert the picture to a high resolution grayscale bitmap possibly thresholded and exorted to TIFF with black and white profile and then also export the page where the barcode is included separately with high resolution (e.g. 1200dpi, not allowing downsampling). I prepared an .afpub file and a CMYK PDF in the process so I can post them privately if you are interested.

As @thomaso mentioned, having in the same document both grayscales (and especially with D50 profile which is a display profile and needs to be forced to be exported as grayscale to be outputted in just K) and CMYK images is problematic, so if you prefer to have the book produced with just one PDF export, I would make all the grayscale drawings CMYK drawings (and see that they share a common CMYK profile) and define the black in K only. There are also problems with masks that cause the vectors (e.g. airplane "rays" and the barcode) to become rasterized, and when they do so, they turn to four-color grays. Another option would be to export just these problematic pages forcing them to be converted to grayscale.

You have CMYK (four-color) definitions in strokes of your drawings (the airplane has also a few four-color fills): (image removed as per request) Once fixed, the drawings export as K100 just fine. (image removed as per request)

One way this happens inadvertently very easily is if you grab the middle bottom handle and drag it over the top of the text frame and hold down the Shift key while doing so. (Dragging over flips the text vertically and holding down the Shift key flips it horizontally.)

You should be able to find out the original size of a resized pixel layer by scaling the resized object until it reaches the document resolution: a) First check the document resolution from Document > Resize Document: b) The transformed pixel layer shows here the horizontal and vertical dpi values of 22 x 13 dpi: c) Straighten the object and resize it until you get the document dpi value (72 dpi) expressed as a single value in the DPI box: In this case, the original dimensions of the transformed pixel layer were 118px x 118px.

That's it! I searched if from Photo! But found out the way to get this information there, as well, so worth an effort!

Found out another method, also available in the current release (and probably any earlier) version of Photo, also on Windows. Just scale the image until the document DPI value is shown as single value in the dpi box (at the top left):

I tried to find out where this information is shown but could not spot it in the current Windows beta -- perhaps this is implemented so far in macOS version only. One way to find out the original widh and height of a pixel object is though available also on Windows, and also in current release (and probably any earlier) version of Photo, is to copy a selected pixel layer on the Clipboard and using a clipboard viewer to display the PDF version of copied content. It shows the original image width and height of the bitmap object: Saving the content to PDF and then opening it in Photoshop confirmed that the two pixels more in both width and height dimension are a margin added by Affinity when placing the object on the Clipboard, as trimming away the transparent edge pixels resulted in image 423px wide and 331px high. This would be a very useful feature if available directly in the UI so that a pixel layer content can be reverted to its original size simply by using a menu command or similar.

Ok, thanks. I did post it initially there, I have not posted for a while on the bug forums and I did not remember that there is a separate area for the beta versions.

I thought that I posted it in here. Is there a way to see where a topic was originally posted, or if the original forum is changed by a moderator?

Trying to export a publication that has a placed PDF marked to be passed through using any of the PDF/X methods (PDF/X1a:2003, PDF/X3 or PDF/X4) causes immediate crash of the app as soon as the option is selected from the drop down. I have tried this with a couple of documents and it seems to happen with very simple files, as well (see the attached files). Testptpdf.afpub testpassthrough.pdf PS. Thanks for the feature, I did not expect this to happen pre v2!!!

Yes, depends of course on the text editor. On Windows Visual Studio can handle the line breaks without problems while Visual Studio Code (oddly) cannot (even after it asks whether it should fix line breaks). Notepad++ shows PS but not does not break the line, many HTML editors, even the old Microsoft Expression Web can handle the line breaks.