Editorial Manager and ScholarOne: Troubleshooting Common Submission Portal Glitches and Errors

Few moments in the research publication process feel as high-stakes as clicking “Submit” after weeks (or months) of writing and preparation. Yet many delays happen for reasons unrelated to scientific quality mis-tagged files, stubborn PDF builders, missing metadata, or a final proof that looks “mostly fine” until a table splits across pages.

Two platforms dominate the research manuscript submission experience across publishers and societies: Editorial Manager (EM) and ScholarOne Manuscripts (S1M). Both can support rigorous workflows, but each has predictable submission portal quirks researchers should plan for. This guide offers a practical comparison of common technical glitches, a reliable approach to ordering files for PDF auto-generation, and a repeatable method to verify the final HTML proof before approving manuscript submission.

What these systems do (and why the quirks matter)

Both EM and S1M are journal submission management systems designed to collect research manuscript files, author details, declarations, and metadata in a structured way. They also feed those inputs into downstream processes peer review, production, and archiving. That structure is helpful, but it also means small inconsistencies (file naming, figure labeling, reference formatting, permissions) can trigger errors that feel opaque to authors.

Many journals configure EM and S1M differently. Even within the same platform, two journals may impose different file types, different “item type” labels, or different rules for what the PDF builder will accept. That variability is why researchers often look for a website submission service or software submission service when deadlines are tight or when a journal’s portal has unusually strict requirements.

Editorial Manager vs. ScholarOne: the most common differences researchers notice

File taxonomy: EM is “item type–driven,” S1M is often “step-driven”

In Editorial Manager, successful submission often depends on assigning the correct item type to each uploaded file (e.g., manuscript, figure, supplementary material). Many journals also allow batch actions like changing item type for multiple files, which is useful when the system unpacks a ZIP and everything defaults to an incorrect label.

In ScholarOne, the workflow often feels more “wizard-like” (enter information → upload files → build PDF → review → submit). The portal may still ask for file designations, but authors often experience friction later during PDF building or when required fields trigger validation errors near the end.

Practical implication: EM issues frequently come from incorrect item types or file packaging; S1M issues more often show up as late-stage validation or PDF build failures.

Packaging files: EM commonly supports zipped source uploads (journal-dependent)

Some EM journal configurations allow authors to upload a .zip or .tar.gz of source files that gets automatically unpacked, after which item types must be assigned.

Practical implication: If a journal allows packaging, EM can be faster for LaTeX-heavy workflows, but only if file typing is done carefully after unpacking.

LaTeX handling and “do not upload PDF” rules can differ

Some EM journals provide explicit LaTeX instructions, including rules like uploading LaTeX sources under a LaTeX item type and not including a compiled PDF at that stage.

Practical implication: When submitting LaTeX, treat the journal’s portal instructions as higher priority than personal habit. A “helpful” extra PDF can cause conflicts in automated rendering pipelines.

Common technical glitches (and what usually fixes them)

1) PDF auto-generation fails or stalls

What it looks like: The build spins indefinitely, finishes but produces a blank PDF, or generates a PDF missing figures or tables.

What typically causes it:

• An unsupported figure format (or a corrupt image file)
• A large file size that times out during conversion
• Fonts or equations embedded in ways the converter cannot interpret (common in Word-to-PDF pipelines)
• Mixed upload logic (e.g., uploading both a fully composed PDF and source files when the journal expects only one approach)

What usually works:

• Re-export figures to a journal-safe format (always follow the journal’s guide)
• Reduce file size without changing resolution requirements
• If the portal accepts it, upload a single clean manuscript PDF for initial submission and provide sources later (journal-dependent)
• Rebuild the manuscript PDF from a “clean” source file (accept tracked changes, embed fonts, re-render equations)

2) “Required field missing” appears late in the process

What it looks like: Everything seems complete, but the final submission page flags a missing checkbox, contributor role, funding line, or ethics statement.

What typically causes it:

• The system treats some fields as conditional (e.g., clinical trial registration appears only after selecting a study type)
• A co-author’s email or affiliation formatting fails validation (extra spaces, special characters)
• ORCID prompts not fully completed (journal-dependent)

What usually works:

• Review each metadata tab again after file upload, because some portals re-check requirements after attachments are added
• Copy-paste content into a plain-text editor first to remove hidden characters, then paste into the portal

3) Tables break, float, or vanish in the generated PDF

What it looks like: A table splits mid-row, appears at the end of the document unexpectedly, overlaps text, or becomes unreadable.

What typically causes it:

• The PDF builder is interpreting tables as images or as complex Word objects
• Tables are embedded as pasted spreadsheets with merged cells and nested formatting
• Table captions are not linked or are placed inconsistently relative to the table

What usually works:

