[Hitch]

Originally Posted by Tex2002ans

This is where I'm confused.

This is how I'm imagining the workflows:

Method A

• Get original file. (DOCX)
• Edit/Proof book. (DOCX)
  
  • Author + Team = Multiple Rounds of proofing.
• Create ebook. (EPUB)

Method B

• Get original file. (DOCX)
• Create ebook. (EPUB)
• Edit/Proof book. (EPUB / EPUB->DOCX)
  
  • Author + Team = Multiple Rounds of proofing.

Method A is what most publishers do.

Method B is what I mostly do.

We really don't do either of those.

We take the docx file, OR the PDF, or this or that (powepoint, Canva, you name it) and we clean it. If it's DOCX, we clean it largely using HTML. I'm the only one that really cleans in Word and that's only because I got spoiled by Toxaris' ePUBtools, which sadly, no longer work.

Nonetheless, it's:

1. DOCX (or whatever) to HTML.
2. HTML to ePUB.'
3. ePUB to customer.
4. PROOF FORM to us
5. We make the edits.
6. Revised ePUB to the customers.

IF the book is being edited or proofed by one of our editors, that's done before step 1. We don't give Word files to our customers, for ebooks. It's just too much brain-damage to have to reclean, style, etc. a DOCX file that comes back to make it BACK into HTML and BACK into ePUB. I can't think of a single eBookmaker here that wouldn't quit on me if I suggested it. None of them are being paid to make the book twice.

Not ONE of our customers, seriously, uses styles and headings. And for those that send us other file types, NOT word files, but everything else, now we're in even deeper kimchee. And let's not forget our Pages users, etc.

I would end up with clean, styled Docx files, from the ePUBs, then interspersed with "normal" and god-only-knows-what-else jammed in there. It would take longer to find all the cruft and fix it than it is to do what we're doing.

It's just shifting where the editing stage ultimately slots in.

With Method A, you have:

• The Editor modifying the DOCX + cleaning up most of the author's junk.
• That DOCX gets split into InDesign + EPUB.

What "editor" are you talking about here? YOU? Yes, Tex, I know that you compulsively clean and edit your customers' files, but we do not. Not sans compensation for that work and 99% of our customers won't pay for us to run around and clean/edit their files, other than formatting. We have one edit that we make daily, which is the ubiquitous "forward/foreward" (yes, really) to "foreword." That's it. That I do because I can't abide having that error so close to the front of the book and visible in the frontmatter.

With Method B, you have:

• The Converter modifying the DOCX + cleaning the junk.
• That gets in the Editor's hands.
  
  • They're more efficient, because the document is already clean + consistently Styled.

From what I gathered, at the Proofing/Editing stage, you'd want Author+Editing team working together, being able to see the "finalized" text in the browser.

There seems to be a person, a role in here, that we do not use/have, this "editor" persona. If you mean you, great for you, but we don't have that role. We have bookmakers and customers, period.

On top of that, this "They're more efficient, because the document is already clean + consistently Styled" only lasts UNTIL the author gets their hands on it. We deal with this same issue, in a Word file, over and over, in our print process, which is somewhat like you've described. SAME PROBLEM. Some of the Word files we get back--which are meant to slide into INDD, seamlessly, and integrate the changes, are SO EFFED UP that it's safer and better to, yes, do the edits by hand, instead of risking corrupting the entire INDD file. Seriously--this happens every week.

THIS is where the browser-based word processors would slot in—then, you'd get all the mature advantages of word processors NOW:

• Comments
  
  • Marking/Replying
• Tracked Changes
  
  • Accepting/Denying
• Keeping all parties in sync.
• Easy A/B Comparison
• [...]

And while the EPUB->DOCX wouldn't be an exact replica of how the final ebook would look, it could be a "rough approximation".

Maybe, but I still think that a browser-based ePUB reader, allowing the customer to slap their edits in there (which, ideally, would also be counted!!!), and the bookmaker being able to easily see and make the changes, is better than the alternatives. We get edits that are literally incomprehensible, or completely daft, like "remove 'the' on page 37." Seriously, yes, we get those. IF the author were writing that in this hypothetical in-browser reader, that might actually show the bookmaker where that edit could be.
- - -

With EPUB Annotations, all it would do is create a Method C:

• Get original file. (DOCX)
• Create ebook. (EPUB)
• Edit/Proof book. (EPUB)
  
  • Author + Team = Multiple Rounds of proofing.

I don't see how it would help merge those author-comments + author-changes back into the finalized EPUB that much better over Method B.

I think you're simply accustomed to working with organizations that have professional people, and/or you've trained them. You've forgotten what it's like, in the wild.

- - -

Side Note: Of course, I welcome all Web Annotation tools/enhancements!

Like I wrote in that 2022 thread, the current landscape is a mess! We definitely need more interoperability between all Annotation tools!

- - -

Yes, that would be nice.

Hmmm, interesting.

So you're telling me a PDF Highlight + PDF Comment can be merged back into the text somehow?

Yes and has been that way for some years now.

(And... the stuff I explained would be a browser-based DOCX Highlight + DOCX Comment + you'd get Tracked Changes.)

Not sure to what it is you are referring.

Hmmm... We'll definitely have to chat about that some time.

Been doing it for 3 years now.

Heh, yeah, I forget... not everybody creates perfectly crisp HTML like me!

"Perfectly crisp" HTMl has sweet FA to do with it. What you are NOT thinking about is what the author does to the file, whilst they have it. It's all well and good if you have novels or simple non-fiction, but by the time you're working with sidebars, text-boxes, pull-quotes, charts, tables, figures, captions, topic-matter indices, lists of all sizes shapes and sorts, subheadings, run-in headings...it's not going to work. Trust me, it won't.

Conversion between formats and merging back changes becomes much harder+unstable once you start drifting away from that ideal.

Sure, and if we were, let's say, working for Random House and a series of 5 editors, and we knew what they'd give us, and we would give them back Word files and all that, it would likely work. In the course of a given week, we have 50 different customers, all using different word processors, with widely varied skill levels--again, 90%+ wouldn't know Styles or Headings if they slapped them in the fact--it's a whole different kettle of fish. I'm trying to make it SIMPLER for them and easier for us. Trying some method that won't work in our environment--well, it won't work.

I know this BECAUSE we use a DOCX (ish) to INDD, to print layout, to Word file BACK to the customer, get customer's edits, BACK to INDD methodology now. I stupidly thought that would be easier, but as described above, it's a constant hassle. For those customers with 200-2,000 revisions (which is not uncommon, mind you) yes, it typically saves us some time--but when they've changed margins, changed fonts, changed letter-spacing, changed line-heights and on and on and on...I really cannot explain it to you.

Side Note: And, as we discussed in those previous threads, every single input->output format/conversion brings its own unique challenges.


Not too sure what that means, but okay.

(dictating to Dragon Naturally Speaking, because my left shoulder's frozen shoulder is acting up. This is clearly my yar for crud and illnesses.

Hitch