lacerto

Hello @JTorres, and welcome to the forums1 At least you should make sure that both the Designer and the Publisher document use the same CMYK document color profile, since if they do not, the K100 color of the placed (linked or embedded) Designer file will be converted to four-color black. What exactly are you experiencing? I assume that the the PANTONE color is correctly exporting, and if not, have you tested if it (and K100) export correctly when exported directly from Designer (using the same PDF export method)? I mean that have you ensured that this is an error clearly related to having Designer file placed in a Publisher file? EDIT: Re-reading your post, and if it is really the other way around, placing K100 text exported as PDF/X-4 from Publisher in a Designer document containing 2-color (K100 + PMS) art, and then exporting to PDF/X-4, you should be good. Just remember to export to PDF/X-4, otherwise your placed K100 text will be rasterized and become four-color black (because of Affinity PDF passthrough "compatibility rules").

Aphoto v1 selection tools are mostly poor, and the suggested Selection Brush tool with optional soft edges [and for the object instead of the bg, as below in the comparison] is the best for most purposes. Aphoto2 is a worthy upgrade even if it did not have any other improvements than adding antialiasing options in e.g. Flood Selection tool and Sampled Color feature. Attached is a comparison of APhoto1 and APhoto2 selections (very quickly drawn), and PS one-click object selection (.aphoto2 and .psd files), the point being primarily in time spent to achieved quality. bugs_compared.afphoto bugs_compared.psd

It is perfectly fine to use rich black on colored background. Even if you'd produce the document in CMYK color mode and specify text black in K100, by default the K100 color values would be overprinted, and would accordingly mix with underlying colors. Here is a demonstration on using RGB 0, 0, 0 and K100 blacks on colored background, and when exporting the same document in CMYK and RGB: blacktext_rgb.pdf blacktext_cmyk.pdf

KDP instructions can vary, but basically they accept any color space for paper cover. It is a user-choice (within the technical limits considering the media, e.g. uncoated or coated stock) how black they want the color to appear. If you design in RGB, then RGB 0, 0, 0 (pure black) will be automatically converted to maximum four color ("rich") black available. https://kdp.amazon.com/en_US/help/topic/G201953020#color As for default color well values in the Swatches panel, they depend on the document color mode and vary accordingly: def_wells.mp4 Note the lock in the Color panel. If the lock is turned off (= not the default), then the Color panel will display the true native color values of a selected object. If you turn the lock on (= default), then switching the color mode in the Color panel will show conversion values of true object color values in selected color model, and the displayed values vary according to your currently active document color profiles.

As far as other apps that can actually do what you ask, GIMP offers to some extent similar features as Photoshop, with user-defined number of colors, optional dithering, using a pre-defined custom palette, and then producing an actual indexed image with an editable palette. a) Before: After: Affinity apps can produce equivalent appearance (with exact number of non-antialiased color areas), but it cannot export the result as an indexed image (but you could do that by taking the resulting image in e.g. GIMP).

This is how PDFs work. It only counts what is within the bounds of a container, whether it is a "page", or a "spread", it does not matter how the source is composed. And you can autoflow spreads of a source PDF onto a facing pages structure of another PDF that you will be using to export as pages, so the splitting job is pretty fast to carry out. spreads2pages.mp4

Check this post:

Well, if Metal computing is turned off, rgbtoi also works with the current release version 2.3.1 (and probably every version before). So nothing seems to have been fixed, at least in respect of rgbtoi. I have M1, and I have tested this both native and Rosetta. On Windows rgbtoi works at least on 2.3.1 and Windows Pro 11 with hw acceleration on. I don't hold my breath to see the slider value boxes returned, either.

I downloaded 2.4.0 beta. Perhaps something was done with Live Procedural Texture, but rgbtoi still does not work, and there are still no value boxes for sliders: ptbugs.mp4 Is there somewhere a log that describes the alleged fixes in this filter? I cannot see anything mentioned e.g. here: I have build 2256, which I suppose is the latest? Nothing on the Windows side, either, rgbtoi still works, but no value boxes for sliders.

