lacerto

Ok, thanks for the additional information. One idea could be leaving out the parts that need editing (date, telephone number and QR Code). Then you would place the PDF in a Publisher document and add the missing elements on top of the layout, and export. But if you get the source from a third party, this might be a problem. You might also be able to use Acrobat Pro on your desktop computer and use the Edit within Print Production tools to delete single elements from the ad (this kind of editing does not re-interpret the PDF similarly as when you need to open it for editing in e.g. Affinity app or QuarkXpress), and then take the edited version on the road to use Publisher on iPad Pro.

But does not this repeat the same page on the same sheet (e.g. front and back page of card 1 twice on the first sheet, rather than front and back pages of successive two cards)? This might well be what OP asked-- just printing the same card twice per sheet to save paper, so the solution presented by me is probably an overkill. It would be useful of course in a situation one needs customized greeting cards for multiple people, and because of page imposition job has already been done, would allow problem-free double-sided printing. Data merge would also allow inclusion of custom images defined in the source document, so potentially a quite powerful feature for these kinds of purposes. Btw., I noticed that on Windows the Layout section does not have Layout direction option, and the printout is still also always in RGB, which may be a limitation whenever needing to produce for printing press (there is no such limitation on macOS).

You're welcome. You might want to ask them to create the PDF using a bit different export method to see if it helps. These kinds of artifacts are not always created when opening a PDF containing shadows so they might be something that can be avoided just by changing the export method, or by increasing the DPI of rasterized objects (like shadows). But it might also be something that is specific to source app and cannot be avoided. In some situations it is fairly easy to fix the problems (in the case of the file you posted I only needed to make clipping rectangles around the shadow images a bit smaller). When you open a PDF document for editing, you are actually likely to need to make diverse fixes (starting from checking that included fonts are installed and correctly mapped, colors rendered correctly, including possible overprint settings (which Affinity apps do not retain), etc. If you simply just need to use a PDF in your job, place it in the document using the default "Passthrough" option. That can cause problems, as well, though. But if you really need to make edits, you need to open the document and then check carefully that there are no interpretation errors.

It would probably be a very simple task, because Affinity apps already can paste a text object on the Clipboard and render it as graphic when pasted on an existing page (or as text, if pasted within a text control). But it is not completely clear whether the macOS versions (already 1.x versions) can create a new document based on some additional code in the app itself, or because on macOS, there is additional data that gets placed on Clipboard by the system [or perhaps by Safari EDIT: no, this happens also when copying from TextEdit] whenever copying SVG code from Safari onto Clipboard. This is a screenshot of that content: Compare this with the screenshot made on Windows when the exactly same text block from your original post is copied from Chrome. On macOS, in addition to text formats, there is RTF document format generated, which is supported by Affinity apps and which would make it natural for Affinity apps to support directly as a document creating Clipboard format without any additional code needing to exist on the macOS platform. I created a routine that tags existing SVG code on Clipboard as an SVG stream (basically a file object), which makes the object recognizable to Inkscape (which cannot paste SVG code as rendered graphic), but it still is not shown as Clipboard content that can create a new document in Affinity Designer (while it can be pasted as a rendered object into an existing document similarly as the mere text tagged SVG code). So when Affinity apps can do that (create a new document from Clipboard content), I think that the content already exists on Clipboard as a document (that is, using one of the supported file formats with a defined document boundary box). Clipboardformats.mp4 In the current situation, it is easiest to simply just paste SVG code in an existing Designer document as a rendered object, then copy the pasted object onto Clipboard, and now (when the pasted content has created a PDF document), use File > New from Clipboard to create a new document encompassing just the graphic content. This works whether you have the "Copy items as SVG" preference option checked or not (since Serif always creates a PDF document format of vector graphics copied onto Clipboard).

Do you mean just pasting (this does work both in v1 and v2), or pasting as a new document? The latter shows for me the following in both 1.x and 2.x versions (Windows): On macOS it does work.

I am not sure what you mean. This is what Free Clipboard Viewer shows when having the code you attached copied onto Clipboard: ...so basically just what Affinity apps see. CorelDRAW also only sees the text (and cannot create an SVG object or new document based on the content). Neither can Inkscape, or Illustrator CS6.

I am not sure if I understood correctly your goal, but have a look on the attached Publisher and Excel data sheet and see if it does the kind of merge you are after (the example file does this for six cards). Cards.xlsx Cards_v02.afpub NOTE: It seems there is meaning at which point text fields are assigned their field data. I initially did it before having text fields nested into Data Merge Layout controls, and could not get the Advance and Offset index pointers work correctly until deleting the text fields, creating new ones within DML controls and making the field assignments only after that.