• Convert tables to simpler structures (avoid excessive merging, nested tables, and embedded objects)
• Ensure each table has a consistent caption format and numbering
• Where the journal allows separate table files, upload them as individual table files rather than embedding them inside the main text (only if the journal instructions support that workflow)

How to correctly order files for PDF auto-generation (so tables and figures behave)

PDF builders generally behave best when the submission package has a predictable hierarchy: a clear “main manuscript” plus discrete, consistently labeled supporting components. However, EM and S1M can assemble files differently depending on journal configuration. That makes file order and item type labeling more important than many researchers realize.

A stable ordering strategy that works in most configurations

When the journal allows multiple file uploads to assemble a combined PDF, a conservative sequence is:

1. Main manuscript file (Word or LaTeX main source, as required)
2. Tables (if submitted separately, one file per table or one consolidated tables file—follow journal rules)
3. Figures (one file per figure, numbered consistently)
4. Supplementary files (appendices, additional methods, datasets, reporting checklists)

The goal is not aesthetic preference. It is to prevent the PDF generator from placing tables and figures unpredictably, or appending them in a confusing order that reviewers must fight through.

File labeling and naming conventions that reduce conversion errors

• Use simple filenames: Manuscript.docx, Table1.docx, Figure2.tif, SupplementaryMethods.pdf
• Avoid special characters and long strings: no #, &, parentheses stacks, or version trails like FINAL_final_revised3
• Match in-text callouts precisely: “Table 2” in the text should map to a file named Table2…

A note on ZIP uploads (common in EM journal setups)

If the portal allows zipped uploads, it can save time, but it also increases the risk of incorrect item types after unpacking. In EM, journals may expect authors to correct item types post-unpack and can support batch item-type changes.

How to verify the final HTML proof before approving submission

Many authors treat the final proof step as a quick visual scan. That is risky because conversion errors often affect exactly what editors and reviewers see first: the title page, abstract, headings, tables, figure callouts, and references. A structured review takes only a few minutes and can prevent avoidable resubmission requests.

What to check in the HTML proof (and why it matters)

1. Title, author list, and affiliations
   Confirm spelling, order, and the corresponding author designation. Portal metadata can override what appears in the manuscript file.
2. Abstract and keywords
   Check for missing symbols, broken italics (e.g., species names), and truncated text, especially if the abstract was pasted into a form field.
3. Headings and section order
   Ensure headings did not collapse into plain text. If the journal uses automated screening, malformed structure can slow triage.
4. Tables (highest priority)
   Scroll every table start-to-finish:
   • Are columns aligned?
   • Are footnotes present and correctly linked?
   • Did any table split mid-row or lose shading that carries meaning?
5. Figures and captions
   Confirm each figure matches its caption and numbering. Look for swapped images, a surprisingly common conversion problem when multiple versions exist.
6. References and special characters
   Verify Greek letters, minus signs, superscripts, and diacritics. These often break when systems convert from Word or LaTeX to HTML or PDF.

A practical “two-format rule”

If the portal offers both an auto-generated PDF and an HTML proof, compare them side-by-side for the elements above. If the HTML looks correct but the PDF is broken (or vice versa), treat that as a signal that the source files need simplification or the upload types need correction before final submission.

Portal quirks that frequently trigger preventable delays

Editorial Manager: item type mismatches are a common root cause

EM’s flexibility is powerful, but it increases the chance of labeling mistakes. When figures are uploaded as the wrong type, or when the main manuscript is not tagged correctly, the system may build an incorrect combined PDF or route files improperly for editorial checks.

ScholarOne: validations can feel “late” and non-obvious

S1M workflows often feel smooth until the end, when the system surfaces missing declarations, contributor details, or file requirements. Planning for a final “metadata sweep” before clicking submit reduces last-minute surprises, especially for multi-author papers with complex funding and ethics statements.

How to decide which workflow to use when journals allow options

• If the paper contains complex tables, heavy math, or specialized symbols, a single author-generated PDF may be safer for first-pass review (if permitted).
• If the journal requires source files immediately, simplify formatting and keep tables and figures as clean, separate objects wherever possible.

Final takeaways: a research manuscript submission process that stays under control

Editorial Manager and ScholarOne both support rigorous publishing workflows, but each has predictable friction points. Researchers can reduce delays by treating research manuscript submission as a technical handoff: label files cleanly, upload in a stable order, and review the HTML or PDF proof with the same care used for the manuscript’s final pre-submission read-through.

When internal bandwidth is limited, or when repeated portal rebuilds are slowing progress, research teams often consider a specialized journal submission management partner. Enago’s Journal Submission Service can help researchers navigate portal-specific requirements, ensure compliance with journal instructions, and manage the upload and verification steps without derailing research timelines. If the main risk is technical non-compliance rather than content quality, Enago Reports’ Technical Check Report can also help identify frequent pre-submission issues across structure and formatting before the manuscript enters a portal workflow.