Search the Community

"Exchanging back and forth" is maybe a bit exaggerate. At least in the cases in my experience, the workflow doesn't involve frequent exchanges. The typical flow is this one: 1) Collecting information and illustrations 2) First draft in something like Word or GDocs (here comes the Cloud!) 3) Assembly and editing in a page layout program 4) Proofreading on PDFs 5) Editing in the page layout program 6) Delivery for distribution or printing as PDF 7) Delivery of interchange data to directly managed translators 8) Delivery of the original materials to other partners, doing their own translation/adaptation That's not the method I know and use. It would be simply foolish doing a translation in a page layout document. This would mean less coherence and higher cost, by not reusing any existing translations. What is usually done is giving the translators a file that their specialized tools can read, convert into easily manageable chunks, and then return in the original format. This means that a translator might not even see the layout of the original document (even if this is warmly recommended, but I know that not everyone does what is best to do). The file format that the specialized tools used by the translators may be INDD, but it is very often IDML. An IDML file originating from InDesign, translated in Trados, returned as IDML and read from Affinity Publisher, would have the same amount of errors that an IDML file exchanged directly from InDesign to Publisher would have. Trados would hardly introduce variations (and when it does, they are really minimal). Some translators are more scrupulous than others, and return you the translated text as a page layout document, in the format you have agreed on. This can be done with InDesign. But it can't be done, at the moment, with Publisher, not being compatible with the tools used by the translators. Yes, it's the latest one we can clandestinely found in the dark web. It has been removed from the Adobe archives. The promised new version is not yet there. How relevant IDML is, I can't say. I don't even know the current state of this job. I know that going from InDesign to an alternative program has been considered important by the respective developers. Going the other direction, who knows? If Serif's target is (also) the professional market, I guess it is extremely important, for the interconnection with other tools and the increased acceptability it will warrant. Apple, for example, has worked hard to make their productivity apps compatible with the ones of Microsoft. Standard formats are continually developed. Apparently, Serif has already subtracted one tenth of customers from Adobe, and if this is true this is starting to be troublesome. Making things more complicate to a competitor may not be the definitive countermove, but it is better than nothing. Adobe (like Microsoft) usually buys and assimilate or destroys any potential threats. With Serif it might be more complicate, since they already went though a buy and repurchase. They know how dangerous it is, the world outside of Sherwood. The third-party converter you cited is not the same as an export feature from Publisher, because it is very expensive and, apparently, not very deep or accurate. It would work for a rough conversion, but I'm not sure it would be better than using PDFs for this. Hardly the solution I'm hoping for, and that would be acceptable by the receivers of my files. The advantage of the Affinity apps, for the customers wanting to use them, seems at the moment untouched. Adobe will not switch back from subscription to one-time payment. Their structure is so huge that I don't expect their prices will go down (they have, actually, gone up). Their dominance is still basically untouched, and they will always get the advantage of the incumbent (no top-manager will understand that there are alternatives, no student will want to be out of the club of their friends*, no obsolete pre-press service will want to offer alternatives and learn new tools). So, I see an IDML export feature as an unlikely trouble for Serif. The only trouble I see is if it remains out of the professional world, for lack of a way of interchanging data. Paolo * A few universities, among which the university of Melbourne, are actually switching from Adobe to Affinity. Wisely so: they have to teach techniques, not tools. And make the costs sustainable.

I've expressed my desire for IDML export elsewhere, but I'll reiterate here. Even if all the features I need are implemented in Publisher, not being able to interconnect with InDesign will exclude it from my workflow. It has been objected that a team must use the same tool. In my experience, this is not a universal truth. For example, in my career I've been using FreeHand and Illustrator, while my colleagues have been using Illustrator or CorelDRAW (apparently, the preferred drawing tool for technical designers). I often receive and send DOCX files, just to discover that the originals have been made with Apple Pages or LibreOffice. My current workflow requires exchange between my InDesign files and the translators' CAT programs (not the same: each one uses a different one…). These want an INDD or IDML file, or an XML file if available, whatever the originating program. The page layout program can be used by the most scrupulous ones to fix some details that may go lost in the conversion. However, there is someone who wants InDesign files. I could simply convince them to switch to Publisher, if it wasn't for the fact that they are higher in hierarchy than me. I guess this is a typical situation: an army of freelancers that would feel at home with Publisher, but are forced by a top-manager to use the "industry standard" solution. In my part of the world (generally called the Occident or the West) the jobs landscape is quickly changing from a relation between a company and its employees, and one where a company hires freelancers. This is the perfect scenario for something like the Affinity Suite. If only it could connect with the old "industry standard"… Adobe has already hidden the IDML specs document. It should mean that they wouldn't be too happy, if IDML export from Publisher does happen. Paolo