You're welcome. Here is a clip that shows the idea, and an updated Publisher document which has 1,800 records in place for demo and a paragraph style ready for editing. ShadeCards.mp4 tableflow.afpub After having flown the data, you could well maintain the database directly in Publisher (add records in between if needed, delete and edit existing cards, etc.)

Thanks, I am not familiar with the .studio format and cutting workflows but the currently drawn shades can probably be converted to a bitmap format like .jpg or .png. I assume that that the shades should be part of the merge? If it is just 1,800 or so data records (e.g. in an Excel sheet), that could easily be imported to Word, the table converted to text where each field would be tab separated and each record paragraph separated. Then you would have the paragraph formatted with frame break and convert tabs to line breaks (or however you wish to format the data). My point is that if you do it with data merge, you need to remerge each time you will have changes. Merged document itself is a pain to edit.

Do you have an existing Publisher document that shows some of the data and the exact layout? With a text flow, you could easily create a system where you have a text block including the three data "fields", and the flow from one frame to another that would be controlled by paragraph that forces break to the following frame. That would allow you to place entries in between. The text flow would also allow inline images when importing from a Word document.

Instead of using data merge, I would use simple frame to frame text flow, frames and graphics drawn, and frames linked to each other on a master page. Then just import any number of elements and auto-flow it. tableflow.afpub

One further note by someone who used to utilize app APIs in diverse programming tasks (both in context of 3rd party and native Adobe scripts and C++ plugins), I do not think that a routine that just reads in e.g. PDF API provided information on page boxes, and places whatever is fed (either with bleeds or without), and places them as per instruction side by side (with or without user-defined gaps) would be anything rogue or peculiar. This is basically just doing the basic stuff and what is asked without wasting space. If that kind of a utility were up to something else then being at alpha or 1.0 version stage, or more than being just an in-house utility, it would probably also check that (auto)positioned layouts do not exceed the specified print sheet sizes. But as a principle, I do not think that a functionality which simply just allows n x n row/col duplication based on the trim box size would be the primary culprit of a failed print job, just because of not warning about results of accumulation, especially when it can be assumed that accumulation can be fully previewed, as when using Affinity apps. But as has been shown in many posts on this forum, simply just assuming that each and every print job is produced at 300dpi (to have the px based rounding errors within a generally acceptable non-harmful zone) is basically just a poor excuse for a non industry-standard basic procedure of calculating page box dimensions on a basis of using px units.

On Windows, this setting only has effect on whether copied objects are placed in SVG code on Clipboard or not (image/X-inkscape-svg and Scalable Vector Graphics): When the setting is off, only following content (when copying the same object) is placed on Clipboard: However, when the mere code is copied, the content of Clipboard is only as follows: ...so the setting does not have effect on how an existing code (as plain or Unicode text) is handled: on Windows, the mere code can never create a new document. But on macOS, it can.

On Windows, this does not seem to work (at least in 2.2.1), but if I paste the referred code on an existing document and then copy the resulting SVG rendering, I can paste as a new document. I am not sure if this something that is dependent on some app preference affecting the SVG behavior also when pasting from (and not just when copying to) Clipboard, but I think that macOS and Windows versions have always behaved a bit differently when copy pasting SVG code via Clipboard.

Yes, I used it because that kind of a line is generally printable on any kind of media and visually discernible from a 0.5 pt line. If a quarter of a point is meaningful when printing lines, I think it can also be meaningful in context of defining dimensions, and especially when abutting objects of assumed sizes side by side. Whether "small" rounding errors are theoretical, or cause discernible anomalies, totally depends on the application. I used a common size (a visit card) at 300dpi simply to show that errors in printout can happen already in these kinds of common tasks: the gap between the edge lines is clearly visible (it would be of course trivial if the cards were actually cut, but that is not the point). I do not want to exaggerate nor undermine the consequences of this feature, but it is good to be aware of it and potential issues it may cause. Similarly, I do not want to take a stand for or against automated checkout routines that might be obsolete, too strict, unnecessary, or simply just lousy customer service -- probably it is not an issue to majority of users who produce their jobs with something like Word or Pages (or Adobe apps). But if they are applied in preflight routines by operators like Amazon, it is kind of pointless to argue against them: either you need to use software that can produce what is requested (or apply workarounds if possible), or need to take the job to print it elsewhere. Yes, the size of the objects does not change. It is their position that is different. There is a gap between each card caused by the erroneous trim sizes.

