ePub vs IDCC (InDesign Creative Cloud)

Home Forums EPUB and eBook ePub vs IDCC (InDesign Creative Cloud)

Tagged: , , , , ,

This topic contains 14 replies, has 6 voices, and was last updated by  Derrick Schultz 9 months ago.

  • Author
    Posts
  • #65784

    incblot
    Member

    I had developed a smooth workflow from converting print books from ID5.5 to ePub (editing code in TextWrangler). Have now upgraded to IDCC and having a few teething problems. It may be useful to share/discuss:

    1. HTML output/terminology changed: eg “toc-marker” now “id=”_idParaDest”, etc.

    This means the find/replaces and GREP formulas I use to clean up the HTML need to be rewritten.

    2. CoverImage.xhtml now generated on export.

    I formerly used the first page of ebooks as the cover by including it in the InDesign document. The only downside I can see to this is the cover is no longer accessible via the TOC.

    3. For images within the book, InDesign generates its own paragraph styles.

    I have my own styles for images, but InDesign generates its own anyway: <img class=”_idGenPageitem-1″

    4. Image height and width percentage (eg height=”99%”) definition has changed. I formerly set cover images to a height of 99%, which would allow the image to fill the page height while staying in proportion.

    The image now squashes/squeezes when the page dimensions change. Not sure how to fix.

    5. CSS export defines a serif font (Georgia) as a sans-serif. Weird.

    6. Page margins are gone. Text now runs right to the sides of the page, to the point it is clipping some of the font.

    I’d like to increase the margins. Not sure how.

    7. When using preexisting CSS in conjunction with an InDesign generated CSS, InDesign sets its css as the default.

    I formerly used only the ID generated stylesheet (cleaned up with TextWrangler). I’m considering ditching the InDesign css altogether now, given first impressions.

    8. Default export ‘meta@dtb:uid’ does not conform to unique-id in content.opf, so ePub does not validate. It’s a known issue to Adobe but no fix yet available (see http://forums.adobe.com/thread/1251167)

    As is probably evident from some of my points here, I’m not an expert in HTML/CSS/GREP but I had a successful workflow which now needs revising. I think it’ll take some time to find all the quirks and alter my approach accordingly. Feel free to throw in your two cents and/or shine a light.

  • #65785

    For number 8, I think the solution/workaround is to not change the UID that InDesign adds. That’s what we’ve been doing in the studio. Including the ISBN in the metadata is not a requirement for a validator, and as far as I know is not a requirement for e-resellers. (they ask for the ISBN separately in their own upload forms.)

    Did you see this post and download the PDF (InDesign CC new epub features) linked to in the post? It may help.

    http://indesignsecrets.com/epub-features-indesign-cc-include-linked-indexes-object-style-support.php

    Love the list, it should spark a great discussion!

    Have you taken advantage of any of the new features in your workflow, like proper font embedding/obfuscation for iPad? Object styles that include epub export options, and that you can map to html/css tags?

    AM

  • #65847

    incblot
    Member

    Thanks for the reply, Anne-Marie! I’d read the adobe list of updates but not that article. Impressive.

    Haven’t yet taken advantage of any new features – just trying to keep up with publication dates for our books/ebooks. Spent my time trying to work around the above list of changes after exporting my first IDCC generated epub.

    I’ve completed my first ebook after the switch, will endeavor to make some notes about it as time allows. For now, I’m reverting to CS5.5 as deadlines loom.

    Re number 8: I’m under the impression some retailers use the UID for the ISBN (as well as the uploaded metadata spreadsheet); as I’ve made an error in the past and not updated the ISBN in the UID, which resulted in one epub replacing another. Perhaps it was a unique case.

  • #66001

    I have tried to answer some of the problems here:

    3. CoverImage.xhtml now generated on export

    CS5.5 only exported to EPUB 2.0 but CS6 onwards, EPUB 3.0 export is supported. CoverImage.xhtml file would be generated in case of EPUB 3.0 export only.

    5. CSS export defines a serif font (Georgia) as a sans-serif. Weird.

    This should not happen but I am not able to reproduce this at my end. In my case, CSS export defines Georgia as serif only. Are you applying this font via style or as an override? Does this happen every time in your case or with a specific file you are working on?

    6. Page margins are gone. Text now runs right to the sides of the page, to the point it is clipping some of the font.

    Page margins can now be specified via EPUB Export Options dialog. In the General tab, there is an option to specify Page margins(in pixels). Earlier in CS5.5 a default margin of 0.5 em was added during export but now it has to be explicitly specified during export.

    8. Default export ‘meta@dtb:uid’ does not conform to unique-id in content.opf, so ePub does not validate. It’s a known issue to Adobe but no fix yet available (see http://forums.adobe.com/thread/1251167)
    Please refer this forum post for a workaround to this problem : http://forums.adobe.com/message/5556215#5556215

    Thanks,
    Pooja

  • #66016

    incblot
    Member

    Pooja, thanks very much for your reply!

    3. The cover issue is fine. I did prefer having control of this but I shall submit to the wisdom of EPUB3.

    5. I tried again and encountered the exact problem. The CSS is: font-family:”Georgia (OTF) Regular”, sans-serif

    I’ve defined Georgia with the paragraph style, no overrides. I suspect this is not a widespread problem then, possibly something to do with my font management program’s relationship to IDCC (Suitcase Fusion 4). I actually delete Georgia from my CSS anyway (I still design without embedded fonts, as I learnt to create ebooks when embedding fonts was riddled with problems – I’m happy to let the readers define the font until I’m confident any design embellishments will not cause problems on any reading platforms [has this day come yet?], but I find this glitch strange/new, so thought worth mentioning)

    6. Thanks for the tip, I’d overlooked that option. I only seem to be able to add pixel for the margin, not ems, but I’m glad I can experiment with that in ID. Does anyone have a recommended pixel with for standard margins?

    8. I find this a really odd problem. Can anyone explain exactly what this means and why it has changed (I cannot see any benefit, but would like to be enlightened if there is one). Also, are there any foreseeable problems not having the ISBN in these fields (which seems the easiest fix to output a valid epub file)?

    Thanks for continuing the conversation. I’m only on my second book via IDCC (after years in CS5.5), so its early days, early days.

    • #66017

      The problem is that if you enter a new Unique ID this will be added to the metadata and used for the TOC.NCX but InDesign will still leave around the original UUID in the metadata.

      This is what content.opf will look like:
      <dc:identifier id=”bookid”>urn:uuid:8B0605B1-0129-4B8D-B3AC-AB4D142F5C0D</dc:identif ier>
      <dc:identifier id=”ISBN”>urn:isbn:978-0-9729563-1-4</dc:identifier>
      toc.ncx will look like:
      <meta name=”dtb:uid” content=”978-0-9839980-3-7″ />
      This causes problem during EPUB validation – the TOC.NCX needs to match the <identifier> which is declared to be “bookid”.

      However, simply removing the “bookid” <identifier> would not be right in case of font embedding. If you embed fonts then the <identifier> with the “bookid” is the one which is used to obfuscate the fonts and if you remove it afterwards (or change the <identifier> with the “bookid” then the reader won’t be able to successfully de-obfuscate the fonts.

      So the workaround for EPUB validation would be to edit toc.ncx file in EPUB and add this line instead of the one entered by InDesign above:
      <meta name=”dtb:uid” content=”urn:uuid:8B0605B1-0129-4B8D-B3AC-AB4D142F5C0D” />

      I hope this explains your query.

      Regards,
      Pooja

  • #66018

    Pooja, that’s immensely helpful information. Thanks so much for posting all the details!

    Are you one of the InDesign engineers? Sure sounds like it!

    AM

    • #66022

      Yes AM, your guess is right. I am from InDesign QE team.

  • #66026

    incblot
    Member

    Thanks Pooja, that fix is indeed very helpful!

    I have a question regarding point 6, if you might assist?

    I am using a preexisting css (template.css) alongside the ID generated css (idGeneratedStyles.css). I’ve set margins to 150px in IDCC during export (nb: using a large margin of 150px to exaggerate its effect for testing). The idGeneratedStyles.css shows:

    @page {
    margin : 150px 150px 150px 150px;
    }

    The template.css shows:

    @page {
    margin : 0.5em;
    }

    Yet the text is not indented. I have tried deleting this from template.css:

    @page {
    margin : 0.5em;
    }

    But it has no effect.

    If I export the epub from IDCC without adding my own template, the 150px margins work in Adobe Digital Editions, but not in Safari or iBooks.

    Could you please explain what is happening?

    • #66027

      Hi,

      I tried your scenario and got the same result. I think iBooks app on iPad uses its own default page margins (0.5 em I suppose) and therefore margins specified via CSS are not honored. Even if user specified style sheet is not used and page margins are set as 50 px during export, margins are not honored in iBooks and the book appears with default margin.

      Regards,
      Pooja

    • #66440

      Susan M
      Member

      Many devices have their own default page margins. Trying to override system defaults often creates a poor user experience.

    • #67290

      @page is only supported by Nook as far as I know (Safari and other browsers only support @page margins when printed, as per the CSS paged media spec). All other e-readers have built in margins you cannot override—adding margins to the html or body elements would add additional margin to what already is built-in. As such I would probably avoid doing so.

  • #66028

    incblot
    Member

    Pooja, Thanks for the clarification!

    Yes, iBooks is its own beast. Safari not honouring the margins worries me more. It leaves me wondering how other reading devices will react.

    I also can’t understand why having two stylesheets is causing a conflict, even when both css files are adjusted to the same setting.

  • #66030

    David Blatner
    Keymaster

    @Pooja: You need to come to PePcon.com next June! Tell Chris K. or Anil! :)

  • #66036

    Pooja: Yes! What David said! ;-D Careful, we might make you do a workshop ;-D

You must be logged in to reply to this topic.
http://indesignsecrets.com/topic/epub-vs-idcc-indesign-creative-cloud
indesignsecrets.com
crawl=CC-MAIN-2014-49
65729
application/http; msgtype=response
sha1:23DRIAQEOAUNFOIGM5CSI7CMBJIKK2YS
<urn:uuid:68d990d3-0b88-421a-bf60-072e3096ad52>
2014-11-27T02:41:43Z
192.237.225.94
sha1:TKEDFCUFPPRODJJIXUSNRXEMSPVEAH6N
<urn:uuid:643c934d-a8d5-4f82-90d9-6464d8bf304d>
http://indesignsecrets.com/topic/epub-vs-idcc-indesign-creative-cloud
length
response
<urn:uuid:d594341d-8131-4a72-bb0b-be77a9898bc7>
robots: classic
hostname: ip-10-235-23-156.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2014-49
operator: CommonCrawl Admin
description: Wide crawl of the web with URLs provided by Blekko for November 2014
publisher: CommonCrawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf