[IDML Implemented] How can I open Indesign (indd and idml) Files in Publisher?

[MikeW]

15 minutes ago, Whitedog said:

On an unrelated note, I just noticed, with the latest update, how large Publisher is. Over a terabyte, three times larger than InDesign CS 6. This gives me to wonder about the applications's operating efficiency. Just a thought.

APub here (Windows) occupies 692 megabytes. ID CS6 is half that (but there are some dependencies in other folders to the tune of about 75 megs or so from what I can tell).

QXP 2018 is 1.7 gigs. But it is still faster in operation than CS6 and APub. So I don't think that in this case size matters ;^-). There is also likely debug code in APub that may not be present in the release version.

[v_kyr]

19 minutes ago, Whitedog said:

how large Publisher is. Over a terabyte, three times larger than InDesign CS 6

LOL, well I maybe should now wonder how I managed to install that on a old tiny hdd and perform updates too (?).

[ChrisBorry]

1 hour ago, Whitedog said:

On an unrelated note, I just noticed, with the latest update, how large Publisher is. Over a terabyte, three times larger than InDesign CS 6. This gives me to wonder about the applications's operating efficiency. Just a thought.

I was expecting a “Related” note on my solution. But I expect your HD is full...

[Uwe367]

On my System (Win 10 Home) it´s 688 MB and so ist 300 MB larger than the other Software but that does not matter for me in times in which HDD´s and SSD´s can store several treabytes. There are 688 MB only a drop in the ocean.
In my opinion is that publisher works well and stable and for a beta this software works very well. Maybe it will be smaller if the final release comes out.

But back to topic.
Will IDML Support be added and ... When?

[Oval]

4 hours ago, Uwe367 said:

Will IDML Support be added and ... When?

Ist bereits mehrfach kommuniziert worden. Z. B.:

“We will be able to import InDesign IDML files but not .indd files. The feature is being written but we don't have a timescale yet.”

Bedeutet: nur Import, irgendwann.

Termine werden nicht mehr genannt, weil APu beispielsweise für 2015, 2016, … 2018 angekündigt wurde. Man hofft auf geduldige Kundschaft.

[Uwe367]

Ah ok, Danke für den Hinweis.
Ich wußte daß ich es irgendwo gelesen hatte, aber nicht mehr in welchem Thread. IDML Import wäre ja schon großartig.

Ah ok, thanks for the hint.
I knew I had read it somewhere, but not in what thread anymore. IDML import would be great.

[Whitedog]

9 hours ago, Uwe367 said:

On my System (Win 10 Home) it´s 688 MB and so ist 300 MB larger than the other Software but that does not matter for me in times in which HDD´s and SSD´s can store several treabytes. There are 688 MB only a drop in the ocean.
In my opinion is that publisher works well and stable and for a beta this software works very well. Maybe it will be smaller if the final release comes out.

But back to topic.
Will IDML Support be added and ... When?

I should have mentioned that I'm using macOS 10.12, Sierra. The size of the app doesn't matter in relation to my 1TB Fusion drive. I just wonder about the efficiency of the code in so large an app, which does not yet even have feature parity with InDesign.

[Wosven]

As already said, there's some "Common Files" folder and some other for the CC suite, and you shouldn't compare only with the app's folder file. Size doesn't matter here.