Hi @Old Bruce, Thank you! I changed the dpi, but didn't work for me. 812x550.idml 812x550.indd

It would be very useful to have ability of selecting default "opening" zoom level for exported PDF (initial view) in Export dialog. Like in InDesign while exporting to interactive PDF where is option "View" for setting of initial view settings of the PDF when it is opened. Indd has there several options from specific zoom values (25%, 50%, 75%, 100%) and several useful options, mainly "Fit to page" and "Fit width". Also initial "Layout" settings of the exported PDF (One page, facing pages etc.) would be nice to have.

Hi, Upon re-opening Publisher files, some of the linked assets (Illustrator files) shift in their frames, clipping content (see screen shots). Locking or unlocking the assets has made no difference, and there appears to be no correlation between asset placement method/layer structure and this unwanted clipping behaviour. The Resource Manager links are all showing fine. The Finder preview image of the document looks fine, and the previously exported PDF version also looks fine. Please see screen shot for OS and hardware specs. I need to make text changes to the doc and don't want to re-do areas of the document that have already been finalised and approved by the client! After a very good start with migrating previous client work from .indd to .afpub, this issue has made me very nervous about file integrity and consistency moving forward. Thanks!

We bought a licence for our studio. I must admit it's pretty impressive. The INDD file has saved many styles in the document, after a small cleaning, everything's ok. Finally, for us, it appears to be a professional and working solution.

Dear Affinity team! Can we get an official statement if the IDML (InDesign markup language) file format will ever be supported for export from Publisher? 'Ever' like in the next few years... I assume you are aware why this is important in a mixed team with Adobe products. It's great to be able to import from InDesign, but as of now it's a one way ticked. Not being able to export from Publisher to InDesign means the whole team might be forced to use the Affinity suite, if just one member decides to use Publisher. That often results in the decision to not use Publisher at all. It would be desirable to leave the choice to the user, of course. In my book, the Affinity suite in the meantime is on par or superior to the equivalent Adobe programs (disregarded any cloud AI features etc.), but it's super hard to convince our office superiors to switch. If roundtripping would be possible, the matter would be a very different one. Even if IDML might not be fully feature complete compared to the .indd or .afpub formats, it is feature rich enough to work as a common ground. It surely would for our needs. It has been asked before, I know, but I could not find any definite answer to your company policy in this regard. Thanks a lot!

You could get a short subscription to InDesign and convert your INDD files to IDML. That's probably your least expensive approach. It's extremely unlikely that INDD files will ever be handled directly in Publisher.

Would be a great feature to be able to open indd in Publisher.

Has someone tried Markzware yet? This is not the first time I'm landing on this page: https://markzware.com/products/pdfmarkz/ - It's pricey and I'd like to know if someone has tested this tool. The principle seems easy: Converting a suitable PDF file into INDD or AfPub. For now, this could be a great solution for those, like me, who love working in Affinity Publisher and have to share the work with a team on Adobe InDesign. And I must say that for me, when I have no other solution than working INDD, I can feel the pain Way much longer, way much unintuitive... Text boxes are a hell on INDD... Resizing takes ages. No way. - So any feedback on Markzware is awesome. Let us know. Regards,

