Line spacing when using Combining Diacritical Marks

[waltzmn]

Nisus folks --

I'm looking for a workaround for a line spacing problem. I'm editing a medieval Latin manuscript page, and it's full of abbreviations. So, for instance, the word "in" is abbreviated as i with a bar over it, ī.

This is no problem, because ī is in the unicode character set. But there are many of these abbreviations that are not. For example, "quae" is abbreviated q with an overbar. That's not in the unicode character set, at least that I can find anywhere.

Unicode has a solution for this; it's the "Combining diacritical marks" character set. So a q can be combined with an overbar to give q̅. That's two characters, note, even though it looks like one -- copy it and backspace over it and you'll see.

Using the Combining diacriticals is a perfectly workable solution, except that, when I enter my q̅, NisusWriter suddenly ups the line spacing dramatically -- from about 14 point (on 12 point type) to around 18 point. I can manually set the leading to 14 point -- but if I do that, then NisusWriter (in effect) raises the text about three points above the proper baseline. And if I put this text in a table cell, it still gives me an 18 point high table cell even when the leading is reduced to 14 point.

I need to be able to put the literal text, e.g. q̅, in parallel with the proper text, e.g. quae. I can't have one with the baseline way above the other. Is there an easy way to do this, or am I going to have to format every line with manual leading, baseline shifts, table cell heights, etc.

I've attached a sample showing the problem. It's the last line of the table, which is highlighted in red. There are other examples in the cells above that.

[martin]

The core problem here comes down to fonts. Nisus Writer doesn't directly increase the line spacing or raise your text because of the overbar. The problem is that the composed character q̅ is not supported by your document font. Arial Narrow cannot display q̅ in your text. Whenever this happens Nisus Writer must choose another font to show your text.

This process is called "font substitution" and the newly chosen font is called the "fallback" or display font. If you select a character like Ꜫ in your document the Formatting Examiner should make this situation clear:

palette2.png (34.9 KiB) Viewed 4507 times

You can see that Arial Narrow has been substituted and replaced with Geneva. These fonts have different intrinsic metrics (eg: height, baseline, etc). That's why your lines of text no longer match up.

The ideal solution is to use a font in your document that supports all the characters you intend to type. Otherwise I'm afraid you're stuck fiddling with the line height and baseline to try to match things up visually.

[Elbrecht]

Hi –

but that should work with FIXED LINE HEIGHT – I would never do without, btw.

HE

[waltzmn]

Elbrecht wrote:

Hi –

but that should work with FIXED LINE HEIGHT – I would never do without, btw.

In this particular case, that doesn't work. It forces the line to a certain height, but it doesn't put the baseline in the right place, which was my real problem.

Martin didn't really have an answer, because there doesn't seem to be ANY font that has all the miscellaneous symbols needed to transcribe medieval Latin -- but I didn't know of the "formatting examiner" palette he pointed out. That at least gives me a diagnostic tool for when fonts get substituted. It's a help.

Thanks.

[Elbrecht]

Again –

seems to be fine with me – Arial Narrow done!?



HE

[johseb]

Martin,
in regards to Formatting Examiner's ability to detect font substitution I made a quick test (using OP's document).
It seems that FE is detecting the substituted font for main text but not for text inside the table.
Am I missing something?

[adryan]

G'day, all

There are things happening here which I'm afraid I don't understand. If someone can shed some light on them, it might help waltzmn as well.

In the file waltzmn posted, consider the Table cell in the first column beginning with "muelē. audi vocē". The text here contains the q̅ glyph discussed.

First, the vertical alignment of text in this cell appears to be Top, which would seem to be at variance with the line height problem seen when the glyph in question is situated in ordinary (non-Table-situated) text. One would have expected the text in this cell to be lower than that in the other cells in this row. According to the Table Cells Palette, all the cells in this row have Middle vertical alignment. Positioning the cursor in any cell in this row and choosing Top alignment does in fact move text higher, except in that first cell where its position remains unchanged. I find this curious.

Also, when I select that glyph, the Formatting Examiner does not indicate that a font substitution has occurred. It merely indicates a Displayed Formatting Font of Arial Narrow, albeit with grey diagonal hatching.

Next, I created a "Lorem ipsum" document and set all the text to Arial Narrow. Application of a combining overline to the letter "q" lowered the relevant line when Line Spacing was set at 1 lin but left the line unchanged when Fixed Line Height was chosen instead. This would appear to confirm Elbrecht's observation. I might add that, with Fixed Line Height chosen, the position of the line remains unchanged even when a combining overline is applied to a character with a high ascender, such as "b".

But in this situation, too, the Formatting Examiner gave similar information as before, with no indication of font substitution.

So, I don't understand what's happening in the Table. I don't understand why Elbrecht's suggestion doesn't work for waltzmn. And I don't understand what's going on if font substitution is not the whole story.

Cheers,
Adrian

[Elbrecht]

HI all –

my guess, as I never ever use Arial – and there are different version around, too!

For the "q̄" I would prefer and did use a "macron" for just a single character: entered "q" with SHIFT/OPTION: "a" on ABC – Extended Keyboard. I never need to enter multiple "overlined" characters though, what might make for a difference.

And I write in "fixed line height" only – not to loose typografical control – overall.

