Hangman

I think this is an already known issue and relates to having the Scale with object check box checked. When scaling an object using Scale with object there is indeed a discrepancy between the actual stroke width of the scaled object and the value shown in the Appearance panel, i.e. the stroke width isn't updated in the Appearance panel list view but it is correctly updated in the Appearance Panel floating menu when the stroke width is clicked on from the list view. I'm sure this has been reported previously.

The issue seems to be that Publisher doesn't have the ability to correctly identify colours in 'Linked' or 'Embedded' AD files within the application itself. For example the attached CMYK AD file uses four colours, namely Pantone Yellow 012 U, Pantone Orange 021 U, Cyan (100, 0, 0, 0) and Magenta (0, 100, 0, 0). When the AD file is placed as a linked or embedded file in Publisher ideally a new document palette should automatically be added which contains all the colours used in the linked AD file (as per Ilustrator and InDesign) which sadly doesn't happen. As a work around my expectation would be that when selecting 'Create Palette from Document' from within Publisher a new document palette would be added with the four colours as per the source AD file but what I actully get is a palette made up of 68 varying tints of the four source colours but defined using the LAB colour space which makes zero sense to me. Having said that Publisher file does correctly export in PDF format (see attached file), i.e. it correctly contains both the CMYK and Spot colour separations but there is a need for a BIG overhaul in terms of colour management across the whole suite which I really hope will be addressed in V2.0. Pantone Colours.afdesign Pantone Colours.afpub

