Is IDML export from Publisher going to be supported?

[Tupaia]

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!

[R C-R]

4 hours ago, Tupaia said:

Can we get an official statement if the IDML (InDesign markup language) file format will ever be supported for export from Publisher?

I think you have been a forum member long enough to know that Serif's policy about such things for quite a few years now is that they will not comment on their future plans or timetables because there is no certainty about such things & they do not want to raise false hoped about if or when something might be added.

So the best you probably can hope for is to see if that feature ever makes it into some future beta.

[Tupaia]

Well, worth a try... =}

Doesn't hurt the good people at Serif if we knock on their door again about this feature, wether they answer or not.

(Guess I'm used to roam the Rhino 3D discourse forum, where any member has a direct wire to the developers, and even access to the feature/bugtracking website.)

[RWhite]

The lack of idml export is a definite deal breaker for me and many others in terms of the whole Affinity suite, unfortunately. I purchased the ipad version fairly recently to get a feel for the Affinity suite. And it appears at first sight to be extremely powerful and flexible. However that said, I cannot start thinking about transitioning fully without the ability to move and share layouts into Indesign. You can export to PSD from within Photo and SVG from Designer.  And I understand you can import idml files from indesign files into Publisher. But so far not the other way, so it seems obvious that this feature has been deliberated turned off, which is a shame. I understand that Adobe may not allow idml to be used by its competitors long term, if loads of users jump ship, but if they if they do currently it would be great to see this feature. 

[PaoloT]

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

 

[lacerto]

17 hours ago, PaoloT said:

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.

If you mean that the documentation is "hidden" amongst 81,960 files within the ID Plug-in SDK so that a possible competitor gets exhausted and will give up already when extracting the about 3.5GB package (a task that takes about an hour), then perhaps so. But seriously, being afraid of competition and someone developing interchange support for Adobe created things is not the first thing that comes in mind when visiting developer.adobe.com  and seeing the sheer amount of open and free as per version targeted documentation, SDKs and tools available for anyone interested.

Even with full IDML export support, true co-operation between diverse professionals already happens in the cloud and using common tools. I suppose IDML export is more a kind of a one-off tool for the purpose of providing a client with an editable document they wished to have (and many clients do nowadays, in addition to getting a production file as a PDF). If it is required, why not pick a tool that can already do it, there are multiple available, including ones that are not (necessarily) subscription-based (and not developed by Adobe, if that is important).

[PaoloT]

8 hours ago, lacerto said:

If you mean that the documentation is "hidden" amongst 81,960 files within the ID Plug-in SDK

The PDF containing the specifications has simply disappeared a couple years ago. If you can find a link in the Adobe site where to download it, I'd be happy to know. There is no sign of it, or its replacement, even in the new WebHelp documentation for InDesign's SDK.

8 hours ago, lacerto said:

Even with full IDML export support, true co-operation between diverse professionals already happens in the cloud and using common tools.

You are referring to some use cases I'm totally unaware of. But which type of cooperation? Which common tools? You refer to IDML as a way to giving files to clients. I use it, in the cases I described above, as a way to exchange data with my collaborators. As of now, I don't know of an alternative way of doing it "in the cloud". And I don't know of "common tools"; on the contrary, I can only think to very specialistic, very niche ones.

Paolo

 

 

[lacerto]

14 hours ago, PaoloT said:

You are referring to some use cases I'm totally unaware of. But which type of cooperation?

I referred to collaboration that involves working with the same file using compatible (= common, same) tools. I do not think that exchanging IDML files back and forth between two different apps can be productive as there are several things that do not fully translate. See e.g. notes related to QuarkXP 2024 IDML Export. As a workflow example you mention giving a finished layout for translation. Personally I would not be happy to hand over a finished layout that has any degree of complexity to translators that would first import the document to e.g. Affinity Publisher, edit it there native, and then send it back converted to IDML using proprietary export method (which I'd need to check and most probably spend considerable amount of time making fixes and get back features that were lost in translation). I have done these kinds of tasks a few times when all involved have been using InDesign, even if different versions, and it was ok then.

Today the files involved could also reside on cloud so there is no need to send lots of files back and forth. This is one issue more when working with Affinity or other 3rd party apps.

14 hours ago, PaoloT said:

If you can find a link in the Adobe site where to download it, I'd be happy to know.

The most recent file format specs that I have are version 8 and I think it came with the Master Suite CS6 (2012). I have also an IDML Cookbook that came with CS6. I am not sure if there are any later versions but perhaps not because I have understood that the point is that IDML files can be opened in different versions of InDesign from the most recent one down to CS4. I have not tried to look for newer versions of these files on Adobe developer sites -- the ones I have might still exist there in context of legacy CS5/6 documentation, or perhaps as part of XML documentation. The plugins SDK I referred to has a reference manual for IDML (server based) tools.

I think that if someone is determined to develop IDML export support, they can find the required documentation. One prerequisite for developing such a tool is that multiple versions of InDesign are accessible (for testing alone), so that would at least be a guaranteed source.

I responded because you seemed to imply that Adobe has hidden IDML related documentation to make it more difficult for other software developers to create full-fledged competitive software with equally rich feature set. If so, they are a bit late, since tools supporting IDML in both directions already exist, and they have not been game changers (e,g,, there are 5 comments in about 4 years for Q2ID Markzware introduction on YouTube). Who knows if it is the other way around: making an agreement with developers of existing export plug-ins that availability of IDML documentation is screened to reward efforts of early-birds.

On the other hand, I think that support for IDML export is a double-edged sword: it makes it easy also to come back if it turns out that the competition was less competitive than was hoped. Adobe has also taken big steps in creating new development environments and tools (e.g. UXP) for CC-based apps, and server based plugins, on the other hand, so the focus of development has changed a lot in recent years.

[PaoloT]

1 hour ago, lacerto said:

I referred to collaboration that involves working with the same file using compatible (= common, same) tools. I do not think that exchanging IDML files back and forth between two different apps can be productive as there are several things that do not fully translate.

"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

 

1 hour ago, lacerto said:

Personally I would not be happy to hand over a finished layout that has any degree of complexity to translators that would first import the document to e.g. Affinity Publisher, edit it there native, and then send it back converted to IDML using proprietary export method

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.

 

1 hour ago, lacerto said:

The most recent file format specs that I have are version 8 and I think it came with the Master Suite CS6 (2012). I have also an IDML Cookbook that came with CS6.

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.

 

1 hour ago, lacerto said:

On the other hand, I think that support for IDML export is a double-edged sword: it makes it easy also to come back if it turns out that the competition was less competitive than was hoped.

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.

 

[lacerto]

4 hours ago, PaoloT said:

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.

I do not know what translation tools and specific workflows professional translation services use (certainly ones I have worked with use both translation memory of sort, and native translators), but the initial step I have performed has been delivering an IDML file saved from InDesign, and the final step has been receiving either a translated IDML (for simpler layouts not requiring visual/structural changes), or translated RTF documents initially exported by translators from InDesign (including formatting), to be placed back (still including formatting) in layout by me. So I do not think that they typically translate anything "in place". 

Another scenario where IDML has been requested are situations where a client wants to have a chance to make minor edits like change of name or address in the layout, and in these situations their "editor" has typically been InDesign. I have not seen it necessary to advise them to use (and learn to use) something more cost-effective.

Whenever professional collaboration is needed for a specific project, the tool required has always been CC, which I have then rented for the time needed (typically just for a month or two). This has worked well.

4 hours ago, PaoloT said:

Their dominance is still basically untouched, and they will always get the advantage of the incumbent

IMO their dominance is primarily based on trusted workflows. The cost and longevity of Adobe-based tools for the designer has much been a question on whether one operates primarily on Windows or mac; and if subscribing, whether one app is enough, and whether what is needed can be hired just for short time periods. I started my school with Affinity apps in order to learn a backup suite. They can mostly be used as such once one has learned enough, but as there has not arisen any cause for making a "switch" and abandon trusted workflows, I only use them for isolated tasks in areas where they are at their strongest. I don't much think about companies in my work but I do not feel that I have been supporting villains whilst using software by Adobe or Microsoft. I try to stay practical and co-operative, but also economical.