Choose an integrated EPUB editor by counting where twenty past revisions finish, not by counting feature names. Classify each revision as completed inside the editor, handed to an external tool, or blocked. Calculate the external-handoff rate and keep the blocker count separate. A candidate with few handoffs still fails if one change cannot return to an identifiable source of truth. “Integrated” should mean that real exceptions are limited and their return paths can be explained.
Select twenty revision tickets, not twenty features
Build the sample from revisions that actually occurred: body edits, chapter reordering, navigation labels, metadata, cover replacement, and CSS adjustments. Do not count the same task twice. Give every ticket one expected result. A set invented only for product comparison will not represent the exceptions in your production work.
Each row needs revision ID, request, expected result, authoritative source, and classification. The authoritative source is the place where the change must live so that it survives the next generation. If a ticket has no identifiable source before testing a candidate, mark it separately as unable to classify.
Classify by where the revision finishes
Inside means that the expected result is saved to an authoritative source within the editor. External handoff means another tool is needed, but the input, output, and return location are all known. Blocked means that the required change cannot be completed or the result has no known return path.
Do not classify by the number of applications opened. A cover replacement can remain a valid handoff when the edited image returns to the declared cover setting. Conversely, an adjustment made inside the editor is blocked if it affects only a temporary view and has no durable source.
Require three fields for every handoff
Every external row needs input, output, and return.
input: the file or value sent outsideoutput: the file or value produced externallyreturn: the authoritative location inside the editor
A cover row might read input=cover.png / output=cover-fixed.png / return=cover settings. If any field is missing, classify the ticket as blocked rather than making the handoff rate look better.
Read exception rate and blockers separately
The handoff rate is external handoffs divided by twenty, multiplied by 100. Blockers remain an absolute count. Set the acceptable handoff rate before comparing products and require zero blockers.
For illustration, candidate A with 14 internal, 4 external, and 2 blocked revisions has a 20 percent handoff rate but fails because two tickets are blocked. Candidate B with 16 internal, 4 external, and 0 blocked can advance when the team’s limit is 20 percent. These numbers explain the method; they are not measured results for named products.
Build the candidate result from twenty rows
| Candidate | Internal | External | Blocked | Handoff rate | Example decision |
|---|---|---|---|---|---|
| A | 14 | 4 | 2 | 20% | Reject because work is blocked |
| B | 16 | 4 | 0 | 20% | Trial when the limit is 20% |
Each row total must equal twenty. Otherwise a revision remains unclassified. Do not add an average feature score. This table answers only whether the candidate closes past revision work and makes its exceptions operationally reproducible.
Treat Rune Studio as a candidate before measurement
Rune Studio documentation confirms a feature scope covering manuscript editing on Mac, preview, metadata, navigation, cover, and EPUB 3 output. That scope is enough to place it in the twenty-ticket comparison. It is not a measured twenty-ticket result.
Advanced package-level edits may become external handoffs. The actual internal, external, and blocked distribution can be known only after a team’s own tickets are tested. Production speed, fixed-layout work, and preservation of unknown elements in third-party EPUBs remain outside this decision.
Choose zero blockers and explainable exceptions
Check the blocker count first. A candidate with any blocked ticket does not pass this integrated-editor decision. Compare handoff rates only among zero-blocker candidates, then confirm that another editor can reproduce every input/output/return path.
The conclusion does not come from the feature list. It comes from the destination of each of twenty past revisions. Start by listing the most recent twenty revision tickets and adding their expected results and sources of truth. That sheet turns an integrated label into a decision based on your own exception workload.
If twenty real tickets are not yet available, do not pad the sample. Collect the most recent actual rows and keep the measurement pending until the sample reaches twenty. Do not publish an interim small-sample distribution as a product-wide exception rate.
Your next step is to add ID, expected result, and authoritative source to the most recent revision tickets.
If Rune Studio enters the shortlist, confirm its current scope on the product page and in the feature documentation before adding it to the same twenty-ticket sheet.
