Hangman

That's always the way, as in, it's easy when you know how... It might be worth adding a feature request for 'delete all anchors'. I can imagine when you have literally hundreds of them in a long-form document, deleting one by one is a bit painful, it would be great to have options to a) delete all anchors and b) delete all hyperlinks in addition to being able to delete selectively.

To delete anchors simply place your cursor directly after the anchor and press the delete key. Which PDF version are you trying to export to, not all versions of PDF support hyperlinks.

Personally, I would like to see the ability to select Document Setup from the file menu after an afPhoto file has been created or an image file opened in the same way you can select Document Setup in both Designer and Publisher after a new file has been created. I think that would be an easier/quicker way to see and adjust the file and colour settings and potentially remove a lot of the confusion. I would also like to see the addition of a files' colour format appear as part of the filename in the individual window/tab for that file, so instead of a file showing as lx_Chel_05b.tiff, I'd like to see it appear as lx_Chel_05b.tiff (CMYKA/8) or myfile.jpg (RGBA/8). Currently, this information is only shown in the context toolbar when the Pan Tool is selected, why not have it always available as a simple visual guide/reminder regardless of the tool selected. This is available when click dragging the colour picker from the colour palette... or as you say, in the Info palette when using the Colour Picker Tool, but I can't see any reason why this couldn't be added as a toggle option for the Colour Picker Tool itself.

Without being able to take a look at your afPhoto file (which as Mike mentioned seems to have corrupted on uploading) it's difficult to see what has been done or the afPhoto settings used. Are you able to re-upload it? Taking an educated guess based on the CMYK values of the black background for the afPhoto exported Tiff file, Ix_Chel_04a.tiff, namely C67 M68 Y65 K74, I would assume the following (rightly or wrongly). The afPhoto file has a document Colour Format of RGB/8 and a Colour Profile of Adobe RGB (1998). CMYK sliders have been used in the RGB colour space to adjust the black background to C0 M0 Y0 K100. The file has been exported as a CMYK 8-bit Tiff file from afPhoto with the ICC Profile set to either Use document profile or U.S Web Coated (SWOP) v2 with Embed ICC Profile checked. It appears that the default ICC profile used by afPhoto when exporting a CMYK 8-bit Tiff file is U.S Web Coated (SWOP) v2 when Use document profile is selected. This results in a Tiff file that has an embedded U.S Web Coated (SWOP) v2 ICC profile, however, the colours in that file have been mapped from an Adobe RGB (1998) colour space which results in different CMYK values in the exported file. My guess is that the background black has been adjusted using the CMYK sliders in the RGB afPhoto file to show C0 M0 Y0 K100 and subsequently exported using U.S Web Coated (SWOP) v2, the belief being that the black values will match when the Tiff file is placed in a CMYK Publisher document with a Colour Profile set to U.S Web Coated (SWOP) v2. The black background created in the Publisher document is set to C0 M0 Y0 K100 and the Tiff file placed into the document. Visually, both on-screen and in the exported PDF (certainly on my monitor which is calibrated) the blacks appear very close, but in practice, there is a colour mismatch because the black values in the afPhoto exported Tiff file have been mapped from a different ICC Profile. This can be seen when the PDF is zoomed into and subsequently then shows up once printed. This is speculation having not been able to view the afPhoto file but the results are the same, i.e. when an afPhoto generated Tiff file set up as described above and exported as a CMYK 8-bit Tiff is placed into a CMYK, U.S Web Coated (SWOP) v2 Publisher document the black values match those in the Ix_Chel_04a.tiff file provided by @Yankeese

If you open the PDF file you generated from Publisher back up in Publisher and check the black value are you also seeing mixed CMYK values? Is there any chance you could make a quick screen recording starting with showing the document setup setting, through to exporting the file as a PDF?

Your Publisher Document Colour Profile is set to CMYK ISO Coated v2 (ECI), but your PDF has been exported using the CMYK Euroscale Coated v2 colour profile. Because you are using two different colour profiles, the K100 is being converted between the two profiles resulting in a black that is no longer K100 but C78 M64 Y67 K74. If your export intent is Euroscale Coated v2, then the document setup colour profile should match. That way your exported PDF should then show a black value of K100.

I think printing to a different printer if you have one you can blow the dust off would certainly help to narrow down the problem. I'm inclined to agree in that I suspect this will turn out to be a printer driver issue in some shape or form. Let us know how you get on.

Hi Lane, I've tested, as in printed all three of your files and have created my own PDF from your source file using Type 1 Univers and can confirm they all print as expected. The PDF created from Export to PDF prints as expected from Apple Preview for me so I don't believe there is a bug with regards the Publisher generated PDF, though it does seem odd that the only issue you are experiencing is printing from Apple Preview. It may be worth removing and re-adding your Canon MF4880dw from the System Preferences to see if that resolves the issue. Apple Preview does allow you to create a generic PDFX-3 file, though of course, it depends on which supported PDF features you require in your document.

Certainly not ideal but could you get away with pinning a horizontal line to your text boxes, that way the line isn't influenced by the width of the text in the text frame or the column width. Depending on how far through you are in creating your document, creating a text frame and then pinning a line to it allows you to then duplicate the text frame with line intact rather than having to pin a new line each time. As I say, certainly not ideal but just a thought. pin.mp4

Walt is correct with regards to your second example. Taking your first example, you basically have a different paragraph style applied to each text box which is why you are seeing the problem. paragraph_style.mp4

I think the confusion comes because your newly created paragraph style is called line above which matches the name of one of the default Publisher paragraph styles only your newly created style uses lowercase text rather than the Initial Caps of the default style. If you select line above from the paragraph style drop-down menu rather than Line Above then your style will be applied correctly to the second text box. For ease, you can rename your style to something that more easily differentiates it from the default Line Above paragraph style by editing the style using the Text Styles panel.