But for the sample page offered – besides using Arial – I would customize the font to contain ALL special characters ever, first. Make things simple – the EYE has to read it.

HE

[martin]

in regards to Formatting Examiner's ability to detect font substitution I made a quick test (using OP's document).
It seems that FE is detecting the substituted font for main text but not for text inside the table.
Am I missing something?

This is working correctly for me, in either a table cell or the main body text. Please try selecting the character fully. If there's no selection and you just have an insertion point (caret) the palette won't show that any font substitution has occurred, because no character is actually selected.

[martin]

First, the vertical alignment of text in this cell appears to be Top, which would seem to be at variance with the line height problem seen when the glyph in question is situated in ordinary (non-Table-situated) text. One would have expected the text in this cell to be lower than that in the other cells in this row. According to the Table Cells Palette, all the cells in this row have Middle vertical alignment. Positioning the cursor in any cell in this row and choosing Top alignment does in fact move text higher, except in that first cell where its position remains unchanged. I find this curious.

The line of text in the table cell where font substitution has occurred is simply taller, either because of the fallback font metrics or font leading. That's why the vertical alignment matters less (or doesn't shift the vertical position at all). If you increase the table cell's height you'll see the vertical alignment still matters.

Also, when I select that glyph, the Formatting Examiner does not indicate that a font substitution has occurred. It merely indicates a Displayed Formatting Font of Arial Narrow, albeit with grey diagonal hatching.

Let's just call this a bug. The Formatting Examiner palette incorrectly shows the mixed font state without the substitution indicator because of the composed character sequence (the overbar is a combining character). Even though the "q" is supported by Arial Narrow and the overbar is not, it's incorrect to show the mixed state because ultimately the characters are shown at once using a single glyph. I'll file a bug, thanks!

[waltzmn]

This isn't really relevant to the topic, but it might explain why simple solutions aren't, well, simple.

Elbrecht wrote:

But for the sample page offered – besides using Arial – I would customize the font to contain ALL special characters ever, first. Make things simple – the EYE has to read it.

That was in fact the original intent: I chose Arial as the face not because I like it but because it had a relatively large fraction (not all) unicode characters encoded. And then was forced to Arial Narrow because the line length was so long in the incredibly tiny script used. (Equivalent of about six point type, hand-written! A lot of it I can't even read without enlarged scans.)

But I gather, from your response, that you have never edited a medieval manuscript, at least in Greek or Latin. We think of the Latin alphabet as having 26 letters -- but not in manuscript. It had a few dozen letters (no w, e.g.) -- and it had a few hundred contractions, suspensions, abbreviations, nomina sacra, etc., most of which are not included in our restricted character sets; they created extra glyphs for their contractions. But no two scribes used the same set of contractions! Worse, a scribe may sometimes use a contraction and sometimes not (presumably, at some point, a scribe was taking a document with few contractions and starting to add them, but sometimes failed to notice and just went on copying the un-contracted form.) One can, and should, look over a document to see what conventions a scribe uses -- and I did, and assembled a set of symbols to represent the more common shorthands used by this particular scribe (e.g. ꝑ = "per"; ʮ after r = "um"). And started editing, and came to a section where the scribe started using more contractions. (Same scribe, but perhaps he started using a different exemplar.) And these contractions, such as the q with overbar, had no unicode equivalent that I can find. Hence the problem.

I have, in fact, shifted the whole thing to Geneva, since it seems to come closest to having a complete unicode set. This is not a very good solution; Geneva is too wide, and of course the font size it claims is not its actual font size, and besides, it's as ugly as Arial! It's the best alternative I have. But understand that most "just do it" solutions aren't going to work when editing manuscripts. This is not typeset material; it's whatever the scribe decided to write! The ideal solution would be for NisusWriter to force a common baseline, but I'm pretty sure that that would require help from Apple....

[johseb]

Please try selecting the character fully. If there's no selection and you just have an insertion point (caret) the palette won't show that any font substitution has occurred, because no character is actually selected.

Selecting the character inside a table gives the correct result for me as well but the discrepancy remains: as shown in my previous post, putting the insertion point (caret) right after the character causes the FE to detect the font substitution in the main body text while you need to select the character fully for text inside a table.
Are there any reasons for the different behavior?

[Elbrecht]

Again –

the Baseline is defined by the Font used – so I would prefer not to leave my Font at all. Besides customising your Font you can combine within this font all Latin Characters with all Combining Diacritical Marks in the way I wrote before and all will be fine. Font substitution is forced when a font contains no pre-composed character and/or is not able to combine on the fly.

Try to think it over from within the Font!

HE

[martin]

putting the insertion point (caret) right after the character causes the FE to detect the font substitution in the main body text while you need to select the character fully for text inside a table.
Are there any reasons for the different behavior?

I would expect these to behave the same, so there's no good reason for the different behavior. I'll have to investigate, thanks!

[exegete77]

I am not an expert, but I wonder if the font set issue can make a bigger difference. I use Libertine http://libertine-fonts.org, and it does have some characters specifically for medieval fonts (Latin and Greek, and more scripts/fonts).

I originally came across this from reading the book Document Preparation for Classical Languages by David J. Perry, Greentop Publishing, ©2010.

If this is common knowledge, forgive my intrusion here.