Guillermo Espertino

I've just experienced a minor but very frustrating encounter with this problem. Some fonts were missing, I missed the missing fonts warnings and I ended up exporting and publishing some stuff with Arial instead of the sans font I carefully chose for the design. There should be some sort of visual cue on the design when fonts are missing. Adobe Illustrator puts a nasty pink highlight that is quite difficult to miss, and that works. I think Affinity should use a similar approach. Some highlight, a visible bounding box in a specific colour, or something like that. It's very easy to miss that popup warning when you're in a hurry or tired after a long day of work, and sometimes the font substitution is not that obvious (sure, you will notice if a serf font was replaced by arial, but when you're opening a design done with sans serif text just for a quick export and you don't zoom in or modify text, it's easy to make a mistake).

Exporting to raster formats with bleeds when using artboards seems to be impossible. The physical size of the image includes the bleeds, but they are empty. I'm attaching a simple file reproducing the bug. It's a color rectangle that should bleed, but it doesn't when exported as jpeg, png or other raster formats. missing bleeds.afdesign

@stokerghi, Normally I place the assets in the design and leave the color correction and grading for the last step. So it most likely went this way: Create an Picture frame select the image inside the picture frame with double click or via the layers panel Use the transparency tool to blend it over the background with a linear gradient Select the picture frame and add the HSL adjustment. I don't know if this helps, but I normally use linked images, not embedded (I embedded the image in the sample file for convenience afterwards, but originally it was linked). As a temporary measure I solved this by rasterizing the bitmap assets affected by this issue in a duplicate file, and as I expected worked fine. Of course it's not a desirable solution as it makes the workflow destructive. Just a moment ago I discovered that if I group the picture frame and apply the HSL adjustment to the group it also solves the problem. As you suggested, moving the adjustment to the top level of the layer stack worked, so using a group in order to create a top-level element for the picture frame worked as well. This serves as a reasonable workaround without losing non-destructive editing, but imho this inconsistent behavior is still a bug and should be taken care of. Thanks for your help.

@EmTdid you delete my post? I uploaded an example file and details about the bug but now it vanished.

Hi, I've been experiencing the same issues, and iirc it's something that was also present in v1. I'm attaching an afpub file and the exported PDF showing the problem. It seems that the HSL adjustments applied to the master node get passed correctly to the PDF export, but the channel nodes are ignored. In my example you can see the overall desaturation applied got exported correctly, but the individual channels (cyans and magentas) seem to be ignored. This bug affects also the PDF export from the other apps, not just Publisher. HSL-bug-PublisherV2.afpub HSL-bug-PublisherV2.pdf

@stokergThanks for your reply. I already applied the workaround of rasterizing the background layer manually. It solves my immediate problem, but I think this is a bug anyway. The noise filter is applied to a group in an underlaying layer, what's the reason for everything else to get rasterized? The other elements aren't in the group or have any filters applied. It's odd that they are also rasterized. I've read the thread you linked, but it refers to an adjustment layer affecting the parent layer (which is something I would expect). In my case, it's affecting a completely different layer, not a parent layer. To be clear, my design has two layers: Fondo (background) which I expect that everything inside is rasterized, as it has a group with an adjustment layer; and "texto y vectores", my vector elements that shouldn't be rasterized at all because they are in a completely different layer. Would you please forward this to developers for further inspection?

I created a cover design for a Book I'm working on. The background of the design has many gradients and blends, so I grouped all the background elements and applied a subtle non-destructive noise effect to the group to force gradients to be rasterized and dithered. So far so good, the exported background has the quality I expected. But after doing that, I noticed that every vector object in the design is being rasterized too, despite they are on top of the filtered background, have no effects and even belong to a different layer. All of the things I want to keep as vectors are on top of the background that has to be rasterized, but for some reason they are getting rasterized too. As far as I know, these object should remain vectors, but they aren't. This seems a like a bug, unless I'm missing something. I'm attaching the aforementioned design in the original afpub format and the exported PDF showing the issue. Libro CAS - Tapas.pdf Libro CAS - Tapas.afpub