Hi @Hayz, and welcome to the forums. The thin lines appear to be caused (at least partially) by rectangles that clip the shadow effects -- if made a bit smaller you should be able to get rid of them. lines problem 3915b_New LANDINI DISCOVERY RANGE_WT 331 oe 31.12_fixed.pdf

Probably not in a book project, but there might be real problem in an imposition job involving placing columns and rows of duplicates of a single design, and generally in printing industry 0.25 points is a meaningful accuracy at which all professional applications should aim at. Even a small trim size error can cause visible results. The attached PDF has a standard visit card the document size of which is 89x44mm placed on a sheet that can have 10 x 10 cards impositioned. The first page has a Publisher created PDF that creates a trim size of 89,069 x 44,027 at 300 dpi document and export resolution, and the second page an InDesign created card that has trim size of 89 x 44mm (rounded from pt dimensions with accuracy of three decimals). Both cards have been exported identically. They have a 0.25pt inside aligned stroke at the edge of the canvas (not basically a practical thing, but demonstrates well enough the issue). The positioning has been done identically: placing a single document as it is on the top left corner of the canvas and then just snap duplicating the design without extra gaps assuming that 10 cols and rows exactly fill the sheet. Which it of course does when placing the InDesign created card, but not when placing the Publisher created card with a trim page box rounding inaccuracy (which is correctly retained when placing the PDF). The error could of course be fixed easily by cropping the placed PDF before starting duplication, but it is a nuisance and should not be there. In a sloppy workflow not checking the assumed trim sizes, or in an automated workflow reading trim sizes and doing positioning accordingly it would require manual intervention, or could end up being printed. imposition_job.pdf

It seems more a kind of a conceptual error combined with coarse calculational glitches (e.g., below the trimbox height is rounded up to become exactly double the width, as if based on underlying px based rounding to nearest integer, when the document DPI is defined as the minimum of 1dpi). The document itself (the physical dimensions of the page and the object) stayed the same as in examples above (a 59,5 x 90 mm rectangle on a page with 49,5 x 80 mm width and height, with 5mm bleed defined on all four sides):

Do you have CMYK involved at any point of the PDF creation? I have found that disk exhaustion happens at least in situations where RGB images need to be converted to CMYK in context of PDF export. If the job is large enough, Affinity apps will (at least used to; I have not tested the latest versions) hog all disk resources available (and beyond, crashing the export job) for virtual memory. Another thing worth a notion is that the memory is released only at app closure -- not after the task is finished.

It does seem more complicated than it should: why not just convert any wide-gamut (> any larger color gamut than sRGB) image to sRGB so that you work with final color values and directly see what you get (when exporting)? If you do need to retain the wider color space and the original image, it is easier to make a copy of the original and work with a copy than making changes to the original using a soft proof, then turning off soft proof, exporting image (without embedding the profile), and finally closing the image without saving it. Direct color profile based conversion (also when using Affinity apps) generally also does a much better job (and allows using diverse options and conversion intents) than manual adjustments (e.g. using HSL etc. controls), especially within Affinity apps where these options do not seem to have any effect in context of Soft Proof adjustment (but do work in context of conversion). More generally: even when working within a limited display gamut, converting between different color profiles and bit depths -- and color intents, black compensation and dithering -- can have significant effects on visual appearance within sRGB (or below) color space. The clip below demonstrates, within a bit convoluted environment, doing a profile conversion on a natively wide-gamut display on a Windows computer, but viewed through sRGB-limited MacBook Air via Remote Desktop, to avoid color compression that would happen if trying to record the video directly on a mac (so that actual change of visual appearance shown on macOS Photoshop doing the same conversion on an sRGB limited MacBook Air would be lost in recording). prophoto_vs_srgb_within_srgb.mp4

Yes, it is related to Affinity's px based calculations (affecting all page box dimensions), so the higher the DPI, the lesser the rounding error. Just compare the figures in the following clip, showing differences in InDesign generated PDF and Affinity generated PDFs from 300dpi up to 19,200dpi. You might need to go at very high production DPI in Affinity apps to get to accuracy where the deviation no longer matters! trimissue_cropped.mp4

