Dave Harris

I'm afraid this isn't something the Mac App Store supports.

Hi Warriotox. Everything in that document is rasterised to one bitmap per page. Also, it is RGB, and uses JPEG compression. Unfortunately the current Mac App Store version uses a Core Graphics code path that only supports JPEG compressing in limited circumstances, so even if you rasterise everything it can't get a small size. The current beta has a new code path that is better at JPEG, so I suggest you try using that instead. I found that using RGB rather than CMYK made a surprisingly large difference to how well the document compresses. I guess this is because it uses photos which were originally RGB, and converting them to CMYK produces more data that JPEG just doesn't handle well. With the current beta, I used File > Export > PDF > More and set Rasterise: to Everything, DPI to 300, Colour Space to RGB, and Profile to sRGB. That produced a file sized 637 kB. Without rasterising everything the size was 1.09 MB.

Affinity Designer already supports this. Select your vector shape and use Layer > Convert to Text Frame. Alternatively, select it then click on it with the Frame text tool. Affinity Photo doesn't have the menu option, but does have the click-with-Frame-text-tool shortcut.

In the meantime, you can access the More features from the Export persona, if you need to. You can also save them as a preset from there, and use the preset from File > Export.

Hi, Chacri. Your drawing uses a lot of noise. Since EPS doesn't support noise natively, it has to be turned into bitmaps. Those bitmaps will be large because the document is large - roughly 2,000 x 3,000 pixels - and there are a lot of them. I think there is 100% noise on every element except the sky. I'm not sure what you mean when you say the eps.file is locked. It won't be very editable because very little of it is vector.

Currently Affinity draws the characters the user specified in the font the user specified. If the font doesn't support them, most other apps switch to a different font that does, but we don't do that yet. For example, I opened TextEdit, set the font to DIN Condensed, pasted your sample text, and TextEdit automatically changed the font to Lucida Grande. We plan to add this feature in due course. In the mean time, you should be able to switch to a suitable font yourself. For example, I pasted your sample text "š, ě, ť, č, ř" into a new document using Lucida Grande, and they appeared fine to me. Which fonts support the characters but with wrong widths? If they're available I can take a look to see what they are doing.

We do plan to add dynamic preview to the Export persona. In the meantime, have you tried using its Continuous Export feature in conjunction with using another app to preview the exported file? We already have a number of options to help produce good line art, including the pixel snapping stuff and the pixel mode of the main canvas view.

We will probably do that eventually, but probably not for a few years.

Kerning via the Character tab was fixed in the 1.3.5.3 beta.

It looks like we have a bug with the SVG export of text with leading spaces. We'll get it fixed for the next beta. What is interesting is why there are any leading spaces to go wrong. It's because the text gets split into many small fragments, because there are many changes in tracking. Some of those fragments happen to begin with a space. The tracking changes were added by the PDF import, because the font you have set, Helvectica Neue Regular, has different character widths to the one in the PDF, ArialUnicodeMS-Bold. I suggest you do one of two things. Best would be to reopen the PDF, and in the font substitutions specify that ArialUnicodeMS-Bold gets replaced by Arial Bold. That font seems to have the right widths and avoids getting the extra tracking adjustments. When I do that and export with "SVG (for web)", I get a file size of 13.09 kB (rather than 50 kB or so you were getting), and the result looks fine in Safari and other apps I tried. Alternatively, if you really want to use Helvectica Neue, select all the text and set the tracking to 0 manually using the Character tab. Either way should simplify the text and avoid the problem.

I'm sorry, but we don't like to give dates until a feature is almost finished and we are sure when we can deliver. Otherwise we find things sometimes take longer than we expect, and users get annoyed. However, you can rest assured that we will provide the features promised on our roadmap in the 1.xxx software, as free updates. We have already added many features to Designer post-release, and Photo will be the same.

You can also change the width and height of individual letters, without changing it into curves, by using the scaling options in the Character panel.

Are you talking about we call "Symbols"? Where one rectangle linked to another such that edits to either are automatically applied to both? If so, this isn't available yet but is nearing the top of our to-do list.

We're moving towards improved printing now, and expect it to be in the next Mac App Store update in a matter of months. EPS is a terrible exchange format, because it does not support transparency at all. It does support vector clipping, which we already use where possible. You really have to design carefully to avoid rasterising if you intend to use it. The best vector format for vector art is PDF, especially if you use other than sRGB. Improvements in our PDF export will also be coming over the next months (and PDF/X is already in the current beta).

I'm afraid we don't yet have vertical text alignment. We will add it in due course - Affinity Publisher will need it.

We do have some infrastructure in this area already. It's not on the Option key, though. I think we're more likely to add user-defined filler text than that particular form. It's not a priority at the moment.

It does for me. If the original document is RGB, then the MAS "Print" preset will PDF it as RGB. The Beta "Print" preset will PDF it as CMYK. This explains the difference in colour. Finder just isn't very good at previewing CMYK colours in these PDFs. To confirm this, use the MAS app, change the document colour model to CMYK, and export it with "Print" again. You'll get the same colour results. PDF/X has to be CMYK. I think the only issue here is whether our "Print" preset should force CMYK too. Maybe only PDF/X should do that. PDF/X specifies colour in a slightly different way. It looks like Preview is doing a better job in that case. Is this happening in OS X Preview? I've not been able to reproduce it. I don't have the fonts "Kabel Dm BT" or "Hand of Sean Pro", so maybe it depends on them. Do you get the same effect with Arial? Perhaps. I don't believe it is corrupt. This may take some time to investigate. Have you tried other presets? PDF/X-4 is standard, and supports RGB images and transparency. "Export" tries to preserve the most information. That would be a good thing. The difference is probably in how the MAS version outputs fonts; it is needlessly bloated.

I've not been at work today, imacken. The earliest I'll be able to look at it is Tuesday.

My only other suggestion would be to change the file extension to .eps and see if that helps. Older Illustrator files were actually EPS files in disguise, and that may be what Rhino is producing. If that works, try using the current beta, where this renaming step isn't necessary.

Edit > Defaults > Synchronise from Selection will do that. There is also a button in the top toolbar that does the same.

Could you attach a sample document so I can look into it?

Is your document RGB? The export presets you mention all use CMYK - they are all for print which needs CMYK inks. If you use the Web preset, that forces sRGB, and the Export preset will use the colour space of your document: do those have the same issue?

Also notable: the Export persona now supports PSD, but it ignores the slice areas and always exports the whole document. We'll get this working as expected soon.

Also notable: the Export persona now supports PSD, but it ignores the slice areas and always exports the whole document. We'll get this working as expected soon.

If you've done any work in the document, you may have done something that needed to be rasterised for PDF, and the rasterisation will happen at the document's DPI by default. Then when we import the PDF, we'll deduce the DPI from those rasterised bitmaps, and get back the number you first thought of.