Udostępnij za pośrednictwem

Word EQ Field and East Asian Formatting

  • Artykuł

This post discusses aspects of Word’s first math editing and display facility: the EQ field. This field is still used today for some East Asian formatting constructs. To have a built-up fraction a/b, one could (and still can) enter an EQ field with the contents \f(a,b). To try this in Word 2007, go to the Insert tab, click on Quick Parts, select Field..., scroll down to and click on Eq, click on Field Codes, after the EQ in the Field Code text box type \f(a,b), type ok, and you see the built-up fraction. Well it’s not really ok; it looks pretty awful by today’s standards, but back in the mid-1980’s it seemed cool at least if you didn’t know about TeX or my PS Technical Word Processor J. For one thing, like my PS Technical WP, the user was responsible for all horizontal spacing, e.g., inserting spaces around the + in a + b. In contrast, TeX usually chooses the ideal spacing automatically for you.

 

In the early 1990’s, people at Microsoft realized that the EQ field wasn’t very good typographically and it was really hard to edit, partly because it didn’t have WYSIWYG editing. And so they contracted with Design Science to ship the Equation Editor with Office. And later on, Word 2007 shipped its own fine math facility. So you’d think the EQ field would be long lost and forgotten.

 

Nevertheless three uses of the EQ field persist to this day: the East Asian formatting constructs that Word calls "phonetic guide", "combine", and "enclose". This post discusses how these constructs are created using the Word EQ field using the function \o(<this>,<that>), which displays <this> over <that>. The major difference between the three constructs is the displacement of the <this> relative to the <that>.

 

Consider first the phonetic guide, which is often call ruby. This displays a ruby text annotation (<ruby>) in a smaller type size above, below, or to the side of a base text (<base>). The ruby text is used to clarify the base text in some way, typically how the base text is pronounced. When Japanese text is displayed from left to right (instead of vertically), the ruby text is displayed above or below the base text. The ruby text can have various justifications. Back in 1996 or so when Word added the ruby feature, the developers realized they could get the old EQ facility to do a fairly reasonable job. Specifically the EQ field contains the information

 

\* jcN \* "Font:MS Mincho" \* hpsN \o\ad(\s\upN(<ruby>),<base>)

 

Here the N of the jcN switch specifies the kind of ruby justification as defined in the table

 

N

Meaning

0

Center <ruby> with respect to <base>

1

Distribute difference in space between longer and shorter text in the latter, evenly between each character

2

Distribute difference in space between longer and shorter text in the latter using a ratio of 1:2:1 which corresponds to lead : inter-character : end

3

Align <ruby> with the left of <base>

4

Align <ruby> with the right of <base>

5

Display <ruby> vertically to the right of <base>, regardless of the <base> alignment

 

The \* "Font:..." specifies the font and the \* hpsN specifies the number of half points to use for the ruby text size. The \ad switch for the \o function says to use the distributed justification defined by the jcN entry (I think). The \s\upN(...) is the EQ shift function that shifts its argument up if the \upN switch is used and down if the \doN switch is used. Here N is the number of points to shift. Note that (half) points don’t scale with the text size.

 

An interesting note is that starting with Word 2000, the ruby construct is displayed by a special LineServices ruby handler. It was this handler that I started with when I wrote a preliminary math handler for LineServices. Basically I figured that the ruby construct was just a mathematical fraction in disguise and naturally my RichEdit/LineServices implementation of ruby could nest ruby structures as deeply as desired, just as one may nest fractions deeply in a continued-fraction expression. In fact, part of the HTML ruby standard allows ruby text to appear above and below the base text, and this is most easily accomplished by using one ruby construct as the <base> of another.

 

Onto the East Asian formatting constructs that Word calls "combine", and "enclose". For "combine", the characters to be combined are split into two groups, <above> and <below>. The corresponding Word EQ field contains

\o(\s\up6(<above>),\s\do2(<below>))

where the font size is chosen to be 6 pts (\fs12). This construct displays <above> over <below>, sort of the way ruby displays <ruby> over <base>, but for "combine", <above> isn’t shifted up so far and <below> is shifted down a bit. As for the ruby construct, since the shifts are in points, the "combine" structure doesn’t scale with text size correctly.

For the "enclose" construct that looks like Ⓠ, the EQ field can contain

\o\ac(\uc0\u9675,Q)

where 967510 = 25CB16, i.e., a white circle. Here \ac switch means center align one argument over the other (note that there’s no \s() object) and we include \uc0 to get rid of the multibyte translation that would otherwise follow \u9675.

When encoding these EQ fields in RTF, one has to duplicate every backslash, so that the backslash is taken literally instead of the start of a control word. For example, the "enclose" EQ field above could be represented by the RTF

{\field{\*\fldinst EQ \\o\\ac(\\fs24\\uc0\\u9675,\\fs16 Q)}{\fldrslt}}

 

This structure also doesn’t scale with font size, since the white circle and the Q have to have appropriate relative font sizes. Also EQ fields always have a null field result (empty \fldrslt), so if a reader of the RTF doesn’t understand the EQ \fldinst, it displays nothing for the field.

 

You can see from this that Word needs a better way to represent these three East Asian formatting constructs, a way that is compatible with the past and allows proper scaling with text size. An appropriate way to accomplish these things is to use a format that allows older readers to use the current EQ field approach and newer ones to use a proper description of the constructs. Two other East Asian formatting constructs, two-in-one (Warichu) and horizontal in vertical (tatenakayoko) cannot be rendered with the EQ field. They were first implemented in Word 2000, which used dedicated LineServices handlers and represented them with dedicated RTF control words. They do scale correctly with text size.

Comments

  • Anonymous
    February 19, 2008
    PingBack from http://www.biosensorab.org/2008/02/19/word-eq-field-and-east-asian-formatting/

  • Anonymous
    February 19, 2008
    The comment has been removed

  • Anonymous
    February 20, 2008
    Unfortunately, there's a horrible design flaw with EQ: it requires the user's regional settings to a specific setting. Not the document's language, the user's regional settings! So on my Dutch XP with Dutch regional settings, o(a,b) comes out as "a,b". For (most) European regional settings, it should be o(a;b). But that means that an American reading the same Word document sees "a;b". Ack!

  • Anonymous
    February 22, 2008
    I'd like to do Ruby text with WPF, is there a straight-forward way to do this?

  • Anonymous
    March 14, 2008
    The comment has been removed

  • Anonymous
    February 21, 2012
    I've met the same problem as Nikos. Is there any way to change the font in EQ Field?