June 2018 Newsletter

Our reports from CSE and SSP 2018, the latest on NISO STS, how good is your metadata? and more in the June 2018 Newsletter!

#SSPat40

We enjoyed catching up with some long-standing customers and partners and meeting up with some newer ones at SSP 2018 in Chicago! The packed 40th Anniversary program included keynotes by Safiya Umoja Noble and Steve Mirsky, several meeting tracks focused on what’s new and innovative in our industry, SSP’s second Virtual Annual Meeting, and even a Ruby Anniversary party (with bonus fireworks)!

Artificial intelligence, metadata, and author data (sharing it, publishing it, assigning PIDs to it, and citing it) were hot topics at this year’s SSP, and we were happy to see good in-person and virtual attendance at Bruce Rosenblum’s session “The Gift that Keeps on Giving: Metadata & Persistent Identifiers Through the Research & Publication Cycle.” If you missed it this time around, watch this space—we’ll let you know when the session video is posted! For a preview, check out this post on the Copyright Clearance Center blog; you can see Bruce’s slides on the Inera site.

See Bruce’s slides!

On the Crossref blog: How good is your metadata?

Crossref is rolling out the beta version of a new type of report that will allow both Crossref members and other interested stakeholders to see how well publishers are doing at “placing [their] content in context by providing as much metadata as possible and looking after it long-term.” This “Participation Report” will grade the extent to which publishers depositing content with Crossref are depositing the following metadata elements for their content:

One SSP attendee noted some surprisingly missing elements when reviewing the results, so we recommend all Crossref members look closely at their own Participation Report. For all the details of this initiative, including a sneak peek at the format and content of this new report, see the Crossref blog!

What happens at CSE … can make better editors!

As we mentioned in last month’s Inera <News/>, our Director of Business Development, Elizabeth Blake, has been a faculty member for CSE’s Short Course for Manuscript Editors for the past 6 years. What keeps Liz and her fellow faculty members coming back, and a fresh crop of learners signing up year after year?

  • A deep dive into the nuts and bolts of editing, including how to leverage Word’s (often hidden) editorial tools; over the years, the course has included presentations on best practices for editing abstracts, tables, figures, references, and statistics
  • Roundtable discussions of ethical issues, including authorship, conflicts of interest, and permissions
  • A collaborative space in which editors from various organizations share their experiences and learn from their peers

We encourage you to consider signing up—or signing up members of your staff—for the 2019 Short Course. For more details, click here!

We also recommend checking out the session “The Good, the Bad, and the Ugly in Citations,” co-presented by Liz with Debora Poff of COPE and Angela Cochran of ACSE.

Click for slides from CSE 2018!

On the Inera blog: NISO STS Standing Committee

Now that NISO STS is an official ANSI standard, what’s next? The NISO STS Standing Committee, co-chaired by Bruce Rosenblum of Inera and Rob Wheeler of ASME! Read all about the committee (which also includes Inera Solutions Consultant Joni Dames), the update and public comment process, and how to submit your comments and suggestions on the Inera blog.

Help with normalizing MathML equations

If the MathML you’re getting out of author-supplied equations from both Microsoft OMML and MathType isn’t quite as clean as it should be, this tip is for you! From the JATS-Con 2018 Open Session, we draw your attention to mathml-normalize, “an XSLT library to normalize MathML equations with heuristic methods”—a post-export tool designed to clean up some of the most commonly encountered equation markup errors. The mathml-normalize library is available on GitHub.

Find Inera at upcoming conferences

► EMUG (Editorial Manager User Group Meeting)

Boston, MA, 21 & 22 June

Inera’s Bruce Rosenblum, Irina Golfman, and Bill Fox will be attending EMUG 2018 in Boston.

Attending EMUG Boston? We’d love to see you! Please contact us if you’d like to schedule a meeting.

 

Working with Word

Epic Word Fail: A mu is a mu is … not a mu?

► The Fail:

Picture it: the manuscript you’re working on is behaving perfectly normally … until it goes back to the author, who sends you a panicked email in the middle of the night because the units of measure have all mysteriously been multiplied by 1,000—that is, every quantity that should be in micrograms (μg) is instead given in milligrams (mg).

What on earth is going on?

