Adobe InDesign and poor code

[JSWolf]

Why is it that Adobe InDesign makes ePub with some poor code? Is it InDesign or is it the user not knowing how to use InDesign all that well?

[fbrzvnrnd]

Half and half.
Ok, 30% bad user, 70% bad Adobe.

[Turtle91]

yes...

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".

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...

[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.

[JSWolf]

Unless it's a complex layout, I would find it easier to do the CSS by hand. I'd have class names that mean something and code that's clean.

[fbrzvnrnd]

I *only* write CSS by hand. I never use inDesign, but I tech how to use it to others publishing houses that have too many workers linked to inDesign workflow...

[JSWolf]

Originally Posted by fbrzvnrnd

I *only* write CSS by hand. I never use inDesign, but I tech how to use it to others publishing houses that have too many workers linked to inDesign workflow...

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.

[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).

[JSWolf]

Styles like p.x01-FM-Ad-Card-Head show the eBook was made with InDesign.

One thing I notice with a lot of eBooks made with InDesign is that some of the font sizes are just odd and not correct. In the last InDesign ePub I cleaned up, some subtext was made with a size of (roughtly) .77em. That's just too small. There's no need of it.

What works in terms of font sizes doesn't always work in ePub. Also, the headers being 1/4-1/2 down the page is ridiculous for eBooks. What I think needs to be done is once the book is said to be finished, the eBook edition needs to be slip off and fixed up to remove the print book things that do not work in an eBook.

[Turtle91]

Originally Posted by JSWolf

What works in terms of font sizes doesn't always work in ePub.

Yup - agree!

Originally Posted by JSWolf

Also, the headers being 1/4-1/2 down the page is ridiculous for eBooks. What I think needs to be done is once the book is said to be finished, the eBook edition needs to be slip off and fixed up to remove the print book things that do not work in an eBook.

This one - not so much. This is pure styling. We all know YOU don't like it Jon, but some people (authors/editors) do. And you know what, they aren't wasting ANY paper to do it that way...it's just another screen slide whether you like it or not. I certainly wouldn't want to take away their ability to display the beginning of their chapter the way they wish.

[Tex2002ans]

Originally Posted by JSWolf

One thing I notice with a lot of eBooks made with InDesign is that some of the font sizes are just odd and not correct. In the last InDesign ePub I cleaned up, some subtext was made with a size of (roughtly) .77em. That's just too small. There's no need of it.

What works in terms of font sizes doesn't always work in ePub.

I agree it is very annoying, but that is one of the glorious things about ebooks, the little button that lets you raise font size. Imagine having to read a physical book that had tiny font... YUCK!

And I also agree that the default body text should be 1em while the rest (headings/footnotes) is scaled up/down appropriately.

When you get those smaller font-sizes, I am thinking that is just some sort of pt -> em conversion just so that the ratios of the different texts stays the same. Sometimes you see those crazy .66666689em, and that just HAS to be done by some sort of conversion. No human would ever use that kind of nonsense as a font size.

Originally Posted by Turtle91

This one - not so much. This is pure styling. We all know YOU don't like it Jon, but some people (authors/editors) do.

I agree it is a styling choice (there is a lot of reasoning/ratios that goes into whitespace in page design)... And they typically use whitespace to keep the golden amount of characters per line (and make the two-page spread look great).

In the case of paper, some people prefer lots of whitespace over others (from what I have gathered over the years, it seems like European books tend to have a lot more whitespace than American books).

Don't know how much sense many of those arguments make in ebooks though...

Personally, I tend to err on the side of JSWolf. You don't have a set page size, and devices can get small (think cellphone), so it is pretty stupid when a huge chunk of real estate is wasted.

Originally Posted by JSWolf

What I think needs to be done is once the book is said to be finished, the eBook edition needs to be slip off and fixed up to remove the print book things that do not work in an eBook.

I agree... although maybe I am biased. :P

And I definitely agree with you when you promote the idea that "good Print fonts =/= good Ebook fonts". I personally just leave as much as I can up to the user's/device's defaults unless it is integral (need a very specific character/symbol, etc. etc.).

[JSWolf]

The font size problem is not always solved by an increase in font size. The problem (sometimes) is that when a smaller font size is used, it's too small. So when you increase the font size so those sizes are no longer too small, other font sizes can be too large. I do agree to let the base font size be the default and adjust the others from there. But don't go stupid and go too small or too large. I've not seen too many eBooks with too large. But a lot do have too small.

I do sometimes read on my phone and when I see things like a 14% white space for a chapter header and a 10% left/right margin to do a simulated blockquote, I just think stupid designers. The screen sizes used to read with are not the same. They range in many different sizes. My way to look at eBooks is to take the smallest screen you think people might be using and design so the eBooks look good on that and also check if they look good on a larger screen. My idea of the smallest screen would be that of an iPhone 4s.

[Notjohn]

My idea of the smallest screen would be that of an iPhone 4s.

My phone! (And yes, I do read books on it, while traveling or waiting for the movie to start.)

[JSWolf]

Originally Posted by Notjohn

My phone! (And yes, I do read books on it, while traveling or waiting for the movie to start.)

I also read on my iPhone. I used to read on an iPhone 5 & now I read on an iPhone 6s. But still, that wasted space for chapter titles is just ridiculous. It looks bad on my H2O (6.8"screen) and on an iPhone 4s, it's abominable.

[IronChaim]

Originally Posted by fbrzvnrnd

Half and half.
Ok, 30% bad user, 70% bad Adobe.

Yeah - I have to agree with that. I feel that most users are just uninformed, and don't care to get informed, about what makes a nicely constructed book and rely on Adobe to just 'do it for them'. If the export makes something that looks good, and it works in platform X - then they see no reason to actually look at the guts (and probably have no idea even where to start).

Other peeves: Crazy CSS, SPAN all the things, exact pixel placement for FXL, mangling Fonts when it's not needed, other 'default' settings users don't think/know of to change.