karl@haddock.ima.isc.com (Karl Heuer) (09/04/89)
I need to be able to print text containing certain accented letters which are
not present in the builtin fonts. I've read through some back issues of c.l.p
that I was foresighted enough to save, and studied the appropriate sections in
the red and blue books. It appears that there are several solutions, none of
which I find entirely satisfactory. Perhaps someone (Glenn?) could suggest
the "right" way to do this.
The books talk about two kinds of font tweaking. Remapping the Encoding
vector isn't useful for this purpose, because the composite characters I need
aren't already defined. So it seems I have to create a user-defined font.
(a) I can make a font containing *only* the new characters, and just switch
fonts whenever I print an accented letter. This seems less elegant than
building a single font with the complete alphabet. But this is how the blue
book example does it (the font containing box and bullets), so maybe it's the
approved solution.
(b) I can easily add my accented characters by extending BuildChar, *if* I can
first create a user-defined font which is functionally identical to the
original builtin font. One way to do this is to let my new font defer to the
existing font to do the dirty work; i.e. I can have my BuildChar do a setfont
and a show. Wilfried Soeker used this approach in his article last February.
(c) I can attempt to construct what BuildChar would look like it it existed in
a builtin font. Except for the missing setcachedevice, I think that would be
{ exch begin Encoding exch get CharStrings exch get end exec }
, right? Is it legal to directly execute the procedure from CharStrings?
Now in cases (b) and (c), to get full benefit of font cacheing I should call
setcachedevice with the width and bbox information. How should I go about
obtaining those values? Are they stored in some user-visible place from which
I can copy them, or would I have to use `charpath flattenpath pathbbox' and
`stringwidth'? If the latter, should I put this code right into BuildChar, or
preconstruct a table?
Karl Heuer karl@haddock.ima.isc.com rutgers!harvard!ima!haddock!karllee@uhccux.uhcc.hawaii.edu (Greg Lee) (09/05/89)
From article <14510@haddock.ima.isc.com>, by karl@haddock.ima.isc.com (Karl Heuer): " I need to be able to print text containing certain accented letters which are " not present in the builtin fonts. " (b) I can easily add my accented characters by extending BuildChar, *if* I can " first create a user-defined font which is functionally identical to the " original builtin font. One way to do this is to let my new font defer to the " existing font to do the dirty work; i.e. I can have my BuildChar do a setfont " and a show. Wilfried Soeker used this approach in his article last February. Soeker has the remark in his code that the underlying characters, the basic character and the diacritic, will be cached, so maybe that will make it fast enough. I have a first draft done of a system, based on Soeker's approach, which constructs Microsoft Word initialization files with diacriticked fonts prepared from a specification file. The spec file lists the two characters to be combined with the font position they are to occupy, and optionally a model to follow for positioning the diacritic. In the latter case, the model character+diacritic combination is looked up in the afm file to determine where to move the diacritic; otherwise an approximation is made based on bounding box info for the two characters in the afm file. Two problems with this approach: if one includes all the fonts normally handled by MS Word, the postscrp.ini file becomes very bulky (with all those tables). And I don't think there's a real good way to calculate diacritic position for slanted fonts. Also, my version doesn't yet give access to characters not in the Adobe standard encoding. Does anyone know whether it's ok to distribute the MS Word initialization files? There's no copyright notice on them. Greg, lee@uhccux.uhcc.hawaii.edu Here's what the spec file looks like: ----------- Diacritic'd characters for Marshallese Introduction ------------ This file will be used to prepare tables for use in a modified MS Word initialization file for PostScript. The principle table determines what characters will be printed as a combination of a letter and a diacritic. Lines in this file of the form <letter-name> <diacritic-name> at <number> cause entries to be made in this "Accenttable". In this form of statement, <letter-name> is the PostScript name of a letter, such as M or ampersand, <diacritic-name> is the PostScript name of a diacritic letter, such as acute or cedilla, and <number> is an integer from 0 to 255 in decimal notation. The <number> gives the font position or character number that will be used in Word, and the two names give the two letter forms that will be combined to create the composite letter to be printed for this font position. The names must name PostScript letters that are encoded in the PS standard encoding. The <diacritic-name> must be one of the following: quoteright slash bar quotesingle quotedblleft grave acute circumflex tilde macron breve dotaccent dieresis ring cedilla hungarumlaut ogonek caron emdash hyphen The two names may optionally be separated by spaces or tabs. Spaces or tabs at the beginning of an entry are also optional. Lines in this file of the form <letter-name> at <number> are also recognized and are used to change the font position of a letter from its default location in Word. (used to be C cedilla at 128) O cedilla at 128 align like C cedilla (used to be u dieresis at 129) u macron at 129 align like u dieresis (used to be acute at 130) m cedilla at 130 align like C cedilla (used to be a circumflex at 131) a dieresis at 131 (used to be a dieresis at 132) a macron at 132 align like a tilde a grave at 133 (used to be a ring at 134) [rest omitted]