Hangman

The issue appears to be with Allow Advanced Features, when this is turned on, which it is by default in the PDF (for Print) preset, then the Radial Grad used for the sky fails to 'export/render' correctly, i.e., the Radial Grad isn't exported as a vector, instead an odd mask is created as a child to the Radial Grad rectangle. So whilst it looks as though it has attempted to render the radial grad as a vector (which is what it should do), it hasn't and so the result is that the radial grad is missing from the PDF export. Layer Not exported correctly when Allow Advanced Features is turned on Result of exporting to PDF when Allow Advanced Features is turned on - the Radial Grad fails to export/render correctly. Result of exporting to PDF when Allow Advanced Features is turned off - the Radial Grad is rasterised correctly (as expected).

@walt.farrell That was my assumption, at least there is a workaround for now...

I guess my question then would be why does a Rectangle require the addition of the extra node but an Ellipse doesn't? AD exports a Rectangle as a <rect> but equally exports an Ellipse as a <circle>, so neither are exported as a path, yet Cricut has no issues with the Ellipse, i.e., it positions it correctly on import, unlike the Rectangle... AD Export with No Additional Node Added to the Rectangle The Rectangle is incorrectly positioned but the Ellipse is correctly positioned on Cricut import AD Export with Nodes Added to both the Rectangle and Ellipse to Create Paths Both Rectangle and Ellipse are correctly positioned on Cricut import Or is this basically just the bug in Cricut we're talking about...

It seems the issue only affects squares/rectangles or shapes originating as such... even drawing a perfect square/rectangle manually using the pen tool results in the same problem as does drawing a square and then either rotating or shearing it, however drawing a random, non-square shape that only uses 4 nodes with the pen tool doesn't exhibit the issue and likewise if you draw a square using the Ellipse tool, convert it to a curve and then move any one of the four nodes in either the X or Y axis by one pixel then the problem also no longer exhibits itself. You're right, adding an additional node to any square/rectangle does indeed fix the issue which is kind of odd. This only seems to be the case when shapes are created using either the Rectangle or Ellipse tools or when using the Pen tool to create a perfect square/rectangle, all other shapes created using any of the other shape tools remain as curves when the SVG is opened in AD which I guess is to be expected but equally unsure why this happens with the Rectangle and Ellipse? Hopefully that will be the case, do you know whether the issue has been reported to Cricut?

Seems to be working as expected here, can you upload a screen recording to demonstrate the issue you are experiencing?

The issue seems to be very much a Cricut Design Space bug. I've tested it using version 6.12.227 and basically what seems to be happening is that for any SVG files created at 72 dpi in Affinity Designer, Cricut is doubling the X and Y co-ordinates for rectangles if the rectangle hasn't been transformed, i.e., repositioned in Affinity Designer. Example Rectangle created in AD - Size 10cm x 10cm, Position X: 2cm, Y: 2cm When imported into Cricut Design Space, the same rectangle appears as Size 10cm x 10cm, Position X: 4cm, Y: 4cm If however, the rectangle is transformed in AD after initially being drawn then when imported into Cricut the X and Y co-ordinates are doubled and then the tranform offset added. Example Rectangle created in AD - Size 10cm x 10cm, Position X: 2cm, Y: 2cm then transformed X: 1cm, Y: 1cm so it is now positioned at X: 3cm, Y: 3cm When imported into Cricut Design Space, the same rectangle appears as Size 10cm x 10cm, Position X: 5cm, Y: 5cm, i.e., it has doubled the original X, Y co-ordinates and then added the transform value so it is now positioned at X: 5cm, Y: 5cm rather than doubling the new X, Y co-ordinate values which would have resulted in X: 6cm, Y: 6cm The issue is exagerated the bigger the initial X and Y values are, e.g., if the initial rectangle is positoned a X: 2cm, Y: 15cm (with no transforms), once imported into Cricut it will appear at X: 4cm, Y: 30cm The issue doesn't appear to affect circles, they maintain their position regardless of whether any transform has been applied before or after being drawn. I've not yet tested any other shapes. The SVG code is correct coming out of AD so the issue isn't AD related. I tested it using SVGs created in Inkscape and the same issue applies once imported into Cricut though size and position are scaled up by a factor of 1.333333 because Inkscape uses 96dpi as it's default resolution. With AD documents at double the resolution, i.e., 144dpi, the issue is quadrupled so a rectangle drawn at a Size 5cm x 5cm, Position X: 1cm, Y: 1cm appears in Cricut at a Size of 10cm x 10cm, Position X: 4cm, Y: 4cm if there are no transforms in AD post drawing. Any post drawn transorms at 144 dpi are however then doubled... Example Rectangle created in AD - Size 5cm x 5cm, Position X: 1cm, Y: 7cm then transformed X: 1cm, Y: 1cm Imports into Cricut at X: 6cm, Y: 30cm, i.e., original value of X and Y x 4 plus value of AD transform x 2.