I rememeber being really proud of writing 10 lines of code that could do the same as my previous PHP page of 50 or 100 lines (can't remember exactly)… Those 10 lines with an advanced function were so slow to process that I keep them as example and revert back to my previous code doing the same in less than a second! If I had only compare files's size, I would have kept the slow code, not for efficiency but for aesthetic

[MikeW]

2 minutes ago, Wosven said:

...

I rememeber being really proud of writing 10 lines of code that could do the same as my previous PHP page of 50 or 100 lines (can't remember exactly)… Those 10 lines with an advanced function were so slow to process that I keep them as example and revert back to my previous code doing the same in less than a second! If I had only compare files's size, I would have kept the slow code, not for efficiency but for aesthetic

And on the other hand, I once handed over the code for an insurance company application that effects most people in the western world. About 4 years later, the code returned for me to fix. It was slow and bloated with what amounted to spaghetti code—it wound its way through existing code so much and wasn't commented at all. It took me 3 months to untangle it, rewrite it, remove code, etc. I was particularly happy to have removed over 100,000 lines of actual code and add functionality in the process.

Sometimes size does matter. It just depends on what/where the "size" comes from.

[Whitedog]

5 minutes ago, Wosven said:

As already said, there's some "Common Files" folder and some other for the CC suite, and you shouldn't compare only with the app's folder file. Size doesn't matter here.

I rememeber being really proud of writing 10 lines of code that could do the same as my previous PHP page of 50 or 100 lines (can't remember exactly)… Those 10 lines with an advanced function were so slow to process that I keep them as example and revert back to my previous code doing the same in less than a second! If I had only compare files's size, I would have kept the slow code, not for efficiency but for aesthetic

Good points. I wasn't making an accusation, merely asking a question. Your example is not indicative of all code, by the way, but just one instance—though I imagine others could be found where more code was better code. I also suspect that the slow processing had to do with calls to external code libraries, which take inherently longer to load and process.

[Whitedog]

4 minutes ago, MikeW said:

And on the other hand, I once handed over the code for an insurance company application that effects most people in the western world. About 4 years later, the code returned for me to fix. It was slow and bloated with what amounted to spaghetti code—it wound its way through existing code so much and wasn't commented at all. It took me 3 months to untangle it, rewrite it, remove code, etc. I was particularly happy to have removed over 100,000 lines of actual code and add functionality in the process.

Sometimes size does matter. It just depends on what/where the "size" comes from.

Back in the day (when I had to do my own keypunch from my code sheets), taking the time to comment my code was frowned upon, even though I was taught that commenting was a "best practice." The real world didn't line up well with what I learned in school. Quick and dirty was the accepted meme.

[MikeW]

Just now, Whitedog said:

Back in the day (when I had to do my own keypunch from my code sheets), taking the time to comment my code was frowned upon, even though I was taught that commenting was a "best practice." The real world didn't line up well with what I learned in school. Quick and dirty was the accepted meme.

The comments never made it into the compiled code. I would have fired anyone working for me that didn't properly comment code (and did once). It is hard to follow someone's code if there is ever a need to without commenting.

[Wosven]

13 minutes ago, MikeW said:

Sometimes size does matter. It just depends on what/where the "size" comes from.

Yes, updating and improving code is important. That's what I was doing, learning new fonctions and new way to do things when it happened. But I expect Affinity teams to know what they are doing, since those new programs are — from what I read — faster, and more efficient than their old ones. Perhaps, once they have completed the 3 main applications, they'll use a "common files" folder too, and the apps' folders will be lighter.

But I wouldn't compare with Adobe apps, since their apps aren't perfect (the current version of PS I use need waiting few seconds before doing anything to an image… even a shortcut, perfect excuse to test AP at work!). On the other side, they have more feature too.

I found more worrisome the files' size. Usually, sending an archive of all the needed files for a project (file, images, fonts), is a big/huge package. What about project made with Affinity suite?

[MikeW]

1 minute ago, Wosven said:

...I found more worrisome the files' size. Usually, sending an archive of all the needed files for a project (file, images, fonts), is a big/huge package. What about project made with Affinity suite?

I don't know if I'll ever use Affinity products at a client's request. Even if so, I don't know at this time if they will want the final files handed over. But if the preceding is requested, and if APub doesn't ever properly link files, it will be an onerous chore to hand those files over.

I don't know whether I will be using APub much for this and other reasons. It presently doesn't fit into my work-flow and I don't know when/if it will.

[Whitedog]

16 hours ago, MikeW said:

The comments never made it into the compiled code. I would have fired anyone working for me that didn't properly comment code (and did once). It is hard to follow someone's code if there is ever a need to without commenting.

Too bad I didn't work for you, or someone like you. I was fired because I took too long to write code—because I included comments. I commented my code so I could follow what I was doing. I was also directed on another job to figure out where the flaw was in a batch of code that was not commented. There was no one in the shop who could tell me what it was even supposed to do so I had to outline it to figure it out. I was too slow there, as well. My boss was an idiot who thought I should somehow know, by osmosis I guess.

[Alfred]

On 2/12/2019 at 11:33 PM, chakko007 said:

PSE 13 is 64-bit though.

Anyway, the “numerous other 32-bit applications” part still stands.

[Alfred]

21 minutes ago, Whitedog said:

I was fired because I took too long to write code—because I included comments. I commented my code so I could follow what I was doing.

It sounds as though you were fired because your boss figured that your successor would be able to produce the next iteration more quickly, thanks to your commented code!

[Oval]

1 hour ago, Alfred said:

successor would be able to produce the next iteration more quickly

and probably the successor works for less (pay) because he is not only not able to comment code

[GWCTas]

For me the pdf export from InDesign and import to Publisher works so far but I'll be looking forward to being able to import the native file.

George

[Moon12]

For me it is quite important, that i can import idml-files as my work of the last 10 years is then unabailable.

When do you think the idml-importer will be ready?

In my case, I would also pay for it extra, as for other modules like a xpress importer despite of some errors on transparency or such explicit indesign or xpress things.

[lenbtw]

Hi folks, I am keen to escape the evil empire and convert to Affinity, I'm loving the ease of use, reasonable pricing and extensibility.... but If I can't migrate from InDesign and convert existing files, it's a show stopper. I really don't want to be forced into a subscription model to maintain compatibility. 

Love your work

[firstdefence]

On 3/2/2019 at 5:37 PM, Moon12 said:

unabailable

"Unavailable" said when you have a cold. 

[Jan Prague]

Hi all, I second that request for at least partial InDesign support too. 

I have paid Adobe CC complete package for couple of years now and I'm getting tired of theirs pricing policy, specially when using only couple of apps of theirs: Photoshop, Illustrator, InDesign, Premiere, Audition, Lightroom and few more occasionally. I have been using these products for last 25 years quite happily. But with CC, everything changed.

Thanks to Affinity and Apple, I have substitutes for almost all of Adobe SW I use on regular basis, but InDesign. I have learned about Affinity Publisher just today, and I jumped in excitement that there might finally be a way out for me  I don't really need full indd support, just to convert my older files and live without Adobe for the rest of my life or until they introduce more flexible pay model.

For those looking for similar switch from Adobe, here is what I'm quite satisfied with.

• Illustrator > Affinity Designer
• Lightroom > Apple Photos, Apple Aperture
• Premiere > Apple iMovie (limited, but good enough for me)
• Audition > Apple GarageBand 
• Dreamweaver > netBeans
• Photoshop > Affinity Photo, Apple Photos, Apple Preview

Edited March 20, 2019 by Jan Prague

[Patrick Connor]

@Jan Prague

Welcome to the Serif Affinity forums  . I hope you enjoy using the Affinity Publisher beta and consider a purchase if you can see it being useful to you at least for new projects planning for a day when your workflow could change completely.

[fde101]

1 hour ago, Jan Prague said:

Apple Aperture

Glad if that is working for you (I used it for a long time too) but for people newly looking for software, Aperture has been discontinued for some time and is no longer an option for people trying to switch.  It is likely to stop working with newer OS versions if it has not already.  Photos is a bit too limited for some of us.

For video work, current versions of Resolve (even the free version) can generally replace Premiere, Audition, and some other things...  and there are other options too for those who need something a bit more powerful than iMovie.