No, the Padlock icon doesn't change, when 'unlocked' it simply shows which colour space has been used for the selected object. Whilst the colours 'appear' identical for both elements, the purple and pink graphics are actually made from a mix of both RGB and CMYK colours which is only evident on export to PDF. When the padlock is 'locked', selecting any graphic doesn't show the colour space used for that graphic, unlocking it (as I've just learnt) does, as (hopefully) shown below.

Haha, I always wondered what the little padlock was for, good to know and very useful... 😀

Hi manandmouse, Do you have a particular sample AD file and source AP file demonstrating the issue you are having in Designer so we can take a look or are you using the one from your original post. I'm not seeing the same issue in terms any of colour difference.

As far as I'm aware, there is no option that shows whether you've defined a colour using RGB, CMYK or HSL (unless I've missed something). In my humble opinion I feel the colour slider panel 'should' automatically change to the selected colour model when an object or layer is selected or there should me something or some indicator that tells you the colour space for the selected object as it is not immediately obvious which is what your example highlights and is very easy to miss. As far as I can tell the pre-flight checker fails to highlight any discrepencies as well, though happy to be proved wrong about this. I think this is one of the many current weaknesses of the Affinity Suites' Colour Management (there are many more issues which have been highlighted in the forums). I'm hoping that colour management will get a big overhaul in V2.0. I think again it is a case of ensuring that all graphics use the same colour space when creating rather than mixing them and either creating a version in CMYK or RGB, which means if you want to maintain the appearance of the CMYK colours for output in RGB you need to change the document colour space to RGB and then adjust the colours accordingly, so the Blue would appear as R:84, B:81, G:163 and the Pink as R:218, G:67, B:152 in your example. Setting everything up using global colours would potentially make the process much easier, though I'd be inclined to have two versions of the file, one for print and one for screen. There is a huge difference in the size of the exported PDF files I agree.

Hi shadowphiar, This is in part down to the way you have specified colours in your document and also how you've subsequently exported it. Although your document is set up as CMYK U.S. Web Coated (SWOP) v2, it looks as though both the blue rectange and the pink dashed circle have colours specified using RGB colour values whereas the blue and pink lines are specified using CMYK colour values as shown below... Subsequently when exporting using the PDF Presets, the PDF (press ready) preset embeds the document profile (by default), the PDF (digital - high quality) profile doesn't embed any colour profile (by default)... which is why you are seeing a difference in the colours, i.e. a mix of CMYK and RGB colour values. Two options, either... Change the RGB specified colours in your document to the relevant CMYK colours prior to export (if your output is required in CMYK). Click 'More' under the PDF export dialogue for the PDF (digital - high quality) profile and change the Colour Space to CMYK and the Profile to 'Use document profile' or CMYK U.S. Web Coated (SWOP) v2 and tick the 'Embed profiles' check box. If you open your exported PDF 'test (digital - high quality).pdf' in Publsiher and either set the Colour Space in the PDF Options dialogue to CMYK or simply open the file and then change the Document Colour Settings to CMYK U.S. Web Coated (SWOP) v2 then the colurs will match, although note there is a tiny discrepency between the blue line and blue rectangle in that the Cyan value is out by a value of one in the conversion which is why all the colours within the document should be specified using the same colour space. What is the intended end use for the PDF file?

@manandmouse I think both @Sean P and @Patrick Connor have ackowledged this as an issue and the thread has been given the bug report reference afd-5283 so I don't think anyone is suggesting this isn't potentially a bug, I was simply suggesting a way of overcoming the issue when using live placed images in publisher should you need to edit the source graphic and have it automatically update the graphic in publisher. Obviously merging layers won't keep the graphic live and would mean re-importing after adjustment so it all depends what you are trying to achieve. Hardly messy, simply a case of placing the adjustment layers in a differnt position in the layers panel. Of course, we'd all love to see it fixed. This is not the case, it 100% happens in Affinity Photo as well. Place, (with emphasis on the word place, rather than simply export or copy and paste) your RGB graphic into a new CMYK Affinity Photo document and export it as a CMYK PDF and you'll see what I mean. Trust me, I tested this thoroughly. As do we all, remember Publisher is still a 1.X release, InDesign is close to its 22nd birthday and it is still not exactly 'bug free' even now. I think you will find the team at Serif far more responsive when it comes to addressing bugs than Adobe so this will be addressed but in the meantime you have a work around using my suggestion if you want to maintain a live link to the source file or you can simply merge layers if you don't have a need to maintain the live link. It sounds as though you, like me, have been in this business since the inception of digital, remember it took Adobe six years to introduce layers to Photoshop and I still have nightmares about the all nighters I used to pull back in the 90s rendering After Effects timelines back in the days when it was a CoSA product, prior to being acquired by Adobe because it didn't have batch processing but the client deadline was 9am the next day which meant having to baby sit the renders just in case and being woken up at 2am in the studio when one render errored and the default error sound built in to the software was a massive car crash which sounded so real I actually though there had been a car crash outside! Anyway, have faith, the issue has been acknowledged and as frustrating as it is, there are decent workable workarounds for both live and non live implementations and getting annoyed with Serif helps nobody. This will be fixed...

@manandmouse and @Sean P I think you are both right and both wrong in part with what you are saying in that: the issue in this instance is not specifically caused by the source Affinity Photo file being RGB and the Affinity Publisher file being CMYK the adjustment layers are "working through" the transparent areas (only in Publisher). This is also not the case, if you place your source RGB graphic into a CMYK Affinity Photo file in the same way you are placing it into a CMYK Affinity Publisher document you will see exactly the same result when exporting to a PDF file, i.e. the lighter blue background where the background has been rasterised. The issue has to do with how the file has been created. If you nest your adjustment layers as per the right hand layer panel layout below rather than sitting the adjustment layers on top of your graphic... then placing your RGB graphic into your CMYK Publisher file and exporting as a CMYK PDF will give you the correct result as shown below. faceplate_with_nested_adjustments.afphoto faceplate_with_and_without_nested_adjustments.afpub I can't upload the exported PDF at the moment, it just shows the file as 'Queued' and nothing happens but if you export the attached .afpub file page 2 and 3 spread you will see the results shown above.

I've just reinstalled the previous two Beta's to test and it seems to be checked by default, though I didn't knowigly uncheck it first time round so I'm not sure.

Thanks, hadn't spotted the checkbox was unchecked!

Definitely not working for me in AD 1.9.0.209 (and prior 1.9.X iterations) but is working as expected in APhoto 1.9.0.13. Both under Mojave 10.14.6. Also works as expected under 1.7.3. Shape Selection.mp4

I'm assuming this is a bug in the latest 1.9.X releases as the same isn't the case in APhoto? It only affects shapes, not text frames.

The issue appears to relate to any shapes that are scaled in any way after first being drawn when you have the stroke aligned to centre, so e.g. if you draw a 500 x 150px rounded rectangle and apply a 3pt stroke and do nothing else to it then the exported SVG file shows the stroke as 3pt (assuming a 72dpi document, the stroke will appear as a 3px stroke in the exported SVG). Draw an 500 x 300px rectangle and then resize it to 500 x 150px, apply a 3pt stroke and export to SVG and then the stroke size shown in the SVG is scaled to 3.79pt/px Draw an 500 x 600px rectangle and then resize it to 500 x 150px, apply a 3pt stroke and export to SVG and then the stroke size shown in the SVG is scaled to 4.12pt/px Draw an 500 x 500px square and then resize it to 250 x 250px, apply a 3pt stroke and export to SVG and then the stroke size shown in the SVG is scaled to 6.00pt/px If you set the stroke to either Inside or Outside the issue goes away. The other issue seems to be that the exported SVG files only show the stoke width for files where the stoke is aligned centre, when the stroke is aligned inside or outside the stroke width is missing in the exported SVG. So I would say both of these issues are bugs! I have a feeling they may already be known bugs but I'm not sure, hopefully someone from Affinity can confirm.

That would explain things then as I'm using a Magic Mouse and use ALT Scroll to zoom into documents but there was no mention of the Magic Mouse not working in the release notes so hadn't picked up on this. It would still be way more useful being able to make side by side comparisons so you can see the same file using different compression settings and/or resample options in a single window because currently changing the compression setting or resample mode results in the preview window going blank whilst it redraws the preview which means you can't realistically make proper comparisons which is really what you need ot be able to do.

This is a very welcome addition and I appreciate it is a work in progress but I'm slightly baffled by the current implementation. The preview provided by clicking the Preview button for any raster format displays a non-zoomable (unless I've somehow missed that) preview at a size smaller than any current document when viewed as Zoom to Fit which basically makes the preview totally useless as you really can not make any sort of realistic assessment as to how the file actually looks at different resample/compression settings. For this feature to be of any use, it needs to be much closer to the Save for Web feature in PS (but hopefully better) and it needs the ability to display the same image multiple times (user defined) and most importantly the ability to zoom in on the file so you can make a realistic side by side comparison of how the file will look at different compression settings. I'm also slightly unsure why the Preview window dispalys a different percentage setting for different file formats, i.e. for an A4 file, 22% for PNG, JPEG and GIF files but 37% for TIFF and PSD Files? What does this percentage actually relate to and why is it different for different file formats? For an A3 file these percentages change to 91% and 96% respectively?

Glad you've been able to resolve the issue.

Did removing the empty layer resolve the problem?

Not seeing any issues here with rounded corner rectangles on SVG export, are you able to attach the file you're having issues with?

@ChristianR Can you attach the AD file and also let us know which PDF preset or PDF settings you are using for the export, a screengrab of the PDF settings under the More button will be fine.

@vikingtone I'm 'guessing' here but I suspect the page that your 148mm long thing is sitting on is A4 in size and 300dpi and I also am guessing that when you're exporting to SVG you're exporting the Whole document rather than using the Selection without background option. Despite being a resolution independent format, AD uses 72dpi as its default SVG resolution which I believe is incorrect since this was changed with the introduction of CSS 2.1 to 96pdi. The CSS 3.0 specification states the following: dppx Represents the number of dots per px unit. Due to the 1:96 fixed ratio of CSS in to CSS px, 1dppx is equivalent to 96dpi, which corresponds to the default resolution of images displayed in CSS as defined by image-resolution. The default unit used by AD for SVG exports is pixels. An A4 landscape page is 3,508px wide when at 300dpi, hence my assumption above but let me know if that's not the case and purely a coincidence? There seems to be an issue with Tinkercad in that it uses mm as its unit of choice and even if following the suggestion from @Gear maker when importing an AD exported 72dpi SVG, whilst this is shown at the correct size, e.g. 148mm in the import window the actual imported SVG when measured in Tinkercad is 420mm which is 148mm converted to pixels at 72pdi, i.e. Tinkercad is actually converting 420px to 420mm. This can be seen by exporting the imported file back out of Tinkercad as an SVG file and opening it up in AD. Note: Unckecking Set viewbox under the More options in AD when exporting to SVG will achieve the same thing suggested by @Gear maker without the need to manually change the width="100%" height="100%" to mm (only it will default to px), i.e. the exported SVG will display px values instead of percentages. Changing the Width and Height to mm makes no difference in terms of how the file is interpreted by Tinkercad, it seems to see everything in mm regardless of the dimensions set in the SVG file. For some reason Tinkercad won't recognise an SVG file that uses percentages for it's W and H, but as @Gear maker suggests, changing the dimensions to mm or px allows Tinkercad to at least read the file, only it appears to read it incorrectly, as in converting what are actually px to mm. If you first physically select your 148mm long thing on the canvas, then export to SVG and choose the Selection without background option from the Area Dropdown and then click the More button and change the default Use document resolution to Use DPI and set that to 72 DPI and also uncheck Set viewbox prior to exporting your file you will end up with a 148mm long thing once exported as an SVG, however most laser cutting programs than use SVG files correctly use 96dpi and not 72dpi, e.g. Carbide Create, which means importing a 96dpi, 148mm long thing exported as an SVG from AD sucessfully imports into Carbide Create as a 148mm long thing.

Firstly apologies if this is 'slightly' off topic but I currently export hundreds of pdf files from AD and have a requirement to password protect them so they can't be copied or printed. At the moment in the abscence of any direct password protection options in AD I'm doing this manually using Apple Preview but I wondered if anyone knows if it is possible to automate the process using Automator or Applescript (or in any other way) and if so if anyone knows how to do it as I'm not a programmer. To be clear I only want to prevent copying and printing... As far as I can tell it is only possible to encrypt the pdf in Automator which would require a password to open the file which is not what I'm looking for... Ideally if somehow scriptable, the option to simply right click the pdf and select the script from the context menu so it runs automatically could work and would save me hours of time. Anyway, I just thought I'd throw it out there to see if anyone has any ideas. It would be nice to see the password protection options for PDFs in future versions of AD, AP and APub.

In what way are they different, I see no difference at all between the swatch colour and how that colour appears on page, but maybe I'm missing your point?

Loving the 'Sure Love', 'Evil Ways (Justic Mix)' (with added base drop) and 'You're Gonna Love Me' sound tracks accompanying the latest product marketing videos. Well done Affinity, great software and truly impressive 'time to launch' for the universal versions of all three apps... 👏 I hope you are making a nice, small but not insignificant dent in Adobes' market share... 🤣 Looking forward to trying all three Affinity apps on some buttery smooth Apple Silicon. The future is here.. 😎

I personally think the ability to rotate the canvas with the scroll wheel whilst holding down the cmd key is a brilliant addition, particiuarly using a magic mouse. I've simply set 'R' to be the 'Reset Rotation' keyboard shortcut.