How to retain layer information while exporting to FXL HTML

[scan35126957fna6]

Hi

I'm writing a script that uses the FXL HTML export.
I have this educational book (made in indesign)
I want to make an HTML version of this.

In the books are gaps where students need to fill in texts and drawings
For the teacher we have a version of the book, with the solutions ready made
In a special layer with the "solutions" those missing texts en boxes are present.
When we set the layer visible, we can make a pdf for the book from the teacher 

What I want to achieve, is to export the HTML pages (FXL) and be able to grab the HTML that was in the "solutions" layer, so I can automate the process of hiding and showing solutions.

The only thing remaining in the html (exept for inline styles) are classes originating from character- paragraph- and alinea styles. I've tried to use those for my purpose, but since only one style can be applied to a pageItem, I'm afraid I will mess up the original indesign.

Are there any other kind of annotations that I can script into the HTML export exept from styles?

[James Gifford—NitroPress]

HTML is one thing, FXL is a subformat of EPUB. Yes, EPUB uses XHTML/CSS, but they're very different in nearly every other way.

All HTML and EPUB exports are subject to the limitations of HTML, which are many, and no, things like layers and other composition assets can't be included. The only format that will truly preserve your pages as you see them in InDesign — and can include some interactive features and even preserve layers, under the right conditions, is PDF.

It is just barely possible that JavaScript could be used to create interactive elements that would allow this show/hide feature in an EPUB export, but in the end, so much would depend on the EPUB reader used that I wouldn't even want to attempt it except for the narrowest use, such as one class or school where use of a specific reader could be enforced. (EPUB readers vary widely, if not wildly, and it is nearly impossible to create a book of any complexity that will read the same on any few, much less most, and never all of them.)

And, I'll noted that fixed-page EPUB, FXL, is a problematic and difficult format that should be avoided for all but "picture page" books. It's difficult to work with and a very poor choice for books that are wholly or largely text. Reflowable EPUB is the right path for those.

Happy to help further but I don't think anything but advanced PDF export is going to get you the result you're looking for.

Although it's possible an actual HTML page, designed for reading in a browser, could be finished or touched up with post-export editing to achieve show/hide features (perhaps in popup boxes). That would require moderately advanced InDesign layout and export skills, CSS styling control of the export, and then fairly advanced web development skills to achieve. The limitation there is that HTML is nearly impossible to rights-protect and any slightly savvy user could just look at the code for the answers. But it's the only workable path I can see, without further refinement of your project.

Here's an introduction to InDesign export to EPUB that might be useful.

[scan35126957fna6]

Hi James

Thank you for your answer.
I think I've read all the documentation available by now.

My intention is not to export for ePub readers.
I just want to use the seperate FXL HTML pages from the ePub (when i unzip them).
Then I want to use those pages in my learning platform.

The books are for children and contain very much the picture pages you mean.
It is important that the layout is fixed so the pages have the same appearance as their physical books.

My solution is perfectly possible, i've tested it with a bit of manual tweaks.
The manual tweaks are the problem: we have thousands of pages to go and I want it to be automated and robust.

When I export the ID page to FXLHTML via a script it's nearly perfect.
An item in a layer from indesign corresponds to a DIV-container in HTML

The only thing that's missing is from which layer the DIV-containers originate
Anyone who has an idea there would be a tremendous help

[BobLevine · Accepted solution]

Have you considered in5? Sounds like it would be well worth the investment for you.

[Pickory]

Hi, have you looked at Object->Insert HTML or Object->Object Export Options... EPUB and HTML tab?

[Robert at ID-Tasker]

@scan35126957fna6 

I'm not sure I understand your problem...

If you know the order of your objects in the exported HTML - you could "destroy" your original INDD during HTML export and bring all relevant objects to the same Layer - then run your script(s).

Just because something is on a differrent Layer - isn't a big deal - if you are in full control of your exporting tool.

[James Gifford—NitroPress · Accepted solution]