@konstantnnn Firstly, let me preface this reply by saying, I agree with everything you are saying 110% BUT the point I've been trying to convey (perhaps very unsuccessfully) is, that it's really not that simple as I think @BofG is illuding to as well... I'm doing my best to try and explain both the complexities, together with possible workarounds (solutions would perhaps be the wrong terminology here I think). Absolutely not - but equally you have to understand the techonological limitations we are dealing with here. I appreciate (as you've eloquently stated) that you're not really interested in the technical aspects. I would happily post numerous OpenGL links to the complexities of rendering and anti-aliasing in terms of Multisampling, Box Filtering, Coverage and Primitave Edges but I really do understand this is perhaps not what interests you with regards to this issue (I get it, I have no problem with that). I'm absolutely not trying to defend any corner here, the point I've been trying to make is that with the limitations in current technology, implementing things like Multisampling could and likely would have a BIG detrimental impact on software performance to the extent that people would no longer be raising the issue of the visible hairlines/gaps but would instead be complaining about poor application performance. In a perfect world, again I agree 110% Glad you appreciate the nuances of British sarcasm (it's one of the few things we're good at)... 😂 This is a bit of a two-sided coin, the harline issue is a purely on-screen visual problem and a direct result of anti-aliasing rendering techniques. As such it has no impact on printed images, i.e., offset litho printing or high-resolution inkjet printing but of course it does impact raster images for online use. My suggestion to turn off anti-aliasing in AD was meant in terms of, if it annoys/frustrates you from a visual working standpoint, then turning it off would overcome that (as in the hairlines would no longer be visible) and would have no impact if your artwork was for print. Clearly if the end use is on-screen, for web, then you wouldn't disable anti-aliasing unless you were going for an early space invaders/asteroids video game look, (I'd assumed, righly or wrongly, that was a given). This really is where the nuances of Multisampling vs Performance potentially come into play, that's not to say that with ever improving processor performance this couldn't be addressed moving forward (though you always have to consider the lowest common demoninator where computer performance is concerned/supported). This was the initial response from Serif with regards this very issue (albeit toward the end of 2015). This is all well and good but as soon as you want to produce a repeating pattern using triangles, hexagons or any other shapes using angles other than 0° or 90° then you'd be facing the same problem and Keynote is not AD. I appreciate what you say about their rendering when using squares, I have no idea the rendering techniques used in Keynote, they could simply be very basic, (they are certainly not as advanced as AD) hence no visible hairlines on vertical and horizontal shapes, you'd have to ask an Apple engineer. Whilst I don't disagree with you, I think if you had this conversation with any software engineer they would be able to tell you, far more eloquently than I ever could, why this approach is currently likely not possible/impractical. Who knows, maybe that will all change in v2.0 of Affinity's software. I'm not a software programmer, my knowledge is relatively limited and maybe things will change with regards rendering engines/techniques moving forward to address this issue, not only in AD but in pretty much all vector software. Maybe you can pose the question/issue in the Affinity Support and Questions forum. I think it will elicit a minefield of opinions but the hope would be an update from Serif as to the current viability of improving this anti-aliasing issue... (just my 2 cents worth). There are easy workarounds, though they are just that just that, workarounds, e.g., experiment with the Contour tool, it does a very good job of 'overcoming' this issue. Take for example a 700 x 700px donut shape or a 500 x 500px square (or any suitable shape using any dimensions), split the donut in half so it takes up 50% of the circle, duplicate it and flip it so you have two adjoining, perfectly pixel aligned shapes to make a complete donut or duplicate the square and snap it so it appears adjacent to the first square. In both instances you will see the hairline/gap issue. Make the shapes 2px smaller in width and height then add a 1px contour (with no stroke) to either. Result, overlapping vectors the same size as the original shapes but exhibiting no gap/hairlines on-screen or on export to any raster image format. Is it the perfect solution, no, of course not but it's a viable option for now me thinks...

This is a known issue and relates to the stroke alignment. Stroke Inside creates the artifacts you are seeing. Supposedly setting Stoke Outside should correct the issue, which it does but I've noticed that Stroke Outside then creates a new issue with artifacts (see below middle, you may need to zoom into the image to see the problem). The workaround in this instance is to use Stroke Centre which eliminates both issues. The issue has been reported previously here and has been raised with the Dev team to look into... I would be inclined to raise this as a new 'bug' or 'issue', especially in light of the additional artifacts introduced with your particular graphic when using Stoke Outside.

The background is able to peep through because the edges of both adjoining, perfectly pixel aligned graphics are rasterised and anti-aliased so they can be displayed on your screen, so the edges themselves are now semi-transparent regardless of their perfect pixel alignment. This is how all vector graphics software works regardless of who makes it, can you think of any vector software that doesn't demonstrate this issue? Correct if you mean converting to a single object, e.g., exporting your original three iPhone images to a JPG file. That JPG file if opened in AD will no longer display the hairlines because there are no longer any rasterised, anti-aliased, adjacent edges between what used to be three adjacent images. The point is, it's not wrong, it's a technilogical limitation of how rasterising and anti-aliasing an object-based vector graphic on a pixel based LCD screen works. If you were able to view this on a vector monitor the issue wouldn't exist. It appears to be wrong to your way of thinking but it's not wrong from a technological point of view. I'm sure at some point in the future technology will move on and new ways of displaying vector graphics will be developed but for now, this is where we're at. I think we can agree to disagree but the facts are the facts. I'm not a computer scientist but I'm sure there are other more eminently qualified people who can describe in far more detail how the rasterisation and anti-aliasing of vector objects works when displaying them on a pixel based display and what the techological limitations are. Fact - the white or dark lines are be caused by anti-aliasing of an application where the two regions intersect. Turning off the anti-aliasing eliminates these lines. If the hairlines bother you why not simply turn off the anti-aliasing as suggested in my previous post? I'm unsure how you've constructed you current graphic but I would construct it like this and then there would be no visible gaps? I've made the vertical line orange just to show the three shapes... Can you either upload just the graphic itself or explain how you've created it so we can understand why you are seeing the gap?

That's not how anti-aliasing works... Anti-aliasing uses semi-transparent pixels to simulate smoothing, so by the very nature of having semi-transparent pixels you will see a change in colour peeping through which is a blend between the top and the underlying colours... The balance between the two colours can be controlled by adjusting the Blend Gamma values for specific layers. Hopefully these videos will demonstrate how a single pixel appears when rasterised using your example. Both show a 6px x 1px document, the first showing the two background colours/shapes pixel aligned, the second (as per your example), non-pixel aligned. I've then simply dragged a 1px x 1px teal coloured square across the background so you can see how the anti-aliasing blends both the background and pixel colours. Pixel Aligned Background Pixel Aligned.mp4 Non Pixel Aligned Background Non Pixel Aligned.mp4 The graphic below shows a breakdown of the above process, with the background pink and yellow elements pixel aligned on the top row and non-pixel aligned (as per your graphic) on the bottom row of each graphic... Bear in mind that vector graphics still have to be rasterised so they can be displayed on a screen that uses pixels, to achieve this vector software applies (to differing degrees) anti-aliasing to the vector elements. Since the effect of anti-aliasing is to blend the colour of the top most layer with the underlying colour this means when placing e.g., four squares adjacent to each other, even when perfectly pixel aligned you will see the hairline appear at the intersection of the squares because this is where the anti-aliasing is visible. The hairline is a screen rendering issue only, if items are pixel aligned for screen then the hairlines don't appear on raster export and likewise the hairlines don't appear on final print resolution PDF artwork once printed either. This issue is inherent in all vector based software, AD, Illustrator, Inkscape and so on. I believe in more recent versions of illustrator they have addressed the issue to some degree, possibly by changing the way vector graphics are anti-aliased, but from what I've seen (I don't use Illustrator so I can't test this) this results in the vector graphics having a soft appearance on-screen so they've almost cut off their nose to spite their face. It's really not as simple as that, if it were we wouldn't be seeing this issue... This isn't the case, it just happens not to be noticeable in your Keynote example. Take the same shapes (add one additional square) using the same dimensions and rotate them 45 degrees then the hairlines are visible (they're faint in my screengrab, but they are still visible). I don't know how Apple applies it's anti-aliasing, it may differ from AD, Illustrator, Inkscape and so on but regardless the same hairlines appear. You will likely see this more clearly if you do the same thing with your Keynote example. You will also likely have seen that the visibility of these hairlines is dependent on the level of zoom you are viewing the graphic at, with some zoom levels the hairlines seemingly vanish but then reappear if zooming in or out further. Because this is fundamentally a screen rendering issue, if the hairlines are a distraction you can remove/hide them altogether simply by disabling anti-aliasing. This can be done on a layer by layer basis or you can put any or all your graphics inside a Group and set the anti-aliasing state for the group. By default the elements contained within the group are set to Inherit so changing the rendering intent of the parent will automatically affect all the contained layers. Equally you can overide the anti-aliasing for individual layers within the group by setting the layer's value to either Force On or Force Off. Anti-aliasing.mp4