There’s more than one right way to insert an accented character, non-Latin character, or other symbol into the text of a Word file, but there’s also a wrong way, and that’s what has happened here: the author of the manuscript changed the font to Symbol, then typed the “m”, in order to make the Latin letter m look like a Greek letter mu (μ). (This author may, like your roving reporter, have learned word processing on a DOS computer running WordPerfect 5.1, back in the days when you could get away with this sort of thing.)

It looks right, but the change may be only skin deep: the underlying Unicode entity isn’t 03BC (Unicode’s “Greek small letter mu”) or 00B5 (“micro sign”), it’s 006D (“Latin small letter m”). This means that if the font in the Word file is normalized by applying styles in Word, or simply by applying the copyeditor’s preferred reading font to the whole document, all those μs will be silently converted to ms, leaving no trace that they ever existed.

→ eXtyles users can relax: we’ve taken care of this for you! eXtyles Activate & Normalize will correctly change those pretend μs to real Unicode ones.

And as if that weren’t enough, we’ve also seen this technique turn the character into something else entirely (i.e., a Unicode entity that is neither a Greek small letter mu nor a Latin small letter m). If this has happened in your author-submitted file, you may end up with something weirder but much easier to detect, such as “tofu” (small white squares), Wingding-type symbols, or some other character that is very obviously wrong.

→ You can usually (though not always!) find out what Unicode entity is lurking under a letter (or other character) by selecting it and hitting Alt-x. To get your letter back, hit Alt-x again. If Alt-x doesn’t work, we advise using the first method below to insert the reliably correct character.

Note: The steps set out below are designed to avoid—and, if necessary, to fix—both variations of this problem.

► The Fix:

What should this author have done instead? As we noted above, Word offers several ways to insert a special character:

  • On the Insert tab, click Symbol, then More Symbols to bring up the full Insert Symbol menu. In this case, you would choose “(normal text)” in the Font box and “Greek and Coptic” in the Subset box to find μ.
    • If you need to use this character often, remember that Insert>Symbol>More Symbols>Shortcut Key also allows you to program an easy-to-remember keyboard shortcut.
  • Type the Unicode entity, then select it and use Alt-X to convert it into the associated glyph. In this case, you would type 03BC for mu (μ) or 00B5 for the almost-identical micro sign (µ); to find the Unicode entity for any character you might possibly need, see the searchable Unicode Character Tables here.
    • Why are Unicode entity names so weirdly specific? Well, here’s just a small part of the list of Unicode entities that comes up when you search “mu”:
  • Use “Alt codes” on your Windows keyboard. The code for μ is Alt-230; see a list of codes for other Greek letters here, and other lists, as well as helpful instructions for using Alt codes in general, here.
    Alt-coders beware: This method predates Unicode, so you can’t always be certain what entity it’s inserting under the hood…

eXtyles users also have another option: The Insert>Symbols menu on the eXtyles tab.

If you’re not the author of this manuscript, but you have to deal with it anyway, it’s time to break out your Find-and-Replace skills! Follow these steps:

  1. Somewhere in your file, type or insert the correct Unicode character (in this case, μ) in the font used in the surrounding text.
  2. Find one of the offending characters in your document, select it, and copy it. Note what font it’s in!
  3. Open up the Find & Replace dialog (Ctrl-H), then click the More>> button.
  4. Paste the character you copied in Step 2 into the Find what: box.
  5. With your cursor still in the Find what: box, go to Format>Font and choose the font you noted in Step 2 from the Font drop-down. You should now see Font: [Name of the font] right below the Find what: box.
  6. Click outside the Find & Replace dialog, but don’t close it. Find the character you typed in Step 1, and use Home>Cut or
    Ctrl-x to cut it to your clipboard. (You can copy it instead of cutting, if you remember to go back and delete it later.)
  7. In the Replace with: box, type ^c. (This will replace the contents of the Find what: box with the contents of your clipboard.)
  8. Replace each instance individually, and check that it’s doing the correct thing, because you never know.

Bonus Tip: How Many Spaces … ?

You may have read this article, the latest entry in the debate over whether one or two spaces after a period (full stop) is the ideal number.

To make sure your publications look their best, you use proportional typefaces and insist on just one space after a period—but not all your authors agree. Fear not! Whatever number of spaces an author types, eXtyles Cleanup can impose consistency for you.

→ Want one more argument for not typing two spaces after a period? HTML browsers will automatically convert multiple contiguous spaces to a single space, so all that extra typing is just going to waste!

Have an intractable Word problem you’d love to solve? Have a clever tip to share? Send it to us at [email protected]!

Back to Newsletter