looks like a bbox problem...

The clipping in Word is related to a performance optimization that treats each line with in a paragraph as independent when it is rendered to the screen. The “empty” space between lines is drawn as white, which can be drawn over other lines – and therefore clip those lines. When you print, the empty space isn’t drawn so hence no clipping.

Thanks for that info. So the print preview is also misleading.

Is it possible to use this font in Illustrator CS5 with the stylistic sets 6 and 7? If so, how?

The vertical metrics in the Gabriola font are set to prevent this kind of clipping, so it isn't a bbox issue. I've all but given up trying to understand how Word interprets those metrics, though, and how it relates to user choices about how to specify linespacing.

I would experiment with setting linespacing as absolute values in point sizes rather than multiples, as this often removes clipping, even if the resulting linespacing is identical.

As Si notes, the clipping should not appear when printed.

I also advise against using stylistic sets 6 and 7 to address envelopes, unless you want all your mail to have to be manually sorted.:)

I've all but given up trying to understand how Word interprets those metrics, though, and how it relates to user choices about how to specify linespacing.

Coming from you that’s kind of scary…

Si: The “empty” space between lines is drawn as white...

What do you mean by "white?"

I'll ask Office what they meant. I assume it relates to the background of the page and not #FFFFFF.

That'd be great thanks.

Coming from you that’s kind of scary…

Word linespacing used to be fairly straightforward: à la other MS text apps like Wordpad and NotePad, the default linespacing was determined by the combined OS/2 WinAscent and WinDescent metrics, as rounded to logical units for individual ppem sizes.

In Word 2007, MS made two significant changes:

1. They set the default linespacing to be 1.15 times the vertical metric in the OS/2 table to increase the default leading. Typographically, this is an improvement in most Word documents with most fonts, since most such documents tend to have quite long line lengths relative to type size. [They also increased the default text size from 10pt to 11pt.]

2. They implemented support for recognition of the OS/2 table version 4 fsSelection bit 7, which tells an application to use the OS/2 Typo metrics for linespacing instead of the Win metrics. In theory, this means that a font can have independent linespacing and clipping metrics, which means that fonts with some very tall variant glyphs, e.g. Gabriola, can have adequate non-clipping areas defined by the Win values, while not needing excessively large default linespacing. But this is where things get confusing and difficult to predict, because there seems to be a Word linespacing algorithm that in some situations produces linespacing that is independent of the font metrics. It looks like the Office developers implemented support for fsSelection bit 7, saw some fonts in which they didn't like the result of using the Typo metrics, and decided to bypass the metrics and apply algorithmic linespacing. This means that in some fonts the Word linespacing is defined by neither the Win metrics nor the Typo metrics, but by Word, in a way that does not appear to be publicly documented.

As noted in my response above, whether clipping occurs depends on how the user specifies linespacing in the paragraph properties dialogue. If linespacing is specified as a multiple of the basic spacing, then clipping will occur if the specified value results in spacing that is tighter than the Win metrics (or, I suspect, tighter than Word's algorithmic spacing). But if the linespacing is specified as an absolute value, then clipping usually won't occur, even if the resulting linespacing is equally tight.

I have not looked at Word 2010 linespacing to see if it is the same as 2007.

Much too complicated, all printed fine without cut offs. All envelopes delivered- they were Christmas cards so no urgency. Might include the postal barcode if Gabriola is used in the future. Still haven't found a way to use stylistic set 7 in InDesign. Oh well.

Zeb -- Still haven't found a way to use stylistic set 7 in InDesign.

It is possible with a little trick, by activating the built-in World-Ready Composer. On Thomas Phinney's website there is an article about it, including an InDesign template document and scripts by Peter Kahrel both of which allow to activate the WRC. This screenshot shows some text typed right into the template document, with Gabriola and Stylistic Set 7 applied:

This is in CS4. I assume it works in CS5 too.

Still haven't found a way to use stylistic set 7 in InDesign. Oh well.

Karsten, I don't think this is a WRC issue.

There seems to be a bug in CS4 that results in the last stylistic set feature present in a font not working (even if there is only one stylistic set feature). In the case of Gabriola, this means the stylistic sets 1-6 work fine, but set 7 does not. I don't know if this is fixed in CS5.

My interpretation was that "ss07" does not work in InDesign because its native layout engine, in contrast to the WRC, is ignorant of type 2 lookups [one-to-many] which are involved in Gabriola's Stylistic Set 7. Other fonts' last Stylistic Set features seem to work in CS4. Of course it were nice if Adobe apps would support all lookup types by default.

I can confirm that SS07 works in InD CS5 with the Word Ready Composer.