Using Transparency forces the display to use “accurate colors” for your current Document Color space. Since not every color can be converted accurately from RGB to CMYK (InDesign's default color space), ID converts them to the nearest possible value.

You are not printing the document — which does need it to be in CMYK space –, so you can simply change the blend space to RGB. It's in the File menu, I believe.

Hey Hank, two (tiny!) addenda to your excellent step-by-step. First off, this is exactly how I taught myself to create covers!

Rotate the frame so that the top of the letters face the front cover, and the bottom of the letters face the back cover.

It's easier to explain the function rather than the form :-)

The spine should be readable when the book is lying flat on its back, with the front up.

Am I correctly remembering that the German style is the other way around? (And do they have a logical reason, other than “It's been done like this fur years”?)

Place the text frame in the Spine Area – adjust the position so that the text is visually centered on the Spine.

Simply set that frame's height to the spine width (remember, it's rotated) and set Vertically Centered in the text frame properties. If you have an all-caps (or Mostly Caps) title, you can set the Baseline Options to Cap Height. Otherwise use x-height, so lower case characters will be exactly in the center. Don't use Leading, it's of no use on a spine.

We'd get clients complaining “some chapters have a blank before them, others don't”, until we changed the PDF Open View to always show 2 pages at once, with a title page. You can change this in Acrobat, Document Properties, View Settings, then save.

Pity InDesign can't automatically create its PDFs with that setting (I sent a Feature Request for that).

— And we still get that complaint, only now it's not always. :-(

A somewhat friendlier version (with a dialog!) can be downloaded from https://www.jongware.com/binari…..ttings.zip

It defaults to the current active document's settings, or the application defaults if there is no doc open. So to copy “from” one document to the active book, first open a “good” document then run.

For completeness sake I added the Small Caps size as well.

Actually, apart from testing if it does anything at all, I didn't really try it. It seems to work, though. Check after running.

Errr… No I was at work. Honestly! :-)

(Awakes.) Wot? Wot? A script? This javascript ought to work (note: untested!). Copy, save as “CopySupPrefs.jsx” into your scripting folder. Open your book file; then create a new text document and set the preferences as you want them. Run the script to copy these to all documents in the Book. Be aware that — if it works — your text may re-format, because you are changing sizes.

supPos = app.activeDocument.textPreferences.superscriptPosition;
supSiz = app.activeDocument.textPreferences.superscriptSize;

infPos = app.activeDocument.textPreferences.subscriptPosition;
infSiz = app.activeDocument.textPreferences.subscriptSize;

book = app.activeBook;

for (var i=0; i<book.bookContents.length; i++)
{
 var currentDoc = app.open (book.bookContents[i].fullName, false);
 currentDoc.textPreferences.superscriptPosition = supPos;
 currentDoc.textPreferences.superscriptSize    = supSiz;
 currentDoc.textPreferences.subscriptPosition   = infPos;
 currentDoc.textPreferences.subscriptSize    = infSiz;
 currentDoc.close(SaveOptions.YES);
}

PS (aka. “Type 1”) fonts: PostScript outlines. Separate files for outlines and kerning (on Windows, but not on Mac). Rigged to encode only a max of 256 characters at a time, in predetermined encodings (echoing Bill Gates: “Who will ever need more than 256 characters!?”) Characters and features such as extended ligatures, small caps, and old style numbering live in separate fonts — just today, I got a font where I had to type a “K” in another font to see an “fi” ligature.

TTF fonts: TrueType outlines. Huge character sets — full Unicode 2.0 set supported. No feature-enabled re-coding, though — if a font has small caps or oldstyle numbering, it'll be in non-standard positions, and you will have to select and insert the characters manually.

OTF: Outline format: either of the above, and I couldn't care less which one. Who can tell by looking if a font uses quad or bezier curves? Mega ultra size character sets (Unicode 3.0 — is there a 4.0 forthcoming?). Features can be enabled and disabled per user request, enabling access to language sensitive characters (S cedilla vs. S comma-below, o kreska rather than o grave), more ligatures than a sane person could ask for (anything is allowed, viz. the custom “Zapfino” logogram if you type its name, and the amazing Ed Interlock), context aware kerning, and typographical niceties such as hand drawn superiors and inferiors and real small caps. Amazing possibilities.

So, it sounds you should convert everything you own and then some more to OTF. Or, does it?

If you convert a font to OTF, it will not have all the niceties I summed up. Special ligatures have to be drawn — or, if they exist in another font file, copied to the base font file. Small caps ditto. And then you have to add the mini OTF programs that actually allow these automatic replacements to take place — it doesn't happen by itself.

I'm also not totally 100% sure of the kerning conversion that takes place. Are all existing kerning pairs correctly converted? All you have to do is type “VAT”, and you'll see if it does. Oh — and all extra OTF types of kerning (class kerning, context aware stuff) should also be added manually.

So there are no real benefits of converting your fonts, and only (possibly) drawbacks. Your computer (or specifically, FontExplorer) doesn't mind handling all different font types. Sure, OTF has lots more possibilities, but you'll have to add them yourself, and that amounts to completely overhauling each and every font.

Unless anyone else can convince me, I'm sticking to my old (t)rusty PS fonts, unless an official Pro version comes out — now these are worth upgrading to!

PS (aka. “Type 1”) fonts: PostScript outlines. Separate files for outlines and kerning (on Windows, but not on Mac). Rigged to encode only a max of 256 characters at a time, in predetermined encodings (echoing Bill Gates: “Who will ever need more than 256 characters!?”) Characters and features such as extended ligatures, small caps, and old style numbering live in separate fonts — just today, I got a font where I had to type a “K” in another font to see an “fi” ligature.

TTF fonts: TrueType outlines. Huge character sets — full Unicode 2.0 set supported. No feature-enabled re-coding, though — if a font has small caps or oldstyle numbering, it'll be in non-standard positions, and you will have to select and insert the characters manually.

OTF: Outline format: either of the above, and I couldn't care less which one. Who can tell by looking if a font uses quad or bezier curves? Mega ultra size character sets (Unicode 3.0 — is there a 4.0 forthcoming?). Features can be enabled and disabled per user request, enabling access to language sensitive characters (S cedilla vs. S comma-below, o kreska rather than o grave), more ligatures than a sane person could ask for (anything is allowed, viz. the custom “Zapfino” logogram if you type its name, and the amazing Ed Interlock), context aware kerning, and typographical niceties such as hand drawn superiors and inferiors and real small caps. Amazing possibilities.

So, it sounds you should convert everything you own and then some more to OTF. Or, does it?

If you convert a font to OTF, it will not have all the niceties I summed up. Special ligatures have to be drawn — or, if they exist in another font file, copied to the base font file. Small caps ditto. And then you have to add the mini OTF programs that actually allow these automatic replacements to take place — it doesn't happen by itself.

I'm also not totally 100% sure of the kerning conversion that takes place. Are all existing kerning pairs correctly converted? All you have to do is type “VAT”, and you'll see if it does. Oh — and all extra OTF types of kerning (class kerning, context aware stuff) should also be added manually.

So there are no real benefits of converting your fonts, and only (possibly) drawbacks. Your computer (or specifically, FontExplorer) doesn't mind handling all different font types. Sure, OTF has lots more possibilities, but you'll have to add them yourself, and that amounts to completely overhauling each and every font.

Unless anyone else can convince me, I'm sticking to my old (t)rusty PS fonts, unless an official Pro version comes out — now these are worth upgrading to!