Vaaish

They could also have just used the eyeball icon to indicate visibility that many other applications use.

Cool, thanks! It doesn't seem that my case is listed so I'll go ahead and post it. Multiple consecutive inline tables are not importing correctly to Publisher. They appear on top of each other and are not affected by wrapping or any other means I can see to space them out. The desired behavior is that the table is placed inline below the previous table. Attached is the IMDL, Publisher file and a PDF showing the correct placement. Skitarii3x.idml Skitarii3x.afpub AdMech0.94.pdf

No need to get defensive. I'm well aware it's a beta and I didn't want to post a bug before verifying that the functionality was supported.

Is there a list of unsupported functions for IMDL import? I was trying it out on an old document that has a lot of inline tables and it's doing this:

I think I'm missing something here or at least this there has to be some confusion of terms going on. For context, I've used Illustrator for over 15 years and in the last year I've been poking at using Designer since I'm tired of the subscription model pricing for CC. Just double checking today, I find very little difference between Designer and Illustrator when it comes to the function of art boards though there is a good bit of difference in how I access things. Designer's artboards drag contained objects with them when rearranged just like Illustrator. Both programs can print or export artboards with printers marks, both can create ad hoc artboards. Sure Illustrator uses a panel to manage them while designer places them in the layers panel, but neither option seems significantly better. I can't speak to the database functions as I've never needed them, but I really can't say I notice much of a difference between the apps when dealing with artboards outside of Illustrator having a properties panel and Designer treating them more like a shape once placed.

The blue on the bottom one is out of gamut for CMYK printing. If you're doc is set to CMYK it'll show up like the top one regardless of whether it's in Publisher or InDesign. I pulled your bottom image into InDesign with the doc set to CMYK. If you want to test this, open the image in Photo and then change the color space to cmyk, it'll switch to look like the top one.

This is the first time in 10 years doing this I've had a request like this one. Usually if an EPS is requested you send the eps and that's that. Just straight up exporting an EPS will result in what you've found, any rasterized bits being embedded in the file. Further, you can't just export and relink them... at least in CS6. They are in some kind of weird state and of course you can't open the EPS in Affinity to attempt exporting them because you'll run into the same issue when you export.

I recently finished a project for a client to test Designer in a production environment. This mostly went quite well until I got a very odd request from the printer. They asked that the files be delivered as AI or EPS with all images linked and provided as separate files. This set off a rather frustrating day of trying to find a way to get the files to the printer as specified. I did get it "working" but it was a very messy process: Export from Designer as PDF Open PDF in Illustrator Manually move all template elements to a new layer Copy out any rasterized elements to Photoshop Save these as tiffs relink the files save final eps I've been trying to figure out a simpler way to do this with just affinity products and I'm a bit stuck. The problem lies with the use of gradients on the strokes. When exported as an EPS from Designer, these strokes are expanded and the gradient is turned into an image fill. This makes it impractical to accommodate the printers needs. Exporting as a PDF still expands the strokes, but at least the gradients come in as unknown vector data. Does anyone know a way I can get Affinity to export the EPS with all elements that it rasterizes as linked? I've attached the file for anyone if they want to give it a go. TuckBox_Final.afdesign

I didn't realize applying multiple masters was possible. It's really hidden away there. It still seems a really really odd way. Totally alien to the InDesign workflow of one master per page but allowing masters to be based on other versions. That does create some nice options for masters and COULD be a functional alternative to nested ones, but the interface for this needs a major overhaul. Why not allow us to select multiple masters initially instead of one at a time? Why not let us select multiple masters in the master page studio and drop them on at one time? anyway... I digress a bit here. Regardless of multiple masters, there still needs to be a way to identify them visually on each page. This could be as simple as adding an extra line under the page name that says which masters are on there. Maybe it we could set master page colors and have a swatch for each master applied next to the page. This is critical information to know at a glance for complex documents.

@Jobalou The terminology affinity is using seems to be different but the effect is the same as the forced line break you're looking for. Maybe the menu option could get updated to clarify it's a forced line break?

The new beta adds in linked values for the bleed and margin settings and bleed preview which is very nice but we need to have bleed settings on the new doc screen too. I'm still really not sure what master pages are good for here either. Other than very basic use setting design elements and header/footer stuff they seem really awkward. I'd love to hear what the dev's goals are for these.

Has anyone found nested styles in the beta? If not, these would be great to have. Very useful.

@walt.farrell Sorry, yes the picture frame tool. I was going off memory and defaulted to Image Frame. Edited

Thanks walt, but that's not really what I'm talking about here at all. The current function of the place image tool that you're referencing creates an image that has limited options compared to an image placed using the image frame. For example: Place Image only allows you to scale and replace the image or file that's been selected. (I should note that IMAGES selected will still give fill and stroke options though no corner options, but files, like a PDF will not give any options.) Picture Frame allows you to specify how the image scales within the frame, scale the image, replace the image, add frame fill colors, add frame strokes, and adjust frame corner options. That creates two objects that look the same but have different properties and no really clear benefit to this distinction. I'm suggesting that instead, the place image tool create an object in a way that is consistant with the object created Picture Frame tool so that either route provides consistant handling of the images. I'm not asking for workarounds or potential extra steps to get the effect, I'm pointing out what to me is an inconsistency that's at odds with how I (the user here) would expect the tools to function. I'd expect that regardless of using Place Image or Picture Frame, I'd have the same options available. Example.afpub

I've been messing around with the beta to see how it holds up and there's a lot to like, but one thing that frustrates me to no end is the Place Image and Picture Frame tools. Initially I used place image to, well, place an image only to find that I couldn't access any of the controls for the image and was limited to just replace doc/edit doc which is useless for most things compared to the controls you get with the Picture Frame tool. I Immediately did the same thing with the Image Frame tool and effectively had an identical result, but with the embedded doc as the child of the Image Frame which allows for adding all the expected properties. I'd like to suggest that the Place Image tool just go ahead and create the image frame wrapper around the selected image. I believe the appearance and function would be identical to what's here now with the added benefits that the structure and properties are uniform for all image elements in the doc.