[Tex2002ans]

Originally Posted by fbrzvnrnd

To be honest it is possibile to have a cleaner xhtml+css exit from inDesign linking semantic inDesign sheetstyle with a specifics tags and classes. But usually people using inDesign have not the "tagging" culture to do it.

Yep. Just like using Styles in Word, you can use Styles in InDesign to make (relatively) cleaner HTML+CSS... and just like with Word... many users do not use Styles consistently (or at all).

To many of these people, as long as the surface looks fine, that is "all that matters".

Originally Posted by Turtle91

I'm not a user, but from what I understand, InDesign is an interface that doesn't show the coding to the author, it only shows the result - sorta like Word. The author's don't care what kind of freakin mess it creates in the code, they only think "wow, it looks ok and it was sooo easy".

Just like in Word, you might also copy/paste text from someplace else and it introduces all this hidden bloat.

And crap code can easily slip in and the GUI doesn't make it easy to spot. For example, italic spaces, bold punctuation, or text/punctuation/spaces that are .95 em instead of 1 em.

The only way to really spot these types of errors is looking very closely at the resulting HTML.

Side Note: One of the latest InDesign conversions I worked on accidentally had an entire chapter using oblique text (leaning left) instead of italic (leaning right). No idea how that slipped through... probably a copy/paste from somewhere.

Side Note #2: Also, you might have very hard to spot/overlapping CSS. Like here is three CSS rules from one of the InDesign conversions I worked on:

.charoverride21 {
    font-size: 0.625em;
    vertical-align: super
    }

.charoverride22 {
    font-size: 0.75em;
    vertical-align: super
    }

.charoverride28 {
    font-size: 0.75em;
    font-style: normal;
    font-weight: normal;
    vertical-align: super
    }

Two of the chapters accidentally had superscripts at .625em instead of .75em. This difference is pretty hard to tell with the human eye if you were just scrolling through InDesign or even reading the Print version.

And only a single footnote in the entire book had charoverride28. Maybe the typographer accidentally highlighted it when trying to remove formatting on text close to it. In 99.9% of the cases, charoverride22 + charoverride28 would get you the same outcome (on the SURFACE it looks ok, and in Print, who cares?). The only possible way you would really spot that difference though is to look at the nitty gritty (or let us say you did something crazy like change the main font to italic).

Originally Posted by JSWolf

Part of the problem is that they use ID to layout the print version and then export it to ePub. They need to deal with eBooks as a separate item and not like they do the print version.

That is something too. Print =/= Ebooks.

Very narrow tweaks that work in Ebooks do not make sense for Print, and tweaks that work in Print do not make sense in Ebooks.

In Print, there are lots of manual tweaks that a Typographer adjusts to make the book look/flow better:

• Tweaking spacing to pull a line or two forward
• Adding manual end-of-line hyphens in key locations
• Adding a space after an end-of-line em dash to make the paragraph look better
• Manually fixing widows/orphans
• Shifting text so a footnote moves a page forward/backward
• Manually positioning tables/graphs/charts
• Manually tweaking kerning/spacing issues
• Adding non-breaking spaces at key locations to keep certain text together
• Fixing rivers of whitespace
• [...]

Also, there are typically mistakes/fixes/tweaks being done right up until the book is being printed. And depending on the workflows, once that InDesign <-> EPUB split occurs, every fix afterwards doubles the workflow:

• Found a typo in InDesign? Well now it has to be fixed in the EPUB too.
• Found a typo in the EPUB? Well now we have to go back and fix InDesign too.

All of a sudden, each little fix requires double the total manpower. (And this stuff adds up!) And the more complicated the book, the worse this Print<->Ebook divide becomes (Footnotes, Cross-References, Indexes, Poetry, Side Bars, [...]).

For many Typographers/companies, it is just easier to have a singular workflow in a tool they already know (InDesign). You can have the InDesign file as the "master file", and generate the EPUB as close to release as possible (minimizing the manpower spent on those corrections).

Also, I suspect there are a heck of a lot more Typographers out there that know InDesign, than people who have the skillset in both Typography + HTML/CSS (and all the related quirks/knowhow).

Originally Posted by Turtle91

Not sure how many times I've had to clean up all the bloat from ID.... bloat that slows down the rendering (makes page turns slower) as the app/device has to figure out what the heck all those codes are for a single empty space...

And then you get things that are totally InDesign's fault... like their DREADFUL Fixed Format EPUB code that wraps a span and HARD CODES THE POSITIONING of every... single... word... in pixels.

Or focusing on generating lots of hideous CSS that works in iBooks (BLEH!).

Or generating about a bajillion charoverride## classes. (Yes yes, I know, Garbage In Garbage Out).