I'm glad you've been able to get things working as they should be (for now). It does sound somewhat strange that the files that weren't working yesterday are now working. Happy to take a look should you see a reoccurrence of this issue so feel free to post a file if you see the same thing happening again.

Hi CJW, Are you able to attach the AD file in question so we can take a look?

Hi John, I'm not that familiar with MarvinSketch, but looking at a few other SVG files generated using it, it seems to add clipping paths to any 'live' text elements but for some reason, these clipping paths are wildly offset in the x, y axes which causes issues when opening them in AD. I don't think AD is at fault because looking at the XML created for the SVG files the clipping paths are incorrectly positioned so possibly something ChemAxon need to look into. I suspect it is the text causing the issues in MarvinSketch, it looks as though in the sample you linked to the same issue does exist in Inkscape, it all depends where the clipping paths fall on the exported SVG, though it's odd that you are seeing different results between Inkscape and AD with your file, hopefully, someone from the Affinity team can take a look and shed some light on this. Out of interest, if you outline the text elements in your file, the 'H's and the 'B' and then export as an SVG, do you get the same issues when opening in AD. AD has an option to outline text on export which means there is no need to physically outline the text in the file itself (which is very useful). I'm not sure if MarvinSketch has a similar option when exporting to SVG but if so and if it overcomes the clipping issue it may be an option? A couple of additional thoughts, a) can you simply copy and paste the graphic created in MarvinSketch straight into AD maintaining the vector format and/or b) can you try exporting in PDF format from MarvinSketch and then opening in AD to see whether you get better results?

Hi John, Welcome to the forum... The missing 'H' is actually there but for some reason, the SVG file contains a clipping path matching the 81 x 84 pt/px document size for each of the text elements in the file and each clipping path is offset by a seemingly arbitrary amount, with the exception of the right hand 'H' where he clipping path appears at X = 0, Y = 0. The bottom 'H', it is hidden because the 'H' character is sitting outside its clipping path which is why you can't see it on opening the file. If you uncheck or delete the clipping paths associated with the text elements in the file the missing 'H' will reappear. I don't really understand why the clipping paths are a) a part of the file or b) offset from the main document origin as they are, I can only assume this is down to the software which was used to generate the SVG file but I also don't understand why opening the file in Inkscape doesn't present the same issue, maybe someone from the Affinity Team can shed some light on this?

Hi kmdk, This is a known issue (see the thread below) which affects all three apps. It's been logged as a Publisher bug afb-2214. https://forum.affinity.serif.com/index.php?/topic/98342-9625-page-width-in-publisher-exports-to-963-width-in-pdf/&tab=comments#

Hi Sean, I was unsure whether this was/is the same issue or not or in some way related. As mentioned I do occasionally see a similar issue to evtonic3 though it tends to only affect layers within a group rather than the group icon itself.

Hi Sean, I don't know for sure but I suspect this is similar if not the same issue already reported in the thread below which you replicated and acknowledged on August 30th and logged with development as afp-2392 (despite being reported as a Designer issue, so maybe it should have had an afd prefix, though I assume the same issue likely exists with AP as well). As far as I can tell it seems to relate to the layer effects but I could be wrong. I do notice this issue from time to time as well but have just accepted it as I've assumed it's already being looked at.

Um, not sure if we're doing something different? I'm working on macOS, are you on mac or windows? Interestingly I don't get anything added to my History Panel post export, mine is blank! text as curves.mp4

Hi Walt, I'm not experiencing that. If I open a document or ensure I've saved it prior to exporting it, the process of exporting it doesn't modify the document (at least not for me) and even if it were to do so it's not an issue because the OP's issue was one of wanting to "preserve the original .afdesign without over-writing it". Using the Text as Curves on PDF export allows you to do this without having to outline anything, so the best of both worlds.

(1) It's pretty quick just using the keyboard shortcut (Command Option Shift S), would a quick-export to PDF button speed things up that much, more so when you need to change any of the pdf settings? (2) This is already available under More options when exporting as a pdf. (3) See point (2) above, this negates having to physically convert text to curves within the document itself, so the text remains editable in the source document but can be exported as curves in the pdf, thereby eliminating the 'document changed' warning.

It seems to have something to do with how the graphs are being displayed. If you select the offending graph and change its status in the context toolbar from Document to Artboard1 then the text that is currently shown as being cut-off/cropped will reappear and the pdf will export correctly. I'd be more inclined to edit the graphs by selecting each in turn and clicking Edit Document and tidy them up a little, removing unnecessary extraneous elements and then bring them back into a single document... graph.mov

Unfortunately, this seems to be a long-standing issue. As far as I'm aware there has been no announcement as to when these issues will be fixed. It would be great if a lot of the major bugs were fixed in 1.8, but maybe someone from Serif can comment?

In addition (in case it hasn't already been mentioned), leaving the opacity of the parent object set to 100% but applying any blending mode to it results in the exact same issue, i.e. the stroke width being halved with the outer half vanishing.

The white background was just force of habit, I tend to always include a background as it puts the page/artboard elements in context in the Layer Panel thumbnail but as you say, it isn't required if white... To be honest, if I were doing multiple business cards as you've described I would use Affinity Publisher (non-facing pages) with one page allocated for the front and then individual pages for each person. That way you keep everything in a single document and it is easy to export and also gives you more control as you can be selective in terms of which pages you output if you don't want/need to output them all. Then I'd set up a simple Automator Quick Action to split the PDF into individual pages which you can access by right-clicking the exported pdf in the finder and selecting the Quick Action from the Services menu at the bottom of the context menu, so a single click to split them all into individual sequentially named pdf files (much quicker than exporting each page one at a time from Publisher).