I remembered incorrectly the capability of Ghostscript to show overprint state of spot colors (especially ones in PDF/X-based exports), but it seems that they do not form a special case. Ghostscript does have similar issues as Adobe Acrobat Pro with ICC-dependent PDFs without output intent (causing ad-hoc recalculated color values shown based on underlying default target), and therefore -- and because of lack of more general interest in the app on the forum, much because it requires user-initiated installation of Ghostscript -- I did not continue developing of my GS front end PDF Output Preview, so it has not been touched in about two and a half years. But considering the continuing poor availability of free (or even low-cost) professional prepress tools being able to show e.g. spot colors, pick color values, show total area coverage and overprints, I decided to update the tool, and it now supports also version 2 Affinity apps on both Windows and macOS. The tool has more "advanced" features on Windows, but might be useful also on macOS. It has been only cursorily tested on most recent Affinity v2 apps (2.2.0 and 2.2.1) on up-to-date Windows 11 Pro and macOS Sonoma 14.0. I had GS 9.5.0 installed on macOS Sonoma and it seems to work fine. On Windows I tested it with GS 9.56.1. To avoid the mistargeting issue, it is recommended -- as always when producing DeviceCMYK content -- that ICC profiles are NOT embedded in the PDF exports (unless done automatically when using PDF/X-routines where inclusion of output intent is obligatory and happens automatically). The apps are not properly digitally signed, and as mentioned, not really tested, but I can try to help forum users interested in using the app and needing some assistance. autokoverprint_wspots.pdf Windows version (1.0.0.17): POPWin_v17.zip NOTE: The app can read PANTONE rendering colors only for MSI-based Affinity v2 apps (because the PANTONE .csvs are sandboxed in Windows store versions and their installation locations change with each updated version). macOS version (1.0.0.13): PDF Output Preview-1.0.0.13.pkg NOTE: The apps have been written in C# so they require runtimes. I am not sure but I think that both Win and macOS latest versions have runtimes installed.

It is only K100 (alone, or mixed with other process colors -- note the difference to ID, which only (optionally) auto-overprints [Black] swatch at 100%). If you want <K100 to overprint, you need to use a separate swatch with overprint attribute (and you cannot specify overprint gradients because overprint is a swatch attribute rather than fill/stroke attribute in Affinity apps). As for apps being able to show overprinting trustworthily (including spot colors), I do not personally know other than Adobe Acrobat Pro and Adobe Illustrator (including legacy versions), and CorelDRAW. Affinity apps ignore overprint status whenever opening / interpreting PDF files. EDIT: PackzView can both highlight and simulate overprints, and would also be available free (but as mentioned, with availability limitations), and is available either on Windows and macOS, and would be very useful. Mere Acrobat Reader can simulate overprints depending on the produced PDF version, which might be useful to some degree.

Note that the referred profile is intended for newsprint so its dot gain for black ink is relatively high (probably something like 25 or 30%). Custom dot gains can be created manually in many color calibration apps, and e.g. in Photoshop, but if you do not have PS Dot Gain profiles, you can get a grayscale profile for coated paper (with more regular 15-20% dot gain) at https://www.colormanagement.org/en/isoprofile.html#ISOcoated_v2_grey1c_bas However, if you are going to use the profiles in context of PDF/X-4 (converting directly RGB images to grayscale) the profiles will be embedded even when forcing image space conversion so you would typically not get different tonal output using different dot gains (even if the internal values are different) -- since the embedded profiles would be used to recalculate tonal values if there is a profile conflict. To cause effective tonal conversion, you should either target to correct final media (with no need for print-time adjustments) or would need to use the profiles when converting from color (or grayscale) in e.g. Photo and then place processed images in Publisher (in which case the gray values would simply be passed through).

That is a good question. I do not personally know other than Adobe Acrobat Pro and Callas Software's pdfToolbox that can trustworthily inspect internals of PDFs, but for me the problem is that there are situations, especially related to non-flattened transparencies and nested mixed color modes where I cannot tell whether they will be resolved correctly when processed on rip. They can fool Adobe Acrobat Pro (and cause it to show recalculated color values, leaving you in doubt whether this will end up on plates, as well), cause rendering errors, white seams, color differences at overlapping areas, which might be illusory, or they might end up getting printed. Proofing ripped PDFs is the least that one can do to check against these kinds of errors but there is often no time for that. On the other hand, the mentioned PackzView basically ignores mixed mode issues and you get expected color values when using the color picker -- but cannot be sure whether the app just cannot reveal possible conflicts and warn about potential problems in printing... I have read on other forums dealing with prepress topics that much of prepress is still actually handled manually by printing personnel knowing their stuff, rather than processed directly on advanced rip software (contrary to what is implied), which is another reason why I personally prefer to deliver 100% resolved DeviceCMYK (or DeviceGray) print PDFs (but typically with live transparencies, though).