By default if each of your three images were 333,333 pixels in width, the edges would already be anti-aliased so regardless of snapping them together you will still see the issue because you will have transparent pixels on the image edges but more than happy if you want to upload a Keynote file that demonstrates what you are seeing... I was unsure if you were referring Keynote/Pages/Numbers here since each limits you to a 400% zoom and whilst you can enter decimal places, they automatically round to the nearest whole point. I think you also have to bear in mind that Keynote, Pages and Numbers are not designed for this purpose in the first place, being presentation, word processing and spreadsheet software. That makes sense, thanks for letting me know... Thinking about this as a gap is perhaps misleading, it's not an actual, physical gap, it is transparent pixels. If you take a look at this image and note how the two grey squares are positioned and how they both use fractional pixels. Even though they are snapped together and perfectly aligned, because they don't use whole pixel values the edges of the squares are anti-aliased, i.e., rendered using semi-transparent pixels. You can see this by looking at the vertical gradated line on the left which appears muted because the gradated background beneath the grey squares is showing through semi-transparent pixels. The vertical line to the right shows how the actual background looks without the transparent pixels, i.e., without any anti-aliasing. So the hairline/gap that this conversation has all been about is simply the result of unavoidable anti-aliasing, it is the way software renders fractional pixels when the smallest unit available is one pixel. Using whole pixel dimensions and positioning at whole pixel values removes the need for any anti-aliasing and hence you won't see any hairline/gap. In this instance your original exported PDF would have no hairline/gaps if all created in a single document and exported. Bringing it into Photoshop or Affinity Photo and transforming it so it now has a height of 56.67px and exporting it to say a JPG file would now result in the file having an anti-aliased outer edge so depending on what you did with this file next you would potentially see this, e.g., if part of a triptych of images assembled in a similar fashion to your three iPhone images. There is no way around this (apart from turning anti-aliasing off altogether but that would cause no end of issues with your images), that is just the nature of how this works.

