how can I export from affinity publisher to indesign

[Old Bruce]

Just now, R C-R said:

Even if there was, the problem remains of how to deal with Adobe-only features when opening an IDML file in Affinity.

But also there would be Affinity only features going to Adobe. Adobe won't change the IDML format to include those.

[R C-R]

15 minutes ago, Old Bruce said:

But also there would be Affinity only features going to Adobe. Adobe won't change the IDML format to include those.

I think it is safe to assume Adobe has no interest in changing the IDML format to make it easier to use it as an interchange format with any of its competitors' apps!

[walt.farrell]

4 minutes ago, R C-R said:

I think it is safe to assume Adobe has no interest in changing the IDML format to make it easier to use it as an interchange format with any of its competitors' apps!

I agree.

However, apparently old versions of InDesign can deal with IDML created by newer versions, by ignoring things they don't understand. The same could apply to Affinity-specific content in an IDML file.

[R C-R]

2 minutes ago, walt.farrell said:

However, apparently old versions of InDesign can deal with IDML created by newer versions, by ignoring things they don't understand. The same could apply to Affinity-specific content in an IDML file.

That doesn't make it any less problematic to use IDML as a two-way file interchange format between InDesign & non-Adobe apps. For example, after a few trips back & forth between ID & APub a lot of content could be lost because one or the other app totally ignores it when exporting the document to the IDML format.

[MikeW]

Geez...Double Geez...

There are people in this thread writing out of absolute ignorance. Full of hypotheticals. Others for whom it is apparent they don't deal with needing to provide deliverables in a "common" format, etc., etc.

For myself, I'll use the application the client wants deliverables in...with some exceptions. If there is/was no agreed upon layout application specified, I'll generally use QXP. However, there have been times when the project has been finished (or is close to being finished) where the client requests an .idml. I do not care if lines break differently. I care the content is intact. In such a case, I'll use a conversion to .idml, load the .idml into ID and review to make sure the content is simply present. This is true whether it is a "simple brochure or, as is often the case, a book.

Do I "collaborate" as in multiple back and forth work using disparate applications? Never. That is also true of ID to ID--I use the same version as they use.

The translation aspect. I haven't needed to interface much with translators. But I do know that Trados et al that translators use simply work as has been mentioned in this thread. They need native or .idml. If Serif ever wishes to allow translators to work with their tools, .idml is a must.

[Old Bruce]

1 minute ago, R C-R said:

... after a few trips back & forth between ID & APub a lot of content could be lost because one or the other app totally ignores it when exporting the document to the IDML format.

It is not just the loss of content that concerns me, but what happens to things like Character and Paragraph styles? My fear is that they will be messed up real bad.

[R C-R]

12 minutes ago, MikeW said:

If Serif ever wishes to allow translators to work with their tools, .idml is a must.

How long would it take Serif do that? There seems to be a great many things in the idml format specifications that have no equivalent in the Affinity apps, including major features like scripting & RTL language support.

[R C-R]

5 minutes ago, LondonSquirrel said:

I agree up to a point, Walt. But unless you have access to their parser and see how it handles the Affinity-specific attributes/elements/whatever, you won't know for sure what will happen.

As I understand it, Walt suggested that what could happen is the parser would just ignore the Affinity-specific stuff. IOW, none of it would be used outside of the Affinity apps, so it would not even appear in any app using that parser to read the IDML file.

Am I wrong about that?

[MikeW]

6 minutes ago, R C-R said:

How long would it take Serif do that? There seems to be a great many things in the idml format specifications that have no equivalent in the Affinity apps, including major features like scripting & RTL language support.

Who knows and who cares? If they, Serif, doesn't get started it'll never be done. Which is true of any/every other feature Serif hasn't brought forth.

There are limitations in every applications I use. Therefore, there are applications I have to use for certain work and others I cannot. RTL is a good example. The few RTL documents I've been involved with in the past, I couldn't use QXP. I couldn't use Xara Designer (my favorite vector design application) nor Photoline if text was involved. I needed to use ID, AI and PS.

The same applies to Serif software. There are things they cannot be used for, or used in a time-saving manner. So don't opt to use them for RTL work.

(Scripting has zero to do with .idml in the main.)

[MikeW]

4 minutes ago, R C-R said:

As I understand it, Walt suggested that what could happen is the parser would just ignore the Affinity-specific stuff. IOW, none of it would be used outside of the Affinity apps, so it would not even appear in any app using that parser to read the IDML file.

Am I wrong about that?

Yes, you are wrong about that. 

Let's say ID, VivaDesigner or QXP did not have the capability to use highlighted text (i.e. text background decoration in APub). The text would get exported, even the tags for highlighting surrounding such text, and the receiving application just ignores the specific highlighting tags, But the text comes through.

And the other way around. APub doesn't have Optical letter justification. So when it opens an .idml from ID, the letter justification type is changed to use the font's metrics. This causes text to generally take up more space for a given line/paragraph. But the text comes through just fine.

[R C-R]

Just now, MikeW said:

Who knows and who cares?

It seems obvious that a great many people care about a huge number of features missing from the Affinity apps.

5 minutes ago, MikeW said:

(Scripting has zero to do with .idml in the main.)

From a quick glance at Adobe's specs, it appears that there are around a dozen or so script-related properties that may appear in an IDML file.

[MikeW]

2 minutes ago, R C-R said:

It seems obvious that a great many people care about a huge number of features missing from the Affinity apps.

From a quick glance at Adobe's specs, it appears that there are around a dozen or so script-related properties that may appear in an IDML file.