Yes, but given that different devices (even Macs with retina displays) have different resolutions, that's not what users get. If you have a new MBP with 254 ppi screen, 144 ppi won't give you a 100% zoom in the workspace. The only way you can make sure that's the case, is being able to detect/specify the actual resolution of your screen and scale media to match. Otherwise you're forcing some arbitrary resolution and creating the problems we've been discussing. What I'm missing in this conversation is an explanation of what's the benefit and who wants the things the way they are now. So far it has been explained the behavior is by design, but for whom? EDIT: I've done some research about the 144 dpi thing, and now I understand where it comes from. One of the strategies for presenting bitmap images on highDPI screens is applying a multiplier to scale them up, depending on the screen detected by the operating system. 144 dpi is 1.5x 96 dpi (96 dpi being the modern ballpark value for standard resolution flat panel monitors, closer to real size than the old 72 dpi). This means that instead of showing tiny images, the software will apply a scaling for more comfortable viewing, albeit it won't be precise. So, if Affinity apps and social media apps are getting scaled by the same multiplier (1.5x) on screen, then yes, it makes sense to rasterize the vector artwork to that resolution so the size at 100% in the app matches with the scaled up display on the rest of the applications that get upscaled. However, it's important to note that for this to be true you have to be using affinity apps on a system that matches that condition: A HiDPI screen and scaling set to 1.5. Maybe this is default for Retina Apple computers, but it doesn't seem to be the case for most of the Windows computers, where standard definition screens are still the most common. At any rate, all the above describes a situation related to displaying the artwork at the expected size in the app. The problem of exporting an image half of the expected size remains: If you wanted to create a 1080x1080 social media post and the export persona exported 540x540, it's not the right size for ANY output resolution. It's half of the expected size at 72, a quarter of the size you need for 144! The rationale for images for the web seems to be the same: If a platform asks for 1080 pixels images, your minimum size will be 1080, and you'll have to produce higher resolution images (higher pixel count, not to confuse with dpi) if you want your images to look crisp on high dpi screens. It's NEVER producing images smaller than the target resolution!

Have you noticed that that Apple documment doesn't mention dpi? It just covers creating artwork with pixel size doubled and tripled for higher resolution displays. That's perfectly fine of course. If you want your media to look good on a high dpi screen, you want more pixel density. Nothing written there seems to justify that 1x produces half of the pixels you expect. Regarding the export function vs. export persona working different... what can I say. That inconsistency is another display of poor design. This has a really simple and quick fix: Make the social media templates 72 dpi. And I know I can do it myself, but it makes no sense that the ones that come with the applicatoin are 144 dpi and behave like that in the export persona. I mean, the export persona could still create images at 2x, 3x, 4x or whatever scaling at 72 dpi if the images are going to be used on high dpi displays. What's the point of that 144 dpi resolution for templates in the first place?

Thank you very much @MikeTO!!!

Do you seriously think it is reasonable that a simple task as exporting an image for the web coming from a 1080x1080 pixels template requires a seasoned designer with 30 years of experience in computer graphics to check the documentation in order to understand how it is supposed to works? I can see it's a design decision and that the output is consistent with that decision. I'm saying it's awful user experience as it collides with the meaning of "pixel". Resolution doesn't belong to a raster workflow with pixels as units. The current design fails to address that. Vectors have to be rasterized to be exported as bitmaps, I know, but when users pick a template set to pixels or create an image with pixels as units for screen delivery, they expect pixels. I'm going to leave this thread alone and stop repeating myself, but please Serif, revisit this design and consider some options that don't mess with pixels and resolution when screen units are used. I'm sure there are ways to do it without breaking the valid use cases (i.e.: export for physical media).

Just converted all the images to image frames and nope, that was not the source of the problem. I'm attaching the full book and all the sections. I'm not sure whether it will be of any use without the actual images and typography, but please take a look. One of the images that is getting the wrong bleeds is the one from page 15. Try putting any image there and see if it exports with proper bleeds (keep in mind that exporting a chapter individually works fine, the problem appears when I export the book containing the chapters).