GreekKeys Unicode 2005/2008: Troubleshooting and FAQ for Mac OS X users
Known problems and workarounds for GreekKeys 2008
Typing with Multiple Inputs in Mac OS X
Long-time Mac users may be familiar with two keyboard shortcuts that have traditionally worked for the Keyboard or Input Menu: these were command-spacebar and option-command-spacebar. From 10.4 onward Apple has used these familiar keys as the defaults for invoking Spotlight and left the shortcuts for the Input Menu deactivated. If you are already used to using command-spacebar and option-command-spacebar with the Input Menu, then I recommend changing the Spotlight shortcuts (for instance, to control-spacebar and option-control-spacebar) and activating the familiar ones for the Input Menu. If you are not already habituated to those shortcuts, then you can assign any keys you want. To make adjustments to such keyboard shortcuts, use System Preferences:Keyboard & Mouse:Keyboard Shortcuts.
With Unicode input, you must remember to change the input from GreekKeys Unicode back to US (or French, or German, or whatever) every time you come to the end of a section of Greek font. If you fail to do so, you cannot simply change the font to fix your error, you must retype the mistaken portion. Toggling keyboards is a one-command process. If you have just two inputs activated, or GreekKeys Unicode and your national input are the two you have most recently used, then command-spacebar (or whatever you have assigned to "Select the previous input source" in the Keyboard Shortcuts pane of Keyboard & Mouse System Preference) will alternate between those two. If you have more than two keyboards activated, you may sometimes have to use command-option-spacebar (or whatever you have assigned to "Select the next input source in the Input menu" in the Keyboard Shortcuts pane of Keyboard & Mouse System Preference) repeatedly to move through the sequence of all available inputs. (You may of course instead use the mouse to select the input in the input menu, but this is inefficient in any extensive word-processing.)
The easiest setup for typing mixed Roman and Greek with distinct fonts is to create keyboard shortcuts in MS Word for your chosen Roman font and for your chosen Unicode Greek font. (Use the Customize Toolbars/Menus… command under Tools, and click on the Keyboard… button to set up your own commands.) Then you will have a two-command sequence to use at each transition from Roman typing to Greek typing: one for changing the input and one for changing the font. Some users report that they accomplish both commands with a single keyboard shortcut through a third-party program like QuickKeys, but compatibility with GreekKeys 2008 has not been tested and is not guaranteed.
GreekKeys Unicode FAQ
Versions of GreekKeys and Intel-based Mac compatibility:
Converting from traditional GreekKeys fonts to Unicode Greek fonts and back again:
Using GreekKeys Unicode with applications:
GreekKeys 2008 for Mac OS X continues to work properly in Word 2011, although there is a bug that may cause minor annoyance (or worse, for some users) and the support for OpenType ligatures has been modified. (Separate from issues connected to GreekKeys, there are other bugs and features in Word 2011 that may degrade usability or disturb the user's long-established work habits.)
First, with Word 2011, as with earlier versions, many fonts are installed. (1) More fonts have polytonic Greek support. (2) Palatino Linotype is now included: this font is extremely popular among users of Word for Windows, but previously was not supplied to Mac users. One item of bad news: after installation you need to open Font Book and search out the duplicate fonts and carefully determine which items are the newest and make sure they are activated and the older versions are disabled. This is laborious because when fonts occur in the four styles (regular, italic, bold, bold italic), it is usually the case that some of these styles have the older version active and some have the newer version active. (For some guidance how to locate duplicates and disable older versions, see the details in the latter part of the next FAQ.)
Second, OpenType ligature support has been removed from documents in the .doc format (these had such support in Word 2008). If you want OpenType ligatures (such as dotted characters with the dot centered properly under letters of different widths), you now have to save the document in the .docx format.
A welcome feature is that you can apply bold and italic styles to the ligatures in the GreekKeys fonts, even those these are supplied only in the regular style. (Some other programs will not apply bold or italic style unless a separate font of that style is supplied.) You still need to activate ligature support. The easiest thing to so is open Word Preferences, select the Ribbon pane, and check the box before Typography: this will make the ligature settings accessible from the Ribbon.
The center of the Ribbon after Typography is displayed:
Activating ligatures on the Ribbon Typography section:
The bug that affects working in Word 2011 involves using keyboard shortcuts for basic tasks while the GreekKeys Unicode input is activated. Command-b (toggle bold), command-i (toggle italic), command-j (justify paragraph), command-l (flush left paragraph), command-r (flush right paragraph), command-t (tailing indent), command-u (toggle underline), and command-w (close) do not work, but instead insert the roman character into the document. On the other hand, fortunately, command-o (open), command-n (new document), command-s (save), command-p (print), command-q (quit), command-c (copy), command-v (paste), command-x (cut), command-z (undo), command-y (repeat), command-a (select all), command-f (find), and command-m (minimize) all work. Originally this problem affected Apple’s Greek Polytonic input and some other Apple inputs as well, but the problem disappeared for them with the release of Service Pack 1 for Office 2011. It still exists for GreekKeys Unicode, however. I have verified with Apple that the GreekKeys Unicode input is correctly formed, and that is why it has always worked in other programs and in Word 2008 and even in Excel 2011 and PowerPoint 2011. So it is mysterious why the problem has not disappeared with SP 1. If you are heavy user of keyboard shortcuts, you will need to unlearn some habits, or revert to Word 2008.
Presumably a further manifestation of the same bug is another very troublesome fault in Word 2011. If you have clumsy fingers and follow the option-key combination for an accent with a letter that cannot take the accent, what should happen is that you see the accent as a spacing character and then the letter you typed by mistake (and you then can backspace twice and correct your mistake). What (usually or always) happens in Word 2011 is that Word triggers some command related to hidden text (characters with dotted underline) and insertion of characters from the memory buffer. When you backspace, you may actually see more text than before (garbled sequences of what you have recently typed). To recover from this problem you need carefully to select from the end of the problematic series of characters back to the character before you made a mistake in keying and delete that selection. This will get rid of whatever in the text file was triggering the bad behavior.
Finally, for those who are using Word 2011 under Lion (Mac OS 10.7.x), there is another troubling bug related to keyboard commands. I do not believe this occurs with Word 2011 under Snow Leopard (Mac OS 10.6.x), but I am not quite certain about that. When using the shortcut command-z to undo a mistake (such as after using one of the problem commands listed above and seeing an unwanted roman character in the text), I have occasionally found that the document will suddenly scroll back to the beginning (as if the home key had been pressed) and, what is worse, a large number of recent changes to the document will no longer be visible (as if some kind of Revert command had been issued). This doesn't actually mean that you have lost as much work as appears. If you save the document under another name (like "junk.docx") and close it, you can then reopen the document you were working on, and you should find that most of the changes you had made before the incident (possibly all of them) are present and visible. After this happened a few times when I was working on a very complex document that compiles collations of scholia, I returned to working in Word 2008, where none of these problems occurs.
Mac OS X Leopard (10.5.x), released in late October 2007, had some rocky features, but after the 10.5.2 update (released Feb. 11, 2008) should provide a generally stable and pleasant working environment. The Keyboard Viewer in 10.5.0 and 10.5.1 does not display SMP (5-digit) Unicode code points. This fault has been corrected in 10.5.2.
The standard installation of 10.5 brings with it a number of upgraded fonts that include polytonic Greek (Arial, Tahoma, Courier New, Times New Roman among them) and also Arial Unicode, a very full Unicode font that is found on many Windows machines. This makes cross-platform sharing of Word files with polytonic Greek Unicode much easier.
Microsoft Office 2008 was released on January 15, 2008. The news is good is that Microsoft's Mac Business Unit has finally done some of the upgrading of features that should have occurred years ago.
Installing Microsoft Word 2008 may, unfortunately, install inferior versions of some of the fonts already provided by Apple (inferior in that they do not include all the polytonic Greek characters), and if installed later than Leopard itself, the inferior fonts may be activated. In this case, you will need to activate the fuller versions again. The proper way to do this is with FontBook.app (in the Applications folder).
Both the GreekKeys Unicode inputs and the older Traditional GreekKeys keyboard resources work normally in OS X version 10.4.x and 10.5.x, whether the processor is Intel or PowerPC. Fonts also behave the same, whether the processor is PowerPC or Intel.
One error in the 2005 inputs has been corrected in 2008 (for iota with macron and circumflex), and the input files have been normalized so that the deadkeys are correctly indicated in the Keyboard Viewer palette.
Two minor errors discovered after the completion of GreekKeys 2005 in November 2004 are addressed in the disk and disk image GreekKeys 2005.01 of January 16, 2005. First, the inputs have been revised so that the < and > keys input U+27e8 instead of U+2329 for left angle bracket and U+27e9 instead of U+232a for right angle bracket. The replaced code points are identical in appearance in New Athena Unicode font. The code points used before are unlikely to cause trouble to users of GreekKeys, but are best avoided because of canonical equivalence with code points in Chinese/Japanese/Korean. Second, the four dot punctuation U+2058 in New Athena Unicode v. 2.1 has been corrected: it had the dots in a square, but they are supposed to be in a diamond pattern. Minor adjustments have been made to the documentation to reflect these corrections.
Version 2 includes more keyboard assignments than the 1.x versions (including for some of the metrical symbols), includes more localizations for European keyboards, includes fuller documentation, and comes with GreekKeys Symbol input (for a full range of metrical symbols and other useful characters approved for Unicode 4.1). Version two also follows the recommendation of the Unicode Technical Committee that the vowels with tonos (in the Greek block) be used for both modern and ancient Greek and that use of the corresponding vowels with oxia in the Greek Extended block be discontinued. So, for example, whereas alpha with acute was input as U+1f71 in v. 1.x, from version 2.0 onward alpha and acute is input as U+03ac. In addition, where version 1.x dealt with some combinations by inputting the decomposed code points (such as alpha with macron + combining smooth breathing + combining acute accent), version 2 inputs a PUA (Private Use Area) code point for a precomposed character. That is, version 1.x relied on the ability of an application to read a specific table in the font New Athena Unicode [and very few applications did this], whereas version 2 relies on the use of a font that contains a particular scheme of PUA assignments (which New Athena Unicode v. 2 shares with some other fonts produced by classicists).
GreekKeys Unicode inputs work in Mac OS X version 10.2 or higher (Jaguar, Panther, Tiger, Leopard). The installer supplied with GreekKeys 2008, however, is designed for version 10.3 and higher and may not work in 10.2. No one should any longer be using any version of OS X earlier than 10.2.
GreekKeys 2008 requires the use of a standard OS X installer, and there is no direct support for manual installation. Instructions for running the installer are in the Quickstart and User's Guide PDFs that come with the package, and are also given on another page of this site.
The inputs and their associated icons are stored in a file (actually a special kind of folder) named "GKUall.bundle." This file is installed in the Keyboard Layouts folder in the top-level Library folder of any startup disk or partition, and the inputs are thus available to all users on that disk or partition. If there is some reason to restrict the availability of the inputs to a particular user on a multi-user machine, the file "GKUall.bundle" should be moved from /Library/Keyboard Layouts to username/Library/Keyboard Layouts, and then the computer should be restarted. Similarly, once you have an accessible copy of "GKUall.bundle" you could place a copy manually in a Keyboard Layouts folder.
After the bundle file is in placed, follow the steps for activation.
Instructions for activation are in the Quickstart and User's Guide PDFs that come with the package, and are also given on another page of this site.
Word X is not capable of using Unicode input. You must upgrade to Word 2004 or 2008 to start to use Unicode input and fonts, unless you decide to use a different word processor. For information on which applications support polytonic Greek Unicode, see the compatibility page.
I installed GreekKeys Unicode and/or GreekKeys Universal, activated them in the International Input Menu pane. When I switch to a GreekKeys input, I see the proper icon for Greek input, but what I type still comes out as ordinary English typing.
If this happens with GreekKeys Universal, make sure that you are using a traditional GreekKeys-encoded font. If you use a font with Unicode or standard Mac Western Roman encoding, you will see only Roman characters.
The diagnosis is different if this occurs with GreekKeys Unicode input. By an OS X bug which crops up very rarely, it may happen that the synchronization between the icon displayed for the selected input in the Input Menu does not correspond to the input that is actually still being used by the system. As a result, you think you should be typing Greek, but you get normal Roman characters instead. For a few users this bug has been very persistent, but in most cases I have heard of, the situation can be fixed.
First, the quickest solution may be simply to restart your computer. Possibly when you restart, the system will have recovered its bearings about which input is active.
Second, if that does not work, then the following steps in most cases will set things right again:
Third, anyone who is comfortable using the command-line in /Applications/Utilities/Terminal could aim for the same effect as the steps in the previous method by restoring the defaults (under which only one input is active) with the following command:
The incremental Software Updates within the series 10.4.x or 10.5.x do not affect the GreekKeys Unicode input if it was already installed. Installation of a major upgrade, as from 10.4 to 10.5 may require reinstallation of GreekKeys Unicode, depending on what kind of installation you did for GreekKeys Unicode and which options you select in the OS X upgrade.
[NOTE: This does not apply to GreekKey 2008.] I just downloaded the file "GreekKeys2005.01.dmg.sit" from the sales site, but it won't open when double-clicked, and the system does not know what application to use. What's wrong?
The default installation of Tiger and Leopard [=Mac OS 10.4.x and 10.5.x] (unlike earlier versions of OS X) does not include support for decompressing a Stuffit archive (.sit). The download of GreekKeys2005.01.dmg is compressed as a Stuffit archive to save bandwidth, as required by the sales site. Therefore, if you download the .sit and cannot convert it to the .dmg file, you will need to install Stuffit Expander as part of the free download package of Stuffit for Mac OS X. Two sites with links that will get you to the download are
Yes, I recommend the use of the separate shareware program GreekKeysConverter, not part of the APA software package. For more details, see the conversion page.
Yes, I recommend the use of the separate shareware program GreekKeysConverter, not part of the APA software package. For more details, see the conversion page.
See the separate compatibility page.
This is a result of confusions created by the piecemeal treatment of Greek script in the development of the Unicode standard and the mistake of some font designers in taking the sample glyphs in Unicode charts as prescriptive. Since the official release of GreekKeys Unicode inputs 2.0 with GreekKeys 2005, GreekKeys has followed the recommendation of the Unicode Technical Committee that where there are duplicates in Unicode, the code point in the Greek block should be used and the code point in the GreekExtended block should be avoided. GreekKeys fonts have always used identical characters in the duplicate positions, but some fonts make a distinction. As fonts are revised, such distinctions are fortunately disappearing. For more on this problem, see the technical details page.
If you are typing in a font which does not contain the character that you are trying to input, the OS will automatically seek out another font that does contain the needed character. At present, there are only some system fonts that contain Greek Extended characters needed for polytonic Greek (most system fonts contain the characters for monotonic Greek). The newer your system software, the more fonts supplied by the system or by an application (such as MS Office) will have the polytonic Greek characters.
For example, if you are typing in Times (in 10.3 or 10.2) and switch to GreekKeys Unicode input and fail to change the font, some characters may be available in Times, but when a character lacking in Times is typed, the font will change automatically (usually to Lucida Grande). If you have 10.4 or higher, you do not see this problem with Times, because the font has been expanded. You will see it, however, with Times New Roman, even as late as the version in MS Office 2008, since this font lacks the polytonic characters.
Some specialized characters in later versions of Unicode (such as special punctuation at U+2310 and following) are sometimes badly handled in Word 2008 (whereas competently programmed applications have no trouble with them). The problem may affect papyrologists and palaeographers and those using certain transliteration schemes (such as Demotic Egyptian or Arabic). The problem appears inconsistently, since it apparently does not affect a .doc that was first saved in Word 2004 and then edited with Word 2008, but rather a .doc that is first created in Word 2008. Here are the steps to try to work around this problem. (1) In some cases, simply by selecting the unwanted font and reapplying New Athena Unicode to the selection, you can get the character you want. (2) If that does not work, a workaround is to copy the character from a keyboard chart document (or another document in which the character appears) and to paste it in, specifying to keep source formatting. (3) If that fails, then there is a more elaborate workaround. Download here a document named 2e17workaround.doc. It was created with Word 2004, which does not show the same problem. Open this document with Word 2008. Check whether you can type U+2e17 in this document. Then copy the entire content of the document that has been troublesome and paste it into this document, then save it under a new name. You should now be able to type and paste U+2e17 in the new document.
There has been a report of this problem with the French version of Word 2004. (I have not heard of or seen the problem in the US version.) This happens with any Unicode Greek font. The problem turns out to be the spellcheck setting: the French version of Word 2004 seems not to know what to do when it meets Greek characters. So the workaround is to turn off automatic spellchecking. Open Preferences, choose Spelling and Grammar, and uncheck "Check spelling while you type" as well as "Check grammar while you type" and "Check grammar with spelling."
This appears to a bug (or a deliberately crippled feature) in PowerPoint 2004, making it less capable in polytonic Unicode Greek than Word 2004 and Excel 2004. The characters from the GreekExtended range default to Lucida Grande and cannot be changed to Times, Helvetica, New Athena Unicode, or other appropriate fonts. PowerPoint 2008 does not have this limitation. The workarounds in PowerPoint 20004 are: (1) use Lucida Grande for all your Greek; (2) use traditional GreekKeys fonts instead; (3) if the Greek is limited, use an image; (4) if the Greek is more extensive, prepare a PDF from Word and insert it in the PowerPoint slide.
Strictly speaking, it is not necessary to change fonts when you transition from Greek to Roman typing or vice versa, if you are using a Unicode font that contains a large range of Roman characters as well as all the Greek characters you need. (And it is likely that as time goes by more and more standard fonts supplied with the operating system will contain the Unicode standard characters of the Greek and Coptic and the Greek Extended blocks.) But if you are preparing a work for publication in a journal or by a press, of if your work contains very frequent alternation of Greek and roman fonts (as in a commentary), it may not be a good idea to use a single font. In the final production, the press may want all the English to be in a particular Roman font and all the Greek to be in a particular Greek font, and global replacement of one or both types of font is very easy in Microsoft Word (and other programs) as long as the Greek and Roman are in distinct fonts. If you use one font, it will require advanced searching with regular expression terms, and this will be more time-consuming and far more complex. And even if you can do that, catching all the punctuation within the Greek to make it consistent with the Greek font adjacent to it will be a major headache in an extensive document.
For small documents for everyday use, however, such as handouts for classes, it may be perfectly fine to use a single font, if you have one you like. Please note that New Athena Unicode contains Roman characters, but it is not a professional font and little attention has been paid to making these characters harmonious with the Greek characters. For a professional appearance, you will probably not want to type your Roman font text in New Athena Unicode.
As of 2008, all current browsers (and for reasons of security one should use only current browsers, not old versions or abandoned software like Microsoft Internet Explorer 5.2) work with Unicode fonts and Unicode input. If you have GreekKeys Unicode input, you can use the Unicode input option in the TLG's search field instead of beta code.
Browsers may, on the other hand, present a rather odd mishmash of Greek fonts when Unicode Greek is displayed. Some html pages are generated without designation of a particular font or fonts for the browser to use, and in this case if the default font you have chosen for the browser does not contain all the Greek characters needed, the missing characters will be supplied from another font. Thus if your default font is Lucida Grande (or New Athena Unicode), all the Greek will be Lucida Grande (or New Athena Unicode); but if it is Times, some characters will be in Times and others in Lucida Grande or another font. Again, in the future, when more system fonts have Greek Extended added to them, such mixture of fonts in display will become much less common.
The TrueType font New Athena Unicode is made freely available by the American Philological Association to facilitate Greek on the internet. See the download page.
Because of the slow spread of support for smart fonts with ligature features, GreekKeys Unicode fonts from New Athena Unicode v.2 onward use Private Use Area (PUA) code points for some complex combinations (such a vowel with macron or breve and diacritics). The drawback of using PUA is that conflicts are possible. If a system font is present using the same code points in PUA, then OS X will take the character from that system font and not from New Athena Unicode. For a brief period and only in some installations of Panther (10.3), Apple was distributing a font that uses PUA code points that conflicted with those in GreekKeys Unicode fonts, but the font was later changed so as not to use these code points.
The conflict should disappear if you upgrade your Mac OS to a more recent version.
Before doing anything to your Panther system (again, this does not apply to Tiger or later), verify that there is a conflict and identify which font causes it. Open Character Palette, select View: Unicode, and click on Unicode Blocks. Then scroll down to the area of the table showing E1A9 (other relevant areas at EAF0, EB36, and EC00). Click on the Asian glyph in this position, and in the Font Variation section of the Palette (click the triangle to open this section if it is not shown) you will see the character and the name of the font containing it.
The font that I know to create this conflict is called LiHei Pro. (The same font in Tiger is a later version and does not produce any conflict.) The name appears thus in the Character Palette and in Font Book, but in the Fonts folder where it is located, it has two Asian characters followed by "Pro.ttf" shown as its name. Here is a picture of the name:
Follow these steps to remove the conflict.
If using FontBook does not solve the problem for you, you may also try instead to remove the font with FontBook. Since the font is in /System/Library, there may be some risk in removing it. Proceed with caution and at your own risk.
The overstroke is U+0305 and it can be entered with option-y on the GreekKeys Unicode keyboards. It should be entered after the character that you wish to mark with the overstroke. In the latest revisions of New Athena Unicode, KadmosU, AttikaU, and BosporosU fonts, the overstroke has been repositioned and lengthened to prevent intersection with a tall character and to allow strokes on two successive letters to join in most cases. Please note that the Apple fonts Times and Helvetica supplied with OS 10.4 do not behave in the same way as GreekKeys fonts and Lucida Grande font: in Times and Helvetica, the combination depends on advanced font features that MS Word 2004 is incapable of exploiting, and so in these two fonts the overstroke is shown after the letter rather than over it.
If you are using only regular style Greek (not italic or bold), then GreekKeys Unicode fonts (New Athena Unicode, AttikaU, BosporosU, KadmosU) will work fine in InDesign CS. These fonts do not, however, have separate versions for italic and bold and other styles, and InDesign insists on such additional fonts if you want to use those styles. If you import bold or italic styles from Word, InDesign will display the words as regular instead. If you try to apply bold or italic within InDesign, nothing will happen.
Perhaps at some point bold and italic versions of the fonts will be created, but so far there has not been time to do so.
Your fonts are probably actually present in the menu. The OpenType fonts AttikaU, KadmosU, and BosporosU are misclassified by Microsoft Word 2004 as Central European fonts, and the application consequently places these fonts in a separate sequence at the end of the alphabetic list of fonts. Some Adobe applications alphabetize New Athena Unicode font under Athena, ignoring the word "New".
[OBSOLETE: OTF format is not currently distributed.] Why, with the OTF fonts AttikaU, KadmosU, and BosporosU in Word 2004, do I sometimes see base double left quotes and reversed double right quote (as in some European styles) rather than the normal US left and right double quotes?
Word 2004 unfortunately does not use the most up-to-date and standards-compliant text engine and script manager available in OS X. As a result, Word 2004 may misinterpret these fonts as Central European fonts. This is why Word's Font menu buries them in a secondary sequence after the main alphabetic sequence of fonts, and this is why Word 2004 makes the incorrect assumption that you want to use the Central European style of double quotes when you use one of these fonts.
I have not been able to find a workaround for this problem. You can fix the quotes using find and replace. To create an instance of left (right) double quote, you can use the Character Palette or Unicode Hex to input 201C (201D) or with GreekKeys Unicode (US) use the keyboard combination option-apostrophe for left double quote and shift-option-apostrophe for right double quote.
Sometimes news fonts are not properly accessed by MS Word because of the font cache that Microsoft uses. In the situation described, the first solution attempted should be the removal of the font cache. For Word 2004 this is ~/Library/Preferences/Microsoft/Office Font Cache (11). For Word 2008 this is ~/Library/Preferences/Microsoft/Office 2008/Office Font Cache (12). Put the appropriate file (or both) into the Trash and restart your computer.
Firefox, even now that it has reached version 2 for Mac OS X, does not use a very good text engine. Its treatment of Unicode Greek fonts is erratic, and it works best if you stick to a system font as default. An even more serious defect is the poor interaction between the Firefox 2 clipboard and MS Word 2004. If you try to copy any extended piece of Unicode Greek text from the TLG web site and then past that clipping into a MS Word 2004 document, Word (which also has an antiquated and inferior text engine) does not even recognize that there is anything in the clipboard to insert. Oddly enough, you can work around this by pasting the passage into a TextEdit document, copying it from TextEdit, and then pasting it into Word 2004. The problem does not occur with Word 2008. The problem with Word 2004 will disappear when Firefox 3 is released.
Since Diogenes (version 3) piggybacks on Firefox, some previous versions showed the same problem, and the same workaround applied to it. But version 3.1.6 of Oct. 2007, with the underlying mechanism of Firefox 3, no longer presents this problem.
For browser display of Greek and high quality of text engine, Safari remains the best choice in Mac OS X, although in other respects, such as web site compatibility, Safari has problems that Firefox does not. The official release of Firefox 3 may change this ranking.
If a font designer wants the diacritics to be legible, they need to be of a certain size, and this often means that the vertical dimensions of the Greek characters with diacritics approach or exceed the standard height of the characters of the font. As a result, when the font is used with "single spacing," either the top of a diacritic (such as the circumflex above a breathing sign) or the bottom of a descender (or of an iota subscript) may not be displayed in full on the screen. This problem occurs particularly (but not exclusively) in Microsoft Word, and it in fact affects not just APA Greek fonts, but Apple's own Times font (Tiger version). It does not happen in a font that has ugly squashed diacritics that take very little vertical space.
Unless effort is expended on a major redesign of the font (which is unlikely), this problem will persist. It already existed with some of the traditional GreekKeys-encoded fonts. The first thing to note is that this is a screen-display problem. The characters will in fact print in full (but in some circumstances you may have the top of a character in one line overlapping the bottom of the character in the line above). The best workaround is to increase the height of the line spacing. In general, the line spacing should be at least 2 or 3 points greater than the point size of the font. Thus, with 12-point Times or KadmosU, use the Paragraph.. command under the Format menu, and on the Indents and Spacing pane, use the setting under Spacing: to choose "At least" and then change the entry (which may appear by default as "12 pt" if you are using a 12-point font) to "14 pt" or "15 pt" and click OK. In other programs you may have to find the commands or settings to make a similar line-height adjustment. On a web page you can create sufficient line-height using CSS.
This faintness is caused by antialiasing (font smoothing) and by the need for the operating system to calculate how to display the refinements of the character shapes on a relatively low-resolution device like a computer screen. It appears especially in KadmosU and BosporosU, but also in Apple's own Times font (Tiger version). This problem has to do only with screen appearance and does not affect printouts. You can sometimes improve the legibility on a flat-panel display or laptop by using the setting for CRT rather than flat-panel in the Appearance System Preference: near the bottom of the pane is the setting for Font smoothing style, and if you select "Standard - best for CRT" the legibility of the faint diacritics may improve. Another workaround is to view your text at 125% or 150% instead of 100%, because this problem appears particularly if you are viewing a relatively small font (12-point) on a relatively high-resolution monitor (1280x600 or more). The view can be adjusted using Zoom... under the View menu of MS Word or with the Zoom field in the Formatting toolbar.
The old-style PostScript font, such as Athenian or Kadmos, is limited to 256 characters, which is not enough for a Unicode font. The newer format is OpenType (.otf fonts), which can be produced with the PostScript outlines. But such fonts are not yet handled well by many applications, and there is not a compelling reason to devote time to producing separate fonts in that format.
Most, if not all, of the vertical discrepancies were corrected in version 2.2 and later. Please try the later version and see whether the result is more satisfactory.
The Roman characters with macron or breve are present in many Unicode fonts: in fact most combinations (Ā ā Ă ă Ē ē Ĕ ĕ Ī ī Ĭ ĭ Ō ō Ŏ ŏ Ū ū Ŭ ŭ) are present in a large number of system fonts; only in the case of ȳ and Ȳ is the character found in only a few fonts (like Lucida Grande and New Athena Unicode). To type these combinations, activate the US Extended input and type option-a for macron (or option-b for breve) before you type the vowel.separate page presenting technical details of GreekKeys Unicode and the APA fonts.
Unicode Hex is an all-purpose input supplied by Apple in OS 10.2 and 10.3 to allow the entry of any unicode code point in the Basic Multilingual Plane (BMP), that is, the code points that are four digits long in hexadecimal notation. When you activate this keyboard (in System Preferences: International: Input Menu), you can type basic Roman characters normally from your keyboard, or you can type any Unicode character available in any font in your system by holding down the option key while typing the four digits of the hexadecimal code. For example, if you hold option down while typing 039e, the character capital xi will appear (from the Lucida Grande font, if the character is not present in the font you currently have selected). This input cannot be used for code points in the Supplementary Multilingual Plane (SMP), which have five digits in hexadecimal notation.
Mac OS 10.4 (Tiger) and higher includes an input designed to enter polytonic Unicode Greek. It is called "Greek Polytonic" and can be turned on in the Input Sources pane of Language & Text System Preference (before 10.6, Input pane of International System Preference). The arrangement of the diacritics is like that on a manual Greek typewriter, for those who have ever used one to type polytonic Greek. Use the Keyboard Viewer Palette to see the positions of the deadkeys for diacritics. This input will not give you access to all the extras made possible by the GreekKeys Unicode inputs.
Modern OS X browsers allow Unicode input within html forms in documents that are encoded as Unicode (utf-8 encoding). This capability is found, for instance, at the TLG web site on their Unicode input search page.
When making an html document containing Unicode Greek, the charset should be set to "utf-8" and the Greek may be entered in a couple of different ways. The least cumbersome is to use an application like BBEdit 8 or Netscape Composer (possibly DreamWeaver MX, which I have not tried) that allows Unicode input: in this way you can type visible Greek into your file. The more cumbersome way is to use either decimal or hexadecimal code as shown here as an image (so it won't execute):
For problems with GreekKeys Unicode, AFTER you've used the documentation in the package and on this site, send email Donald Mastronarde at djmastronarde dot berkeley dot edu, being sure to use as your subject line "GreekKeys query." Please tell what model of Mac you are using, what OS version, what application you are using, which keyboard and which font, which version of GreekKeys, and what the problem is.