lacerto

Not completely. The default in InDesign is (was at least up to CS6) that the rule origin is at the top left a a spread, and when dragged to be at he spine, coordinates of the left pages are negative. It is just that InDesign offers three options for the user to choose the default. Spread is the application factory default, and then the behavior is the same as in Publisher (including what happens when dragging the zero point at spine, or anywhere within the spread) -- negative coordinates to the left and up, positive to the right and down. Page has page specific coordinate system (which is what you prefer and which option is not available in Publisher when using Facing pages), Spine places origin at the spine and shows negative values to left and up and positive to right and down, similarly as when the spread-based origin is manually set at spine. It does, but the change is not "live" since you need to reselect an object to have the coordinates updated.

It is the canvas of the painting when changing the resolution, and probably combined with JPG compression artifacts that causes the behavior. You might be able to alleviate the problem by using a bit different resampling size, method and then saving to PNG. if nothing else helps, the parts showing most moiré can be tried to be blurred a bit, but it is tricky because this is a painting and changes are easily too big, or uniform, and you are supposed to keep all details (for this reason e.g. cloning non-moiré parts might be impossible). But see if simply just using a different resolution, resampling method and no JPG compression could make a change.

It is a good idea to ask, as there are often regional (and printer specific) preferences. ISO based profiles are nowadays common so e.g. in Europe ISO Coated v2 300% is common for coated paper and in the United States U.S. Web Coated (SWOP) v2. which both produce about max 300% TAC ink coverage (something that was used in your sample ads). "Glossy" magazine may refer also to highly coated media, which can easily accept more ink (somewhere around 330%), but it is best to ask. Basically this is not too critical in your workflow as you are going to pass through existing color values. But as long as there are RGB images included, and you are going to convert color spaces to CMYK, you would need to know the recommended max ink coverage. For newsprint, ISONewspaper26v4 is common and would produce somewhere around max 230% ink coverage. If you are unsure, it seems that you can leave RGB images in the print PDF and just pass them through (since the other of the ads contained RGB images), without forcing conversion color spaces at export time. This way they will be converted only at print time, and you just pass through colors. One potential problem is that you get an ad containing CMYK images intended for coated paper and need to produce an ad for newsprint: this would require conversion of colors (which won't happen when passing through PDFs). You could ask if the printer can make these kinds of conversions for you. I also noticed some errors in the original ads, e.g. the wider one had in the right part of the ad black text in registration color (400% ink coverage) while 100% black was clearly intended. These kinds of errors would not be fixed when passing through PDFs.

Be it as it may, but mere SVG code (as Clipboard text element) does not create a new graphic document in any Windows graphic design app that I have (only ones specifically dealing with vector graphics mentioned and tested): CorelDRAW 24.5.0.731 (cannot paste rendered in an existing document, either) Illustrator CS6 (cannot paste rendered in an existing document, either) Inkscape 1.3 (cannot paste rendered in an existing document, either) Xara Designer Pro X 19.0.1 (cannot paste rendered in an existing document, either) Designer 1.x and 2.x (can paste to existing document) VectorStyler 1.1.111 (can paste to existing document) LibreOffice Draw (can paste to existing document) When tagging the exactly same code with image/x-inkscape-svg: VectorStyler can create a new document and paste rendered to an existing Word can paste rendered on existing document Designer can paste rendered on existing document (but not from image/svg+xml) Inkscape can paste rendered on existing document When tagging the exactly same code with image/svg+xml: VectorStyler can create a new document and paste rendered to en existing Word can paste rendered on existing document On macOS I have assumed that there is better OS support for deciding whether SVG code is displayed as text or rendered as graphic when pasting from Clipboard. But it does not seem to be nearly as common as I thought so basically only Designer and VectorStyler can both paste SVG code and render it as graphics in an existing document and create a new graphic document from it. But e.g. Pages and CorelDRAW cannot render pasted SVG code, nor can Word. In this perspective, Affinity apps work pretty well, being at least able to paste SVG code text item from Clipboard rendered as graphics in an existing document. The only app (of ones I have tested) on Windows that can create a new document from an SVG stream is VectorStyler. Whether an omission or not, I do not think that it takes a lot to improve the code on Windows versions so that behavior will become identical with the macOS versions. Additionally, as shown, image/x-inkscape-svg seems to be more compatible at least when using above mentioned apps, but when developing this kind of utility, both options should be made available as user-choices.

I do not think that there are any productional issues with these files that would cause them to be rasterized when placing in Affinity Publisher and subsequently exporting to PDF. These files used PDF v.1.4 and if you export using PDF 1.7 (the default in Affinity apps), you should be good. Colors are mostly DeviceCMYK (no ICC profile dependency) -- in the other file there were some RGB images which is just fine. The total area coverage was around 300% so well suited for standard printing on coated paper. When exporting, I would probably check "Convert image color spaces" and leave "Include ICC Profiles" unchecked. I would also uncheck 100% black overprint since when using placed PDF, overprint settings of the original files should be retained (e.g., the black text at the bottom on top of the gradient has overprint setting which is retained in export). My only concern is lack of bleeds in the original files. If these ads are placed in a publication and color is intended to be extended to page edges, you would need at least 3mm bleed on each side that is extended to the edge of the page. The QR Codes were also RGB or four-color CMYK. I am not sure if this can be an issue but there might be point in printing them just in black (white edge around the QR code is a good idea to make a gap to underling gradient). Please find attached an example export of an edited original which had first the QR code and then some text parts erased using Adobe Acrobat Pro, then placing the saved file in Publisher using "Passthrough", and finally exported using PDF 1.7. As you can see there are no artifacts, embedded fonts are included, and color values have been retained. export_after_edit.pdf

That works in context of VectorStyler and Inkscape, but if I add the suggested stream tag on Clipboard, Affinity apps cease to recognize SVG code on Clipboard and can no longer render items on canvas of an existing document. If I use image/x-inkscape-svg, this works in all apps at some level. The way I added the SVG stream is according to the documentation and can be serialized. EDIT: One further note: IMO there is no "glitch" or omission on Windows versions of Affinity apps. As mentioned, macOS seems to encapsulate text (including SVG code) -- in addition to placing it in multiple text formats -- within an .RTF block and thus wraps the code within a document format supported ty Affinity apps. As can be seen in the screenshot I included in one of my posts above, showing content of macOS Clipboard when OP's code is copied from Safari, there is no specific SVG stream / file object on Clipboard on macOs, either. EDIT2: No, this is wrong. I now tested this with plain text, no document wrapping, and both Designer and VectorStyler can create new docments from the SVG code content as text items. Perhaps there is something in macOS Clipboard handling that allows doing that, as both Designer and VectorStyler can do that on macOS but not on Windows. Anyway, explicitly tagging SVG text as SVG stream will allow VectorStyler to do the same on Windows.

UI missing. Perhaps something like this turns up when the context is correct, but I did not spend much time with this, since as you imply, messing with printer settings is known to cause serious headache.

Sure, but as long as the SVG code (or its PDF translation) is not wrapped within a supported document format, it requires separate handling (basically a routine that actively looks for SVG code = text data on Clipboard to create a new document). The following clip that tags a text format as an SVG stream shows that Designer does not track specifically for SVG data content on Clipboard for new SVG file creation, but VectorStyler does (and is the only app I know that does this based on mere SVG stream): vectorstyler_svg.mp4 But VectorStyler does not do this simply just with mere text item containing SVG code. It requires a specific data stream tagged as containing SVG, or a document wrapper (like PDF or RTF document), otherwise it just renders SVG data as an object on an existing document canvas. On macOS it behaves similarly as Designer (and can create a new document if SVG data exists wrapped in a supported document). If you need to have instant preview of SVG code, you could create a Clipboard related monitor yourself that does Clipboard SVG tagging or document wrapping automatically as soon as there is text content that actually contains an SVG document. But perhaps an SVG Preview add-in e.g. in Visual Studio Code would be more convenient?

Basically you have a better chance to retain original PDF print settings when you pass through a PDF. E,g,, when you open a PDF for editing, color profile conflicts with embedded ones and the one to be used when exporting, would cause changes in color values. Also, overprinting attributes are not retained when opening for editing (or interpreting a placed PDF). When placing for passthrough (and all goes as should), original color values are retained, as are print settings, embedded fonts, etc. There are certain caveats, though. E.g., if you need to export using a PDF/X-based method, there are Affinity-related compatibility rules that would cause a non-PDF/X-based placed PDFs to become rasterized at export time. If there are such problems, and you generally have the kinds of ads that you now posted (so that you have all fonts installed, and there is not anything overly complex), you might do better opening the PDF and make the necessary fixes and then export as recommended. If you are free to choose the export method, use the default PDF (for press), which uses PDF v.1.7, and force conversion of image color spaces (some of the gray shadows were actually in RGB color space, and conversion makes sure that you have everything in the exported PDF in CMYK color mode. This method is most compatible and should support all kinds of placed PDFs and pass them through as they are. If you have the original PDF and you can post that on the forum, I can have a look on it to see if there could be any issues when working with these kinds of PDFs placed in Affinity apps for passthrough.

If you use this scenario, then use File > Place to place the PDF in an existing Publisher document of the same size as the ad. Make sure that the placement option on the context toolbar says "Passthrough". Then add the text fields and QR code in layers on top of the empty slots in the ad. It is the opening of PDF that causes those artifacts, as Publisher needs to interpret the PDF content (rather than just use the original content as it is) and the shadow images clipped by rectangles are opened and slightly misaligned (the shadows consist of blurred graytones that are not completely clipped).

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.