If I triger the first MSO to start only after 10 seconds, it should then start at the 10th second of the page but no, it seems everything is in the cue and waits its turn. Each MSO needs to pass in a time tunnel and there is no place for overlapping timing so two or three MSOs can not drive at the same time in the same tunnel side by side.

My whole project is collapsing here.

A colleague told me 30 minutes ago than everything he made with the previous tools is just scrambled in the latest version of the Viewer. But we need interactivity in MSOs to make this project work otherwise the client will kick our tail.

It is getting worse. A client sent me an email: he has also noticed that it is not possible to have more than two MSOs and each one stays on state 1. That's what he says and I can believe him, he's also an Adobe Instructor.

Adobe, this is really a shame what we are living here...

I close everything, fed up, and will show v1 to the client without interactivity in MSOs.

Unfortunately, some of the changes that enabled embedded overlays caused the timing issues which you've discovered here. The bug has been logged, but it won't be fixed before the v19 release. Sorry about not catching this one.

Back from the meeting with the client: he's upset because he can't see what we have promised to him.

He asked: "Is this at beta stage this DPS thing?"

I said: "No, Adobe screwed the whole thing with the latest update."

Client: "Use the previous version"

I said: "No interactivity in MSOs. It's like suddenly the new version of Photoshop can't do what previous versions were able to do it but it is hard to use these old versions because we need the features in the new version".

Client: "Can we export the Folio as a standalone app and tweak them to make them work"

I said: "No, a folio does not use open-source that we can access in its binary and we are not expert in programming. It's not like HTML and JavaScript. Also you don't have the budget. Adobe creates tools only for very rich companies, the ones who can spend at least € 5,000 a year for only 5,000 complimentary downloads and with no guarantee for us, the agency, that we will have enough projects to cover the cost of the DPS contract."

Client: "Well, or you find another way to do it, or I choose another service supplier"

I said: "There are three possibilites: 1. we wait that Adobe fixes the problem but it will be too late for your project. 2. We make an iPad only version of your interactive publication and we use iBooks Author. This is free, easy and even spectacular. 3. We make hardcoded iOS (and Android) apps. But this is far more expensive."

Client: "The presentation must run on iOS and Android"

I said: "Let us think about it"

Thank you Adobe! It seems nobody in your team has real life files for testing apps before releasing them.

Anyway I'm looking into what the problem is before I call it Adobe's fault.

As a general rule from experience, never promise a client something you haven't tested or seen to be working yourself, then you'll never be in this situation. Adobe employs humans, not all seeing robots. There are bound to be errors here and there. It happens everywhere.

I haven't updated the tools yet but I was sorely tempted as they would have enabled us to do things that we have previously had to compromise on. I am now glad I left it to you guys to feel the pain, sorry but that's the way it is. Adobe's policy of "continuous development" is a sham, in reality we are all still beta testers. As I have suggested many times in the past Adobe should continue to beta test each new version of the tools before releasing them. What Adobe are doing is using us the paying customers as guinea pigs and that is thoroughly unprofessional (please note John Metzger).

This continues to be the worst experience I have had with an Adobe product despite the fact that it is probably the one I have been most enthusiastic about. When it works it is great but so often it doesn’t. Adobe’s reputation is taking a hammering with ADPS, if there was a viable alternative I would ditch it without hesitation. And watch out because Apple (or someone else) may well come up with a publishing solution that cuts the rug from beneath Adobe’s feet.

The sad thing is that nearly all of us are fans of Adobe’s products. You should listen to these (and other critical) comments Adobe and change the way you develop this product. It has to work 100% before you release it to us, your customers.

Will Adobe pay me my lost day yesterday from 4:00 PM to midnight when I have created at least one hundred MSOs, cursing, looking at the coming deadline, and making an unifinished project at 4:00 AM in the morning? I slept 3 hours.

Yes you can check with my account that I have uploaded dozens and dozens tests in the Folio Producer.

In my testing, I noticed erratic behavior if I create multiple MSOs on a page and use the same state names in each MSO. If I change the state names (such as "State 1" to "Red"), the MSOs work as planned. I don't believe this addresses the timing issues, but it may affect some of the other issues reported in this thread.

Unfortunately, some of the changes that enabled embedded overlays caused the timing issues which you've discovered here. The bug has been logged, but it won't be fixed before the v19 release. Sorry about not catching this one.

We need some clarity Bob.

The announcement of v18 has disappeared. Does that mean it has been withdrawn?

Are you recommending waiting until v19 is released before for we update tools and if so my view is that this should not be until the iPad Content Viewer has been approved by Apple as this has caused a major problem for many users (who admittedly didn’t read the announcement before rushing off and installing the new tools)?

The v18 tools are still available. That announcement just expired. To get embedded overlays to work, the program team rebuilt the overlays for slideshows and buttons. We expected to see bugs and limitations around nested overlays, but the team wanted to avoid introducing errors in existing areas. Unfortunately, a new slideshow bug prevents an autoplaying slideshow from stopping at the last image. It goes back to the first image on the iPad, This bug ruins fade-ins and other effects that rely on stopping on the last image. Other than using HTML, I'm not aware of a workaround.

While we can post hot fixes for the web client and Folio Builder panel, we can't easily post a new set of Folio Producer tools. This bug and others should be fixed in v19 (February), but that's several weeks away. If your design relies on stopping slideshows on the last image and you can't find a workaround, you should roll back to the v17 tools.

Sorry Bob but that is simply disingenuous. You should post a new announcement explaining the problem with v18 rather than quietly withdrawing the original post. People will go own downloading the new tools without realizing that they have bugs and that there is no iPad Content Viewer. That is irresponsible!

Perhaps an announcement or sticky about the MSO bug might be a good idea.

I think I'll stick to v18 anyway, considered rolling back to v17 but I'd lose PDF Pinch & Zoom ( which incidentally reduced my folio size by almost half ). The text crispness is also of course far better than the bitmap alternative!

It may appear to be a tools problem, but it's a viewer problem. The MSO code in the v18 Folio Producer tools changed. The new AIR viewers handle it properly while the iPad viewer does not. The new viewers handle the previous MSO code just fine, as you've seen.

Oke, I see. The new builder displays 'old code' but can not display 'new' code, but Desktop Preview is oke. Well, that will go down well coming monday during my training session for a big company here in the Netherlands...