Lagarto

No, the method described above is just a way to have meaningful names in the document palette. Affinity by default adds PMS color definitions in the (automatically created) document palette with nonsense "Global" labels. This is ok if you do not mind having the actual real PMS definitions be "hidden" by such generic names, so I am just showing a method of adding meaningful names first as local swatches and then converitng them to global, to achieve the same behavior. UPDATE: You could of course equally well just rename the generic "Global" color swatch created by Affinity app and use the PMS color name, instead.

Affinity way of creating a meaningful swatch for a PMS based color is not really an example of good and intuitive UI. Pantone colors by default are added as global colors in an automatically created document palette (like "Global Color 58" below). You could right click the swatch in the generated list and and then choose "Overprint" from the context menu to have that color overprinted. For me, the preferred method would be creating a document palette beforehand, then adding any PMS definitions for specific objects (as in the screenshot below the yellow rectangle) using the PMS color model. Having the object with appropriate color been selected, click on the leftmost icon in the Swatches palette (the first icon on the right ot the "Document" ilst box below). This creates a swatch where you have a meaningful name for the swatch, as follows (note that the swatch is not yet global, as indicated by not having the bottom left triagnle in the swatch). Subsequenly you'd click the created local swatch named as "PANTONE 803C" below) and choose "Make Global" to make the PMS definition global: After that, you can select the gobal PMS defintion, right click it, adn choose "Overpirnt" from th econte menu, as follows (here the original "Global Color 58" already been deleted):

It is nothing of the sort. The way color is handled in Affinity apps and when exporting to different file formats is very much "live" because of these kinds of issues. What is important, it gets improving and becoming more consistent. But "PDF/X"-based export methods are basically the way to go when using Affinity apps, otherwise you need to run a series of test exports to find out what kinds of results different settings cause in regards to non-standard based exoirts done from within Adobe apps. One crucial difference is that Adobe apps do not by default include color profiles in non PDF/X-based exports, and accordinbly do not cause this kind of illusory problems.

A good call. I pasted the histogram from Excel into PowerPoint, that lets save individual slides in SVG format, and here everything is kept in vector format, which can then be opened in Designer, see attached. However, saving the same slide in PDF format still produces a rasterized image. I also tested this by directly creating many of the new chart types from within PowerPoint and then exporting them as SVG, and vector graphs are retained. Copy pasting from PowerPoint still behaves similarly as when copying from Excel: all "new" chart types get rasterized. So this begins to look like a genuine Microsoft blunder (considering that everything works fine on macOS). I do not currently have older non-365-based Office apps (newer than Office 2010 where these kinds of chart types were not supported) installed so I cannot verify if this applies to all Windows versions of Office apps. histrogram.svg

Even when determining "Copy to", and specifying "Picture", or "As printed", certain graph types (like histograms) paste rasterized also in other Office apps like Word. They paste as bitmaps at least in CorelDRAW, QuarkXPress 2019, and Illustrator, which all support pasting vector format from Excel. Most of the charts paste as vectors, as do shapes, but "new" chart types are rasterized. It is possible to specify in app options which dpi is used for rasterizing so this way high-quality graphics can be created. But even save as PDF and export PDF produce rasterized graphics of these chart types. On macOS, all these additional chart types seem to be exported as vector format, so this is really a strange omission. It does not seem to be a bug but simply something that is not implemented for new graph types on Windows platform... . EDIT: Correcting what is said above about pasting into other Office apps: graphics do paste vectorized in internal Office draw format, but get produced as bitmaps, e.g. when saving or exporting or printing (to file) as pdf from within Word, Publisher, or PowerPoint. The only workaround I have found to keep the format vectorized is pasting in PowerPoint and saving in SVG format, see post below for details.

Yes, I can reproduce this. Perhaps an Excel bug. The histograms (at least this one) will be rasterized also when exporting to PDF, pasted in Illustrator, etc., so it is not Affinity-specific problem. This does not have anything to do with the PICT format, which is an old Mac format. It might have, if the original histogram were initially created on macOS version of Excel, but the same problem appears also when re-creating the same histogram on Windows version.

