Edit and "cleanup" CPM.js at HTMl export

[Document_captivate]

Is there a way, or a Guideline on how to "clean" the CPM.js file?

If I understand correctly, when you export a project as an HTML5 file the  CPM.js  always the same. So even if TOC is deactivated, if you don't have a playbar and no audio. All code needed for these features is still there!

Is there a "slim" version of the file or a guideline to help me clean this up?

CP

[Russ_E]

Hi,

The CPM.js file is recreated every time you publish and may be very different depending on changes you have made in your course.

I would advise against making any broad changes to it or replacing it with a custom version.

Hope that helps,

Russ

[Document_captivate]

Thank you very much. The only problem i have is that the file features a lot of things that are deactivated in the project ( for example audio). Is there a way to tell Captivate not to feature these elements in the published file?

[Russ_E]

Do you mean exclude functions that aren't used in your project?

If so, I don't know of any easy way to do that.

Maybe you could submit it as a feature request, but who knows if they will ever get to it.

Sorry.

[windscorpion]

Its typical machine generated code, you could edit it but it wouldn't be an easy task, plus as already mentioned you would have to do it every time you published (though you could have a script to do it for you). I know its a fairly hefty file but is it worth the effort?

[kevinc13836104]

I know this is old but I wanted to revisit with a concrete example. I've been thinking a lot about optimizing size & performance in my current HTML5 project and decided to edit CPM.js as one small part of this effort. I stripped out all MediaPlayer and Dash code at the end of CPM.js, resulting in a file that's 4,292 lines of code instead of 15,691. This shaved something like 600 KB off the file—which may sound tiny, but it's a large project that needs every bit of optimization I can do. 

[petern33480613]

Kevin,

Well done!

I too have always thought that so much of the published project is a waste, such as the java code and the icon files for the things I don't use. (I never use Playbar, Skins, TOC and Gestures, but they all have assets in the published project).

I know these are only small items, but they all add to the size and the complexity of projects.

I have over 100 projects on a server and all of them have icons and images in the assets/htmlimages folder (approx 50 items using 700Kb) for features that I have switched off.

Even if I wanted these items, it would be great if I Adobe could have given an option for a 'global' folder to hold these assets in one place and all 100 projects look to that folder.

Good luck with your work to slim down the files, keep us informed of any other progress.

Peter

[mfensel]

I'm still on Captivate 9 (9.0.2.437 to be precise). Have there been any improvements in the file structure of the HTML5 output in newer versions of Captivate? Or an option to publish a global asset folder as Peter suggested a year ago?

The SharePoint server where I currently upload my courses has a limit of uploading 100 files at a time. I want to convert all my SWF courses to HTML5 but it's very annoying to upload each Captivate module in batches.

[RodWard]

I haven't noticed any great changes to the structure in Cp 2019.  No option for global assets folder. While that's a nice idea if you build and code your own elearning courses from the ground up in Dreamweaver, it would be very difficult to implement flawlessly in tools like Captivate that are typically used by people that have limited IT skills. Considering the kind of day-to-day problems we already see posted here, I dread to think what kind of messy problems we'd end up having to debug on the forums if that was an option.

SharePoint has never been the favoured server for Captivate content when it was SWF and I don't see any indications that it's better when you move to HTML5.

[mfensel]

Thanks for the quick response on an old thread Rod!

That's a good point about how a global asset folder might be difficult for people with limited IT skills to use. I code my own eLearning courses in Dreamweaver and use Captivate for software simulations embedded in those HTML pages so I'm probably not a typical user.

Yes I would much rather be uploading my courses to a regular LMS than SharePoint but, despite years of advocating for a different solution, I'm still stuck with SharePoint. And unfortunately SharePoint (at least the older version I'm using) is worse for HTML5 Captivate output than it is for SWF output.