This is because Apple Keynote, Pages and Numbers all work at 72dpi. All three can only display units in either Points, Centimetres or Inches (not pixels). If you take the document you uploaded which is 4,100px x 621px at 72dpi with the three individual images at 1,330px x 621px, 1,440px x 621px and 1,330px x 621px respectively and convert it to points you'll see the numeric values are the same only in points rather than pixels, i.e., 1px = 1pt. If you set up a Keynote document at 4,100pt x 621pt (since you can specify pixels), drag your three images onto the Keynote page/slide and position them manually or mathematically you'll notice that you can only position elements in whole points, i.e., whilst you can type in a 0.25pt or 0.5pt value, Keynote (and likewise Pages and Numbers) rounds the values to whole points, e.g., anything below 0.5pt is rounded down to the nearest whole point and 0.5pt and above is rounded up to the nearst whole point. This effectively means you can only position elements in any of these programs at whole point values, therfore by definition, whole pixel values which is why when exporting to pdf (which is the only relevant export file format available) the file renders correctly, i.e., because the elements making up the file are positioned at whole rather than fractional pixel values. The smallest unit available when rendering graphics is a pixel so fractional pixels will automatically be anti-aliased (rendered using lighter colours), so anything that is offset, i.e., not using whole pixel values will have visible anti-aliasing applied hence the faint line you see when items are not pixel aligned using whole pixel values... A black line with a width of 1px will be rendered as a series of black pixels, but if you make its width 0.5px then it will be rendered as a series of lighter gray pixels creating the illusion of a thinner line. I'm sure you have a very good reason but my question with regards the iPhone graphic is why is the image split into three in the first place, why not just 'assemble' it as a single image, then you wouldn't have the anti-aliasing issue you're seeing between the three images even if the images were not pixel aligned. You would technically still need to position and size your image using whole pixel values to avoid anti-aliasing at the edges but you would eliminate the vertical hairlines you are currently seeing where the three images currently meet... This issue isn't unique to Affinity software, the same 'issue' exists in Illustrator and Photoshop.

