Archives for posts with tag: HTML

UPDATE 11.21.12 | Since writing this post, I’ve come to the realization that it’s more accurate to say “markup” instead of “code” in this instance. A programmer I am not!

  1. In the design stage, brainstorm with the team regarding all of the design ideas to try for the ebook. And then assign a hierarchy of importance to the ideas for the sake of productivity on a tight deadline. In this way no ideas get ruled out and, if you start at the top and work your way down, you will always be working on the next most important element of the project. This is especially helpful when I have to learn the code as I go along. Some things come together quickly while some things take a long time to research and get right.
  2. Working with code feels a lot like learning to recognize patterns. Everything that opens must close. Look at it and work with it long enough and it starts to make sense.
  3. Type code slowly and with thought. I’ve spent too much time trying to find unclosed tags. One trick I like is to type “/” in Dreamweaver while editing in the HTML doc to check for unclosed tags. If “/body” pops up, the file is in good shape. If any other tag pops up I go back and try to find the error. This saves time and less rounds of validation (but validation comes in handy for those times I just can’t find that &%@#! unclosed tag).
  4. Try a regex action on one example and be sure it works the way I want it to before applying it to every open HTML file. Enough said there.
  5. It’s going to take me a while to learn the cascading aspect of CSS.
  6. If I feel like I have all the answers on one day, I will inevitably feel like an idiot the next day. Conversely, when I feel like an idiot on one day, I will inevitably feel like I know what I’m doing the next day. Hang in there. That’s what learning feels like. I remember back when Quark felt the same way.
  7. There’s always going to be more to learn and this makes code seem fun and interesting. This makes my brain happy. (Reminder to myself to revisit #6 when this does not make my brain happy.)

Here’s a bit more behind my question I posted on Twitter tonight:

Shoulda mentioned that my export is from CS4. Also, not sure why my outsourced files had div=”chapter” instead of div=”story” as my own InDesign test export did, but the bottom line is that these div’s are adding a blank page in iBooks at the end of each file exported from InDesign. So far I’ve just noticed this on iBooks. It’s one blank page after each HTML file. The same eBook on my Sony eReader and Adobe Digital Editions did not have any blank pages. Here’s those trouble makers:

So far the only solution I have is to go into each HTML file and delete the div’s manually. And so it goes … adding another “to-do” to my ePub “to-do” checklist. I’m coming off a string of iPad-only eBooks but it’s still good to know for books that are destined for multiple accounts including the iPad.

Thanks to all who let me know on Twitter that CS5.5 is indeed still adding div’s to HTML files. My boss, Matt (who refuses to get a Twitter account), asked me to pose the question because we’re compiling a list of why we want to upgrade to CS5.5 to present at the next budget approval time. (Of course, there’s 10 other reasons why, but another reason doesn’t hurt. Oh well.) Also, Matt then told me to post that PDFs are eBooks. (He won’t let that go. But I still like him.)