Because I got work done that was due this afternoon last night and I'm somewhat bored, I made this little comparison. I grabbed an InDesign sample brochure and packaged it along with an .idml file. The sample filed used a certain free font. For ID, the font doesn't actually need to be installed if these fonts reside in a folder named Document Fonts. The Viva Designer sample opened the InDesign file (versus the .idml, but the results are the same as opening the .indd version in this case). The main font used was reported as missing. VD handles these missing, uninstalled fonts different than ID or QXP (more on QXP's handling later). With VD, one can just drag and drop such fonts onto the open file and they become available for that publication. Neat feature, but I would prefer the folder method of ID and QXP. VD handled this publication better than either APub and QXP. Mainly for one reason: VD can/does include ID's method of using the custom underline property as a text highlight method. With APub or QXP, the white text that should be highlighted shows with a normal underline whereas VD has the colored background with the white text. In order to display this properly in QXP or APub, one would need to know, firstly that this text is suppose to a background of a certain color and size--what this highlighted text is suppose to look like--and secondly, replicate it using their respective methods for this effect. This highlighted text is used three places in the brochure using different color each time. But all QXP and APub display is white text with a white underline versus the brochure using yellow, red and green highlight via the underline property. As with QXP, VD properly displays the shadow PDF used. I've hidden the image that sits on top of this PDF shadow to demonstrate that VD and QXP, neither having a document DPI (as ID also) the shadow is full size whereas APub shrinks it due to the use of having a document DPI. VD also handled the overridden space after and the line spacing for the headline at the top of the column versus APub and QXP requiring adjusting the height of the text box for the heading to display. As regards the font issue, APub would need for the fonts to be installed. QXP requires a slightly font folder naming, so I copied the Documents folder and renamed the copy Fonts. However, both ID and QXP can use a master fonts folder place where these document specific fonts are available for the application to use for any publication without the need to install them. While not shown, the first page of this brochure has a map as a graphic. APub properly used the map image box's run-around property, pushing a column's text over to its right side. VD and QXP requires wrap-around image boxes to be higher in the layer order it is suppose to affect. This map in VD/QXP needed moved to the Tex layer and above the text in the layer order for the text wrap to work. In addition, I had to play with the run-around properties in VD. Once moved, the values were reset to zero so those values needed re-entered. In short, there were differing issues in all three applications. However, I believe with this particular publication, VD handled it best. If I was more bored, I would have hunted down some of my other test publications that showed where APub was near perfect and QXP/VD fell short, or specific publications where QXP was the best versus APub/VD. Viva Designer: QuarkXPress: Affinity Publisher:

Hi @joe_l, Are you aware which program the file was originally created in? Affinity's PDF interpretation is not picking up the blanks/spaces whilst Acrobat is but I'm wondering if this relates to Ken's explanation in the thread linked below if tracking/kerning has been used to create the blanks in the PDF file originally, and Publisher is having to guess where it thinks the spaces should be during the interpret. Edit: Just checked the PDF properties and it looks like it originates from InDesign, I would be interested to see the original .INDD/IDML file where the text originates from.

It would be good to be able to export indesign format or Ai format because since all the Adobe suit is industry standard, but it sucks and it's ux outdated, we need some features to work for profissionalismo without going back to adobe. Photo needs AI tools Designer needs Blend tool Publisher needs indd format.

Thanks a lot! This feature is one of the few things that I really really miss compared to INDD.

Can it? I read that it can import and export IDML files, but not INDD ones. But maybe I'm lost in that messy web site. Paolo

Because .idml is a documented and is constantly updated as to new InDesign features. .indd is not documented and so is a blackbox file format. There is at least one application that can open an .indd, VivaDesigner.

I use Adobe Creative Cloud apps, and to import an InDesign file to Affinity Publisher, you first have to convert it from .indd to .idml while in InDesign. Affinity Publisher cannot handle an .indd file format, but there are other non-Adobe apps that can. What I find curious is that the .idml format is so old: it was used in the Adobe CS4 suite and dates from 2008.

Which format are you talking about, IDML or INDD?

I create specification sheets that have the same details repeated for different products, when using Indesign I can create tables as objects on master pages. I can then insert the objects on to the different pages and if anything changes I can just update the table on the master page and it automatically updates the tables on all the other pages. Is this possible in Publisher as when I export the INDD to IDML it doesn't copy the links just the data.

Hi, I've been lurking in the forums for quite a while now on scripting-related topics, hoping to see it added to the Affinity Suite. I run a comic localization company, and we use InDesign and Photoshop extensively in our business. Since people were mentioning usecases, I will give an example of the two main ones it would be great to have so we could switch our large team over to the affinity products: 1. I have built up a complex system (web GUI, server etc) to control (the very expensive) InDesign Server. We received thousands of chapters from Japanese publishers in InDesign containers (it's the dominant format in this industry). Since our team operates in Photoshop, not InDesign, I have a system that ingests these files, and converts them to PSD files. I also have an alternative pipeline that exports the contents of an entire InDesign project to a PDF file. Both of these are essential to our workflow. I know that due to the difficulties of implementing .indd support in Affinity Publisher, the full workflow will probably never be truly replaced, but Publisher can at least open .idml which we can mandate the usage of to some extent. An essential part of this is mimicking the "Bridge" functionality. I can use the (admittedly ugly) "BridgeTalk" functionality of InDesign Server to interact with both InDesign and Photoshop at the same time, so having the functionality to script between different Affinity apps would be nice, although not required. Throughout this entire workflow, something that has been really nice about Photoshop's scripting is that I can do literally anything I can with Photoshop actions in the scripting language. The process is a little painful, but if the docs suck for a specific operation, I can record an action in Photoshop, then use publicly available tools to convert the action file into a bunch of scripting commands, which has helped when doing things people don't normally do. Overall, the Photoshop portion involves importing the exported PDF layers from InDesign into a document as layers (with a specified DPI), then turning the entire thing into a smart object, and resizing the document and occasionally changing its format to grayscale. Something that I miss with the resizing step is the ability to specify the resizing algorithm, so if we could have the same control Affinity Photo currently gives you in the GUI (Lanczos etc) that would be great 2. We have written tools based on publicly available scripts (such as https://swirt.github.io/typertools/) which improve productivity for our freelancers greatly. I can't emphasize enough how much work this tool saves people when lettering comics. It's probably the single most important reason they can't switch to Affinity Photo, because all of #1 still technically would work since Affinity Photo can read PSDs (even with smart objects!). We need the ability to build complex GUIs that are built-in to the program (or at least as a pop-up window that does not prevent focus on the document). I don't like saying this, but I think Adobe's choice of going with a "webview" was the correct idea, because there's no GUI toolkit as extensible, hackable, and for which you can find devs that's better than chromium. I think exposing your own widget toolkit would be better for puritans and for the experience, but I'm not sure how you're going to possibly implement every possible widget someone needs, meaning they'll be constrained and therefore irritated when they don't have e.g. a special color picker, custom vertical fader, or whatever else their GUI requires. As a side-note, we are currently working on developing another script/GUI in photoshop to allow for direct uploads/downloads of the documents to our project management system. Some kind of `fetch`-like API access would be nice. I know the difficulties and dangers involved with letting a script communicate with the outside world, but I don't think you're going to be able to compete with Adobe without an equivalent to their "Socket" API. I hope this helps you a bit, and I eagerly await scripting abilities.

(Moments later) Ahhh, HAH. Seems AFpub took all the items in the old .indd document layer called "content" and made them a Group named "content" in which all the subitems — text frames, graphics — were locked, even though the Layer list palette showed all layers as unlocked. I had to look really hard to spot the little right-pointing caret which I click on to pop down the subparts in the Group. Besides that momentary hitch — a really sweet, clean job of converting several simple and multi-page CS6 .indd documents with no issues.

Yes, of course—here is an IDML file containing 3 pages (along with a ZIP file containing the original packaged .IDML/.INDD file with links, etc., just in case you need those for testing purposes). —Kent2023-04-30 Easter 4A test file Folder.zip2023-04-30 Easter 4A test file.idml

The menu command seems to select normally, but appears to have no effect. Strangely, a fresh .afpub file created for a test behaved OK. I observed this in an imported .pdf exported from Adobe InDesign CS6. Everything seemed to import OK, but when I turned off the margin guides, I couldn't get them to come back on again. The menu would show as selected, but I never could get them to show again. I think I was still able to toggle the text frames/flow outlines. The document I imported was at least 8 years old; maybe that might have had something to do with it...? A 7 or 8 year-old InDesign CS6 print-ready PDF export? (turns out AFpublisher won't open my old .indd files, and needs them saved out in some exotic format I've never heard of. Was hoping to not have to drag the old Intel MacBook Pro out and fire up CS6)

The .indd files have a proprietary format that Publisher can't understand. You'll need to convert them to IDML format.

Finally trying out Publisher. Nice to see it'll import pdf's as layout files, not nice to see it can't import my Creative Suite 6 .indd InDesign files. Even less nice to see that most of the Show/Hide toggles in the view window... well, just don't work. They just don't. I was able to turn off margins, bleed, guides, text flow — but when going to toggle them back on? "ZFG", says Publisher. Ouch.