I don’t, I can only assume that because it doesn’t influence the exported file that it’s not considered an issue. Like most things I guess it’s optional and either you decide to have it on by default or you don’t. I see no obvious reason for it not to be on by default but equally you can make that the default setting...

The example you posted relating to Clipping Paths is a different 'issue', although it's not really an issue as such because it has a remedy as mentioned previously. Use Precise Clipping is purely used to improve the on-screen appearance by eliminating the red bleed you are seeing with your clipped circle. Exporting with or without this checked makes no difference, the exported file will not show the bleed. Use Precise Clipping.mp4

This is key and the reason you are seeing the hairline, sizes need to be whole pixels, otherwise you are seeing the result of antialiasing on a non-whole pixel which is a side-effect of the way the rasterisation routine works... as you've now seen when the elements are both placed at whole pixel values and are using whole pixel dimensions there is no hairline on raster exports. It will have a gap/hairline for the reason cited above... It does, there are no issues with the magnet/snapping tool in this respect... Image on the left showing pixel aligned images - image on the right showing the subsequent JPG export with no visible hairline Image on the left showing non-pixel aligned images - image on the right showing the subsequent JPG export which still has the visible hairline Where there is an issue however, one which has still not been fixed despite being highlighted several times with support, is PDF export. PDFs are not exprting at the exact size of the source file... If you take a look at the widths for each of your three source elements and then compare this to the widths of the same three elements once exported to PDF then you can see the issue... They should be 1,330 px, 1,440 px and 1,330 px respectively however, the widths on PDF export are 1330.999668 px, 1439.999946 px and 1330.000419 px. All three images are correctly positioned but at the same time they no longer butt up with each other but overlap each other and because they are no longer whole pixel widths, the hairline is visible for the same reason. The issue is even worse with SVG exports in that both the image width and image positions are incorrect on export, resulting in non whole pixel values for both. PDF Exported Image Widths It is possible to remove the visible hairline onscreen by adjusting the Coverage Map in the Blend Options, however, this is not necessary for raster export assuming everything is perfectly whole pixel aligned and it is ignored on vector export but at least it helps from a purely visual standpoint when creating artwork. Visible Hairline Onscreen Using Default Coverage Map Visible Hairline Onscreen No Longer Visible When Coverage Map Setting Adjusted One thing I was going to point out with the file you uploaded is that the three elements are not perfectly aligned between themselves so you can effectively see the joins so to speak. I don't mean they are not pixel aligned, they are but you can see the small issue below...

