lacerto

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

Here is basic visual preflight that you can do in apps like Adobe Acrobat Pro that can show separations and check use of transparency, overprint and rich black, and total ink coverage. basic_preflight.mp4 You mention newsprint so I wonder if the default CMYK profile you are currently using (U.S. Web Coated v2), which allows up to 300% total ink usage, is appropriate, or if your printer can recommend something with lesser maximum ink usage? Related to this, please note that if another CMYK profile is recommended, you cannot simply just switch the profile at export time, since Affinity apps do not allow "keeping the color numbers", but instead will recalculate all CMYK definitions, which would result in K100 blacks being converted to rich black. So if you need to change the profile, use File > Document Setup, and Color tab, and when switching the CMYK profile, make sure that you use the "Assign" option if you just want to change the profile without causing change of color values (this would keep you K100 text as K100) -- or, if you want to have Affinity Publisher to translate all CMYK colors for lesser ink coverage, use the "Convert" option, which would cause K100 to become rich black, which you then need to change back to K100 using e.g. Search and FInd, optimally combined with text style definitions.

😃 If you do not have e.g. Adobe Acrobat or another tool that lets you view separations (e.g., browse through the pages while having CMY enabled and K hidden, to expose text where CMY inks are applied), you can always open the document in Affinity Publisher and check (e.g. use formatting in search to look for specific font color). If you have Photo, you could visit Pixel Persona and use the Channel panel for this purpose. Note that if you experience conversion of K100 text to four-color text, these parts might also be rasterized, since violation of Affinity PDF compatibility rule basically always means that these parts will be rasterized. If you are going to use transparency flattening (PDF/X-1a or PDF/X-3), please notice that Affinity apps always flatten transparencies by rasterizing, so some part of text might become rasterized and four-color because of that, too. Fine. As long as document DPI is high enough (300dpi is probably just fine, considering the medium), it is basically irrelevant at which point things get rasterized. If the newsletter will be in digital format, as well, exporting with different PDF method would keep these parts non-rasterized. It is not an explicit option anywhere, so you get it in Affinity apps only if you use PDF/X-1a or PDF/X-3 standards, which have in their specs that live transparency is not allowed. It is possible to have transparency flattening as an in-app feature, but this is not so far supported in Affinity apps. Affinity apps do not support exporting using PDF 1.3 version, which would allow transparency flattening without using PDF/X standards (if that is something that is not wanted), and which would also allow flattening of transparencies in RGB exports (which would require also an option that lets the user to choose transparency blend color mode). You can do some transparency flattening manually, too, e.g. flatten images with a transparent background when this feature is not needed, using an image editor. It is possible to rasterize objects also on canvas but that often leaves artifacts. Using Boolean operations and Designer Persona and tools like Shape Builder you can also manually try to separate transparent parts and make certain areas solid color, but this is pretty cumbersome so probably not worth an effort.

@Jane DK - I'm sorry for my somewhat frustrated words above, but I'll try to be more helpful, even if what I mention here is a bit out of topic considering the original subject. Producing using PDF/X-1a (or PDF/X-3, and making sure that you check the Convert color spaces option) gives you the closest to the preset you have used in InDesign: essentially, these two export methods are the only way to produce automatically transparency flattened PDF within Affinity apps, which is what PDF 1.3 supported in other page layout apps will do. If this is what your printer truly requires, these two are the only options you have to automatically flatten the transparency (opacities, PNG and other images with transparent backgrounds, etc.) The bad news is that it does not work well with the kind of job you have at hand, since a newsletter is likely to contain placed PDFs on the layout. If so, you should know that if you export using PDF/X-1a, all non-PDF/X-based PDFs (e.g. logos, ads, etc.) will be rasterized and their colors recalculated, e.g. K100 black will become four-color black -- unless you let Affinity Publisher interpret their content (in which case you should have all fonts used in these files installed on your system, and check that they are correctly mapped; and check that colors are not recalculated: they most certainly will be). You mention above that this is specifically what went wrong with your job, and this is one explanation to this. If you export using PDF/X-3, PDF/X-1 and PDF/X-3 based placed PDFs will not be forced to be rasterized, but will be passed through; everything else will be rasterized and colors re-interpreted. If you do not have this kind of placed content (or do not mind having it rasterized and colors changed), I suggest that you try either method, and let your printer have a comment on output. It should be technically pretty close to what they expect. It is true that most printers today accept live transparency so if you want to make your life easier with Affinity apps, you'll do yourself a favor if you look for a printshop that does not have a problem with it. Your job is a kind that allows such a switch, but those depending on low-cost on-demand book print services, might not have that freedom. You mention that you will try PDF1.4 based method. That will not flatten the live transparency, and is also an export method that allows mixed color modes, which might be something that your printer does not want. Technically the most compatible export method would be the default, PDF (press-ready) that uses PDF 1.7. That will not rasterize any placed PDF content, but would of course not flatten live transparencies, either. [Non-PDF/X-based press exports in Affinity apps, on the other hand, will retain RGB colors in PDFs that are passed through, which is probably something else that your printer might comment...]