Windows Excel works identically with macOS version. This is how Clipboard content is by default pasted from Office apps to Affinity Designer: As can be seen, only certain type of colored pens paste as rasterized, everything pastes as vector objects. So as @v_kyr assumed, this is probably a setting that for some reason is turned off on your computer. The default behavior is that Excel objects paste as vector object in apps that support it. Note though that if you use Designer in Pixel Persona mode, the same content would naturally be pasted as bitmap content.

What kind of vector graph? Shapes and charts seem to be transfered (by default) as vector objects, but (EDIT: only certain kinds of) pen strokes will be rasterized. But they will be rasterized also when pasting across Office apps. I tested this with latest Office package.

It should not. How did you create the initial swatch? Please see the following: Note that you get color mode(l) based swatch names, if you first create them as local, and then convert to global ones only after that (using the context menu).You can also check the actual color value by using the Color Picker tool of the Color panel. Note too that parenthood of tints is broken as soon as you create a swatch of them (which does not happen in InDesign). So in the screenshot above (and attached Publisher document) changing the dark green would also change the larger object using a tint of that color, but not the smaller object, which has been assigned a tint by using a swatch. tints.afpub

I am not sure if this fixed it, but I simply just deleted all non-needed content. You do not basically need to delete the empty picture frames as they do not show, but I deleted those, as well. Instead of using empty paragraphs to move content to next page, it is also possible to define exception paragraph breaks (and use specific styles) that cause the break to next page (rather than next column), but it is probably easier to handle this simply by entering multiple empty paragraphs. TEMP_fixed.afpub

Thanks for the explanation, seems to be a really complex thing. Anyway, ID and Q seem to do "Ascent" based alignments similarly. For Adobe fonts, this seems to happen mostly based on "lhk" tops, and for other fonts, based on "WinAscent", or something else. Confusing, and that's why we have "first baseline alignment options" in professional page layout apps!