Which file format are you exporting to, on Desktop, both JPG and PNG export with zero bleed regardless of whether the precise clipping checkbox is ticked, PDF has a thin keyline but equally if you set the circle to no fill then the PDF is fine too. Did you check it on the iPad as well?

That checkbox won't fix the other issue you have... these are two different 'issues' I think. There are numerous threads about the thin line 'issue' e.g., here... Regarding whether the option for the 'use precise clipping' is available on iPad, this is the response from the Affinity moderator team... I've not tested this as I don't have the iPad version of Designer but hopefully you can confirm if it works for you? No idea why it's not on by default though it sounds as though it's just a screen rendering, 'visual' issue if it exports correctly.

抱歉，我的意思是使用 Apple 诊断程序（不是磁盘实用程序）来检查任何潜在的硬件问题，但也许最好将有问题的 mac 带到苹果商店进行检查。 我会确保您在运行任何诊断程序之前对所有文件进行完整备份，以防万一。 在我之前的 MacBook Pro 上，我的硬盘驱动器出乎意料地坏了，所以很高兴我的宗教备份到位。 我认为它似乎越来越指向硬件或显卡问题。

在这种情况下，这可能只是 MacBook Pro 工作时的显卡问题，您是否尝试过在工作机器上运行 Mac Disk Utility 应用程序（如果可以的话）？

这个问题似乎是机器特定的，看起来好像有什么东西影响了您当前设置的蓝色通道。对于您在第一篇文章中上传的视频，当您复制 Google 徽标和其他图像并从剪贴板新建时，Affinity Designer 中默认调色板的蓝色滑块会变为绿色，此时它应该显示为黄色，并且所有三个滑块都在同一位置值为 235，一旦应用了从剪贴板新建，色域就会发生巨大变化。 您在第二篇帖子中上传的视频中再次看到了此问题，该视频显示了 Affinity Photo 中的频道调色板。复合蓝色通道不是显示蓝色，而是显示紫色。 我认为我和 @Dan C 都没有遇到您上传的 Affinity Designer 文件的任何问题，这表明您使用的 Mac 存在问题。您能否在另一台运行任何 Affinity 应用程序的机器上测试您的文件，以确认情况确实如此，即您在另一台机器上没有遇到此问题？ 顺便说一句，您是否曾在任何时候使用当前设置的外接显示器或通过 HDMI 将您的 Mac 连接到任何其他设备，我在问，因为这可能会导致与颜色相关的问题？

您附加的 PDF 文件不是从您附加的 Affinity Design 文件的同一版本创建的，因为徽标和芯片的位置在两个文件之间不同，所以可以看到。 您附加的 PDF 上显示偏色的问题是因为芯片图像仍在使用彩色 LCD ICC 配置文件，而不是文件中其他图像使用的 sRGB ICC 配置文件，这可以在分析 PDF 文件本身时看到。 来自您所附 PDF 的 ICC 配置文件 然而，您附加的 Affinity Designer 文件中的芯片图像确实使用了正确的 sRGB ICC 配置文件，并且在导出为 PDF 时不再显示偏色，因此如果您导出附加到您之前的 Affinity Designer 文件，您应该会发现相同 邮政。 来自附加 Affinity Designer 的 ICC 配置文件一旦转换为 PDF 如果确实如此，请告诉我们。

是否可以附加带有嵌入图像的分层 Affinity Designer 文件，以便我们查看。 如果没有，您能否上传一个文件来演示您遇到的问题，因为这样更容易尝试找出导致问题的原因？

Although not quite the same issue, it is I believe related or at least a similar 'bug' to this thread...

Assuming you have Convert opened files to working space checked under the Colour Preferences, though having said that, even with it checked it doesn't appear to convert your background, not sure why it's not doing so?