@Ldina, as rgbtoi is broken on macOS, why not just use direct percentage calculation on 0 to 1 range? Another problem of course is that the input sliders have lost their value boxes (a bug that has existed there for years, I think that at some point they were there, at least as tool tips). So you need to be a bit innovative with the rulers to get exact(ish) values (30, 59, 11). The attached file has the same traditional grayscale conversion also as a Black and White Adjustment to show that the conversions are equal. rgb2gray.afphoto

Here is one possible explanation (but unlikely, as it seems the font you are using is Avenir or Avenir Next). But on Windows, the following could explain appearance of these kinds of surprising glyphs: accidental_accents.mp4 UPDATE: I just checked, and on Windows (11 Pro) it is similarly as on macOS and iPadOS, that just by having Polish as the active kb language does not have macute diacritics mapped to the keyboard (alternatives for m), so if this glyph comes from standard input, the active language must be something else than Polish (there are three different kb layouts for Polish in Windows).

I meant that there is same kind of inaccuracy also in VectorStyler native shapes as regards snapping, but typically only at these kinds of zoom levels: This means that snapping indicators tell that there is perfect snapping (collision of not just arcs and two kinds of ellipses it can draw, but whatever objects...), while there is still this kind of microscopic gap that has no meaning in graphic design.

I have no idea. You probably somehow specify the job specs when making the order. Lulu instructions seem very confused, just look how they specify A4 landscape.

No, I tried to explain that IMO picture frames are unnecessary clutter that just hide the linked document page. I need to access the page box setting anyway, and having a picture frame just because of being able to center the page is kind of an overkill since centering can be easily achieved afterwards with just a couple of clicks. Picture frames are useful with images, but I rather have linked PDFs with bleeds and printer marks placed without an additional wrapper. UPDATE: There is an additional consideration related to situations where PDF content is not symmetrical so if a page is placed centered in relation to a Picture Frame, it may be positioned incorrectly (e.g. in situations where inner bleed is zero, or when extra info like color bars, page info and slug areas are included). To be able to show this extra page information, a Picture Frame should be drawn larger than the page area, and then differently on left and right pages, and possibly also from top and bottom, depending on how things like slug areas have been defined. Placing a PDF page directly on the page, according to Trim area, automatically shows extra content like unsymmetrical bleeds or unsymmetrical slug areas correctly when the page box is changed. Picture Frame, as a mediating wrapper, would just unnecessarily complicate things.

Here is what I had in mind: LuluSwitch.mp4 Notice how placing autoflown PDF pages does not result in centered pages so this needs to be fixed by using the Transform panel. Then you also need to enable for each page the cropbox, to have bleeds included in the final portrait export.

Thanks for the workaround. You might well be right about inherent drawing inaccuracy which cannot be (at least always) avoided. When I copy Affinity objects to VectorStyler, I can get perfect tangential snaps using collision snapping, but when brought back (via Clipboard), and zoomed in very close (absurdly close), there can be minor gaps, which are meaningless, though, in most applications.

Ok, hope this works! But have a good look on color values etc. of final exported PDF so that you do not have inadvertent changes.

I would probably rotate the pages using Adobe Acrobat Pro, but as the user on Adobe forum mentioned, just rotating the pages in Adobe Reader might be a change of a meta data and does not actually perform a change from landscape to portrait (even if visually causes the change). Another option would be placing PDFs, since I think you could place all landscape pages in one go using PDF autoflow, and then select and rotate all pages in one go using the center point as rotation reference. PDF would also allow you to correctly import bleeds -- I am not sure if that would work well when placing a Publisher document. I have also bad experiences on placing Affinity document within an Affinity document, since the placed document content is interpreted, and there can be surprising conflicts between the actual inner content, and the wrapper, even if they use identical settings.