Yes, yes. People care that features are added to achieve some degree of parity. And Serif is adding them. Just not as quickly as they would like. 

I have not read the spec lately. But if I recall, script in that context means language. 

[R C-R]

2 minutes ago, MikeW said:

The text would get exported, even the tags for highlighting surrounding such text, and the receiving application just ignores the specific highlighting tags, But the text comes through.

So is there only one way text can be highlighted that all apps understand & implement in the same way?

[MikeW]

Just now, R C-R said:

So is there only one way text can be highlighted that all apps understand & implement in the same way?

No. There isn't some sense of a single way. But it is a paragraph property. It's up to the receiving application to map properties to their own method. If the receiving application cannot use such a property, the property is ignored. 

[R C-R]

10 minutes ago, LondonSquirrel said:

The fact remains that idml is designed and intended for use within InDesign and not for exchange outside InDesign.

Which I think makes support for it as an interchange format with Affinity in particular a non-starter for Serif, if not for a group of users who want to use it as such.

[R C-R]

9 minutes ago, MikeW said:

No. There isn't some sense of a single way. But it is a paragraph property. It's up to the receiving application to map properties to their own method. If the receiving application cannot use such a property, the property is ignored. 

I think in many apps text highlight can be a character, word, or text run property, so not just a paragraph one, but more to the point unless there is a specific tag that all the apps understand how to map to their own method(s), don't we still run into problems if the receiving app just ignores that tag & an edit to the text creates a different kind of highlight for some or all of that text?

[MikeW]

Yet more ignorance being spouted.

PSD is not intended as a format for non-PS applications, either. Should Serif not have import/export support for .psd files? The fact is, Serif doesn't support even keeping text live in a .psd export, yet I don't see any of the naysayers in this thread spouting their particular brands of ignorance in various .psd issue threads.

Y'all that are naysayers or ignorant of working in various real-world situations simply do not need to make use of .idml import, or perhaps one day, export. Y'all don't need to make use of .psd files in non-Adobe applications. Or .eps/AI files in non-Adobe applications either. Or, .pdf files being brought into any application capable of opening PDFs...

[MikeW]

1 minute ago, R C-R said:

I think in many apps text highlight can be a character, word, or text run property, so not just a paragraph one, but more to the point unless there is a specific tag that all the apps understand how to map to their own method(s), don't we still run into problems if the receiving app just ignores that tag & an edit to the text creates a different kind of highlight for some or all of that text?

Yes, it can also be a character style. Thanks for bringing it up.

Receiving application programmers need to know how the .idml maps that property. Then they need to map/convert that to how they've programmed their application. To export, that understanding is simply reversed.

[R C-R]

2 minutes ago, MikeW said:

Yet more ignorance being spouted.

I think you are confusing ignorance with wishful thinking.

[R C-R]

1 minute ago, MikeW said:

Receiving application programmers need to know how the .idml maps that property. Then they need to map/convert that to how they've programmed their application. To export, that understanding is simply reversed.

So basically, are you saying that each of the apps must understand how to map/convert every property that can be included in an IDML file into something the receiving one can use; that it can't just ignore any of them?

That does not seem possible, short of a 'universal' set of tags that all apps could agree to use.

[MikeW]

3 minutes ago, LondonSquirrel said:

You raise an important point, but with PSD specifically you are also wrong. From the Adobe PSD specification: 'This document is provided for 3rd parties to read and write the Photoshop native file format.' Adobe intends that third parties use PSD.

Compare the above with the language used in the idml specification: 'IDML is intended for consumption by InDesign-family applications, including InDesign, InCopy, and InDesign Server. IDML is not intended as an interchange format for use with applications outside the InDesign family of products, and does not attempt to write or structure InDesign content in a manner that is compatible with other XML layout formats...'

There is a clear distinction here.

Yes..but if Adobe really cared about other applications being able to fully utilize the .psd format, they would have documented how to get live text out of application X and into Photoshop. Their PSD "specification" document amount to hints that are not fully documented.

In that IDML snippet you quoted, do note the end of the last sentence. In the main, the intent is intended to just Adobe ID. But it is well documented and able to be used in several applications to their abilities.

[MikeW]

2 minutes ago, R C-R said:

So basically, are you saying that each of the apps must understand how to map/convert every property that can be included in an IDML file into something the receiving one can use; that it can't just ignore any of them?

That does not seem possible, short of a 'universal' set of tags that all apps could agree to use.

YES...the receiving application ignores what it has no abilities to map. Like in the example I gave somewhere above.

[R C-R]

1 minute ago, MikeW said:

In the main, the intent is intended to just Adobe ID. But it is well documented and able to be used in several applications to their abilities.

But unless they all have the same abilities using IDML as an interchange format will remain problematic. It is much like PSD -- for obvious reasons Adobe isn't going to make it easy for any of its competitor's to be used as a perfect replacement for any of its own products.

[MikeW]

10 minutes ago, R C-R said:

So basically, are you saying that each of the apps must understand how to map/convert every property that can be included in an IDML file into something the receiving one can use; that it can't just ignore any of them?

That does not seem possible, short of a 'universal' set of tags that all apps could agree to use.

Here's an example.

InDesign can span columns. APub cannot.

Here's ID:

The top line of text is spanning all 3 columns.

Here's what happens in APub if I open that exported .imdl:

The text, along with all the text properties sans the paragraph style's span property came in just fine.

[R C-R]

2 minutes ago, MikeW said:

The text, along with all the text properties sans the paragraph style's span property came in just fine.

My question is how could APub export that document to the IDML format & preserve that property?