Ok, I was really confused about the concept. The latter (""Ascent") seems to be strictly typographically technical term, and I really do not understand the difference. "Ascender" I think is in Western context including only extenders related to basic glyphs like "l" and "h" and "k", and not diacritics. "Ascent", however, seems to be basically same as the top coordinates of the font bounding box itself(???).

Still a couple of words about the concept of "ascender". I think that the term itself is highly cultural dependent, but basically something that does not include diacritics at all, and that the term itself is likely to have been created within the Latin (Roman) tradition, rather than Germanic or Anglo-Saxon culture, the former including "extravagancies" like "ÄÖÜ", still existing in languages like Swedish and Finnish (Úü excluding, but Å,å including), and as non-diacritic variations (Æ,æ,Ø,ø) in Norwegian and Danish -- not to mention italian, French, Spanish diacritics, and other "peculiarities", abundant in all European languages.

Thanks a lot! The really interesting part of this is mentioned in your caption ("basically, the bottom of the diacritics") compared to "Ascent" being conceptually realized as something that ascends the x-height of the basic glyphs of the font itself, and this, I think, is highly cultural dependent. This also explains why "ascender" based first baseline alignment is so confused, yet we need to deal with it, as it is our legacy. In Western context, but within the Nordic culture that uses "ÅÄÖ", I interpret "regular" and "proper" typographic behavior being such that basically "ignores" these kinds of extras, and rather determines its behavior in relation to design principles. As for ascenders, this means glyphs like "l", "h", etc., and not "extravagancies" like "ÅÄÖ". I have no clue, what this means for someone designing fonts for other cultures, or a designer representing other cultures, e.g. Asian or Arabic, but it is clear we need options and manual settings in page layout apps!

@MikeW can you elaborate a bit, please, as this seems to explain something about the variation we get related to "Ascent" based alignment. Here is a screenshot created in QXP2019 using the default "Ascent" first baseline alignment option for Futura Book Italic and Adobe Garamond Pro (both by Adobe): ...and this seems to be corraborated also by Wikipedia (our omniscient friend of free "knowledge") : ...so I am interested in knowing where this grid of WinAscent-metcis proceeds from, as it seems to be causing much of confusion here. Uppercase diacritics should not be included in ascent metrics, I think, so even if the defintiion of "ascender" is "anything extending above x-height", it really should not cover diacritic positioning, and at least not with upper case glyphs. I think that QXP behaves in this respect typogrchically most soundly of all page layoyt apps, considering the first baseline alignment. IMO, the only useful options are Ascender-based (if only for the reason that this is what Adobe is using, and you simply just need to be compatible, supported by ID and Q), CapHeight-based (Publisher, ID and Q), CapHeight + accent (Q only, and quite useful for languages using regularly uppercase diacritics), and manual offset. Leading and x.height based alignments (provided by InDesign) are nice extras, but not necessary. As there are type designers around, I'd really be interested in knowing their comments about proper "Ascender" metrics! (I am not insinuating that Adobe-kind of "ascender" metrics is the only "correct one", because I know that e.g. URW can use "WinAscent" kind of metrics, where uppercase diacritics are included, but I think the question is worth asking, if different foundry cultures or differences in interpretations of these kinds of basic concepts require app-specific options and support for manual adjustments).

I do not want to spoil something that appears to be have been resolved, but the screenshot you had attached, actually had prominent blue constituent component, so it needs to look blueish on any screen: So it is not just a question of appearance. The crucial question is what color mode and color profile you are using in your document? E.g., when working in CMYK mode, RGB 0,0,0 black will be converted to 4-colour black, and depending on the document profile, might get tones that look brownish or bluish, but are totally correct values in the context of the profile and assumed color intent (e.g., using uncoated paper, etc.). So called "rich black" (or "deep black") typically has bluish overtones on display, but which do not appear bluish or brownish on paper. This spesific case might be something that was resolved by changing color management settings, but automatic applying of sRGB device profile as a kind of a standard solution in environments where more capable displays are used (even if in many cases without proper hardware calibration), is simply just overlooking the complexity of color-related problems.

No, quite the contrary: it basically removes complexities like fonts and transparency and makes everything simpler The only concern then being that the flattener does its job well! And of course you no longer can edit the font-based stuff, as "text". These kinds of tools are a great aid at this point when you need to get in vector-based stuff into Affinity apps. Without flattening, the fonts used in the imported jobs but not available on your system, might get silently be replaced with stylistically "matching" fonts, or objects with missing fonts might be totally omitted, or rendered mispositioned or otherwise erroneously. So certainly money well spent, even after Affinity apps get ability to render unavailable fonts (or ability to pass through embedded ones). May I inquire which app you ended up to purchase for the task?

Please check this post:

I only just noticed this, and this explains the problem: I think that there is no "Perspective Crop Tool" in Photo (similar as there is in Photoshop), so you need to first use the Perspective Tool, and then the Crop Tool.

I made a couple of fixes to the image flow to avoid problems if you continue adding pages to the gallery. ENCOURAGERS_Alphabetical_Directory_fixed.afpub

It is not exactly so. It will struggle with books constisting of several hundreds of pages, but does just well with smaller publications. Also, as it is possible to start page numbering from a specified number, you can easily create a larger book in parts. If the produced parts (PDF files) need to be combined, this can easily be done with free tools.

Yes, the recording showed the perspective being correctly applied on the top layer. Note that you do not need to duplicate the bottom layer to be able to apply a perspective on the image. Even if the bottom layer is named as "Background" and "locked", it is still a layer in Photo, so you can directly apply the tool on it, if you wish.

Strange. I think that Filters > Distort > Perspective does the same as selecting the Perspective Tool from the toolbar: While using the Perspective Live Filter is done as follows: a) To apply: b) Being applying:

But did you first use the tool to create the perspective, and click Apply only after that? Note too that the image posted by @Fixx shows a Perspective Live Filter, and this is not applied by using the Perspective Tool, but instead from the Layers panel, clicking the Live Filters (an hour glass button on the right of the Fx button), and choosing Perspective... The latter is non-destructive adjustment, that can be applied also on an image layer, while if you use Perspective Tool, an image layer will be automatically rasterized to pixel layer so that it can be used.

This could be something similar that @MikeW spotted with another job that was to be handled with CorelDRAW: the default PDF/X-based export methods in Affinity apps use "the Allow advanced features" option which results in the print PDF showing only partly, or not at all when opened for positioning. Please tty using the same settings but just modifying the export options so that you turn off "Allow advanced features". Worth a try anyway.