Here's my experience of this feature on Windows (latest version). I have not tested this on macOS, but on Windows, placing the page using spread snapping, even when zoomed in very close, typically leaves a gap, sometimes smaller, sometimes larger, and does not place the page exactly in the middle of the sheet, so the first thing to do is to fix the positioning (drawing the trimbox is a valid workaround but kind of counter-intuitive). Positioning is not a big issue though, because multiple pages can be selected at a time. I have not tested whether the gap is caused by having additional stuff (bleed, print marks) beyond the trim box, but this is anyway a typical situation in all kinds of imposition jobs so the autoflow feature should be able to do centering right if the center of the page is clicked while having spread + middle point snapping on. My other gripe is that the Page box cannot be set at once for all pages, but needs to be set one by one. Publisher also does not remember the last used setting so I cannot just first place one page and define the desired page box, and then delete the page and autoflow all pages since Trimbox will be the forced page box option. IMO fiddling with Picture boxes just blurs a simple job and unnecessarily hides the linked document and requires additional clicks when needing to add page box definitions done for each of the placed document pages. I am not saying that the job cannot be done but just demonstrating flaws of the feature as it is currently implemented. pdf_autoflow.mp4

It might still be that you need to rotate the pages after exported to PDF. See this similar question on Adobe forums: https://community.adobe.com/t5/indesign-discussions/self-pub-how-to-change-landscape-to-portrait-orientation-keeping-landscape-dimensions/m-p/14269608

I think that the PDF autoflow feature is buggy and poorly implemented, and in practice pretty useless for imposition kinds of workflows, because the centering does not seem to work (possibly because of incorrect calculation of page content, when it has print marks), and because there is no way to predetermine page box (e.g. aligning to crop marks). It is possible to correct positioning in two steps by multiple-selecting pages, but it is not possible to determine page box option for multiple pages. In practice it is probably faster to copy paste one spread at a time correctly positioned document frames with correctly defined page boxes (because copy paste uses the source coordinates), and then use the Spread box to specify the page to be shown in each frame -- especially if you are going to do impositions where the page order is not consecutive. I did not understand how picture frames can be useful when working with PDFs and imposition, I think they are just one element more making correct placement of desired page boxes more complex. For image placement they are of course practical, but that's another topic.

I do not understand: do you mean that there is some inherent tangent calculation, and not just node snapping to ones created at tangent positions? CorelDRAW, e.g. has tangent snapping that works when drawing lines, but not when trying to snap ellipses (or ellipses converted to curves): ...and Illustrator has a tedious workaround: https://community.adobe.com/t5/illustrator-discussions/how-to-snap-line-tangent-on-circle/m-p/11514713#M248472 ...but VectorStyler collision snapping works really elegantly.

Thanks, I had already checked this but I missed the collision snapping.

Hi @eobet, Did you export after applying the single node fix, or some other kind of a fix? If I try to reproduce this after the "PDF export fix", I' seem to get a clean SVG export and no such anomaly. But I might have misunderstood something. add problem_basedon_pdfexport.svg

Thanks for posting! There is one point worth noting mentioned in Blurb instructions: Some service providers, on the other hand, might use (overly) strict preflight routines that discard a delivered print job for reasons that seem trivial. But they often are not, considering what the print personnel in such services really can do. Many on-demand-printers targeted for general public e.g. might simply just strip any color management included and if there are transparencies, might flatten them with whatever tool is available for them. Such operations might leave visible stripes or color changes between adjacent (flattened and non-flattened) color areas, which would then become as nasty surprises in printed product if not noticed when checking the drafts (if even available). Noting users of possible issues as regards use of live transparency, mixed color mode, etc., and recommending "legacy" press standards, are often kinds of safety measures and warnings and recommendations, and they are often given assuming that users have easy ways of applying these changes (i.e., that they do the layout with e.g. InDesign, QuarkXPress, etc.). There is typically no press-specific information available for Affinity apps, and it cannot be assumed that printshops have trained personnel knowledgeable enough to know about specific limitations and workarounds of Affinity apps to give step-by-step instructions for their customers (especially as press-specific development is going on).