Okay. It sounds as if you have a good technical handle on what you're attempting. The very short answer is that you're (back) into a realm where things like web pages and EPUB books are 'built by hand,' with each component file created to purpose and then assembled. While ID might be a tool to generate the page content, pretty much everything else is going to have to be done with other tools and techniques to assemble a result that serves your needs.

If the end result is "just a web page" that someone — student, child, reader — loads with a browser, Bob's suggestion to look at In5 is a good one. I don't know what its limitations are when getting into this kind of outlying, specialized result, but I know it can do outstanding interactive HTML from InDesign. You may have to adapt some of your workflow to it, but it if works, it could be a one-step tool.

If In5 won't do it (or the nontrivial cost is too high for your working budget), I can't think of any single tool, setting, plugin or process that would get you results. InDesign is not a very flexible creator of HTML and EPUB; while it has a fair number of export settings and points at which CSS and JS can be inserted, there's not really a path from "ID component pieces" (like layers) to "HTML page pieces" — and that's what you seem to need. You may be in the very small group that can still use the tool-like EPUB editors and assemblers, and (barring a trial run with In5) that's the direction I'd look.

I'm curious what your overall vision and purpose is here, though.

[Robert at ID-Tasker]

One of the goals of my tool - reason I've created it - was to let user easily export InDesign's contents to different formats - HTML, XML, etc.

It's very easy to get "right placement order" of the objects in the document - it's part of the core functionality - including anchoring in the text, originally unanchored objects - then, it's just a case of "deciding" what extra information needs to be added to the exported object's info.

All the information about the object is already there - its formatting, location, size, etc.

Unfortunately, I don't have much experience with epub so if anyone can share practical knowledge... creating alternative to In5 wouldn't be a big deal... 

[James Gifford—NitroPress]

I don't have much experience with epub so if anyone can share practical knowledge

Take one apart (with any ZIP archive tool) and see. It's basically one or more XHTML content files with one or more CSS style files (at least one, the most fundamental one) generated by ID at export. If there are images, they're in a folder; if there are embedded fonts, they're again in a folder. But basically it's just an XHTML+CSS web page with a few quirks about how it's structured. (One oddity: ID does not export <padding> even when it's an obvious style/structure element.)

If you don't split the EPUB export in any way, you will have one large XHTML file. Splitting produces as many separate XHTML files as there are splits, so that might be useful to separate pages as elements.

The problem is that ID functions and components don't always export, or export "linearly," or export in any sensible fashion. You'll have to create some sample docs with layers etc. and examine the exported code to see if the hooks are there for anything like what the OP wants to achieve. I've never messed with layers as any kind of active element after export, so... take a compass and pack a lunch. 🙂

All in all, though, it might be more straightforward to export to HTML, using CSS as needed.

[Robert at ID-Tasker]

I was thinking about checking how sample EPUB export would look like - but maybe the better way would be to focus on how "correct" HTML should look like - and then export each INDD element accordingly - PLUS of course add accessibility rules... 

That's where my tool will really shine - for each type of the object in InDesign, user would create Task and inside will "describe" how info about this object should be exported... This way - user would be able to create ANY kind of export... 

So Tasks would be like DTD for XML or CSS for HTML... Describe how things should be exported... 

Same with DataMerge - for each column/field in the record, there would be separate Task - PLUS additional Tasks for first/last column/row for multiline records - what should happen, what extra operations should be performed, when "product" starts/ends ... Another bonus - placeholders can be added/changed dynamically...

[James Gifford—NitroPress]

ID is very responsive to HTML output — I just did a bunch of client work to produce operating manuals that could be called up on the system (Windows-based) console, and HTML was by far the most streamlined and flexible method. It also permitted dual-format publication in PDF/print and HTML, with the optimized CSS.

However, be aware HTML export has a serious bug that appeared with v18 (I think) and has yet to be fixed. It writes the user CSS file to the export first, then links the generated ID one afterwards... meaning the user CSS is either reset or haphazardly implemented. For the project above, I had to have a macro-ed setup that would open the file and swap the two lines on every... single... export. Got very tedious, and that was after several days of Whiskey-Tango-Foxtrot, Over since I had not previously encountered the bug.

Maybe in 19.2 It seems like such a simple fix, but...