Does it make sense that loading a very simple, small HTML file (4kb) via Overlay Creator's Web Content would turn an article upload that happens in seconds into a 105mb mini-monster that takes minutes to upload?
Well, a simple html file (one liner with a <video> tag) ended up with a 350 MB file for me. So that's 400 kB without the html oneliner, and 350 MB with. The video was supposed to be retrieved online, but it looks like it is embedded (though it still requires an Internet connexion to work).
Could it be that html inclusion fills the folios with cache?
My file was even simpler - 4 or 5 paragraphs and no linked content. I wondered if it was trying to drag in something from the XHTML namespace, but I have no found where the folio files are being written locally, so I will open one up and investigate.
It looks like the uploaded .folio file for this article didn't just contain the article - it contained all the files and subfolders for the magazine project. This was because the html file I added was actually stored in the project's root folder, under which were subfolders of my original indd files and other original content. Once the html file was moved into its own subfolder, the upload was as small and fast as one would expect.
I don't think this is a "known" (as in "acknowledged") bug. I just
encountered this behaviour in prerelease and just hoped they fixed this in
some of the many versions after that.
I think it is hard to identify all the assets an HTML file needs (because of
some lazy load techniques and indirect refers, such as @import), so they
just pust all the content lying around the HTML file into the folio.
I always put HTML in a separate folder (just to keep myself organized) and
so came around this behaviour.
Now I understand what happens, I'm not too worried about the behaviour and it's easy enough to avoid. Everything else is organized into subfolders but this html file was just dumped in the root folder while I was figuring out ways to keep text content in sync in portrait and landscape layouts. But it is such an easy "mistake" to make. Maybe the palette should point to a folder rather than allow the user to specify a file?
We just ran into exactly this problem. We found about 95Mb of useless-to-the-user InDesign files, tiffs, PSDs, whatevers, buried in the commercial App! But only on pages where the HTML was sat next to the InDesign file.
There are both file size and IP issues here, which we could really do without.
Thanks for the tip about putting the HTML in a separate folder - we'll deploy this for our update.
IP, as in Intellectual Property - copyright protected stuff.
If it sweeps up everything sat next to the HTML file, you could inadvertently distribute a bunch of Jpegs from picture library that happened to be in that folder.
I appreciate they'd be packaged up in the App, so most users would be blissfully unaware, but it only took me 2 mins to discover how to get to them.