ligproc.dll is a Framemaker filter designed to do two types of typographical tasks, both automating the user of "expert" and "SC/OSF" fonts: * add and remove ligatures * convert digits to "old-style figures" and back * make systematic adjustment to the heights of characters * set Y kerning in a character format (intended to allow height adjustments if characters in variables, e.g. lowering the / in dates) * move the last character in the line slightly out into the right margin. This is typically done with punctuation, to produce an optically more even right margin. This program does not solve the problem that Windows can't access the fi and fl ligatures in a normal font on Windows. It works with the usual Framemaker font representation, which is limited to the Windows character set on Windows. However if you have a font with ligature (e.g. a "expert" set), this program lets you insert ligatures from that font automatically. Note that this substitution can result in odd hyphenation. Thus there is a command to review all words with ligatures that have been hyphenated. (I was unable to think of a way to automate fixing up bad cases. The API for writing plugins doesn't give access to the dictionary, so I can't find out what hyphenation is legitimate. Fortunately there are normally a small enough number of these that it's practical to look at them by hand. Something like a quarter of the hyphenated words with ligatures turned out to have bogus hyphenation, so you really do want to do this.) The most difficult issue is hanging punctuation. Doing this adjustment may cause hyphenation to change. For a few lines (like 5 in a 90-page document), reducing the width of the hyphen, comma, or period changes the place where the line breaks. In that case you may end up with a thin hyphen, comma, etc, in the middle of the line. In a few places this may be OK. If it isn't you're going to have to repair the damage by hand, typically by changing the hyphenation parameters of that paragraph (in the "advanced" paragraph properties). I suggest slightly raising or lowering the minimum word spacing, depending upon what you are trying to do. I recommend doing this only at the very last stage of producing your document. I suggest saving a copy before you do these substitutions, in case you have further editing to do on the document. You'll want to edit the version before these changes, since you may find it hard to remember exactly what you had to change. To aid in reviewing and fixing the line ends, there are several commands: convert end of lines - change the last characters as specified in ligatures.conf. This is the main command for doing the right margin alignment convert next end of line - starts from the selection/insertion point, looking for the first line that would be changed by the convert end of lines. Does just that one line. Moves the insertion point to that end of line. WARNING: When the insertion point is right at an end of line, Framemaker displays it at the start of the next line. This is quite counterintuitive. (The problem is that the actual end of line is regarded as zero-width in the API. Hence placing the point at the end of line is equivalent to putting it at the start of the next line.) restore end of lines - undoes the change to the whole document. I.e. replaces all occurences of the alternate font with the main font. It does this whether the font occurs at the end of line or not, since characters may have gotten moved in rehyphenation. restore end of line in selection - as above, but just for the selection. This turned up a bug in Framemaker. In a few cases the internal functions return an invalid selection. This seems to happen when your selection ends on a hyphen. The hyphen isn't a real character for the API, although it is in the GUI. Thus if you select it, the API gets confused. Because of this problem I check the selection very carefully, giving a warning if it's invalid. Normally you'll fix the problem is you end the selection with the character before the hyphen. That's OK, because the hyphen takes its font from the character before it, so that's the one that actually gets changed. find next end of line needing conversion. Finds the next end of line that would be changed by the conversion. This is the end of line that would be changed if you did convert next end of line (usually -- find next will go into tables, etc, convert next will not). As above: WARNING: this cursor will look like it's at the start of the next line, even though it is actually at the end of the previous one. Normally I first do convert end of lines. Then I use "find next end of line needing conversion" multiple times. When done just after "convert end of lines" it will show you all lines whose breaks are changed by the process of doing hanging punctuation. You should consider whether you want to change them or not. Make sure you have enabled viewing of text symbols. Adjusting the end of line creates a marker, so if text symbols are on, you can see more clearly where the adjustments have been done. The whole process for final review of a document can get slightly hairy. It's something like If you're done ligatures and end of line processing before, * remove ligatures * restore end of lines However it's safest always to start from a draft that hasn't had this done. * add ligatures * convert end of lines * use find next end of line needing conversion to see whether there is any repair needed * use find hyphenated ligatures to see whether the ligature replacement ended up with hyphenation in any invalid locations. (The hyphenation dictionary won't know about words with ligatures substituted, so you can get bad hyphenation) * look through the document for any pages where a word was hyphenated across a page break. There's no way to tell Framemaker not to do this. Once you're used to it, this only takes a few minutes, even for a fairly long document. But it sure would be nice for this to be more automated. I've considered moving to InDesign, but it still doesn't seem to be complete enough. (I'll try again when InDesign 2 is released.) Since you're going to use them repeatedly, I'd put "find next end of line needing conversion" and "find hyphenated ligatures" on the main toolbar. See below. TO INSTALL 1) copy ligproc.dll into Framemaker's structure somewhere. I put it in the filters subdirectory, but I think fminit may be more common 2) add a line to maker.ini, e.g. Ligatures=Standard,Ligatures, filters\ligproc.dll * Ligatures before the = defines the name of the client. This is used to build the name of the config file. Use whatever you like. Just make sure the config file name is consistent. * Ligatures after the = is a description that will appear when you use About. It doesn't need to be the same as what is before the =. * filters\ligproc.dll should be the filename you choose 3) If you work with long documents, consider adding a button for the command to find hyphenated words with ligatures. That will speed up reviewing the whole document. To do this, edit fminit\fmtoolbr.ini. You can add the icon whereever you like. I put it on the end of the first line of icons. To do so, at the end of the entries for [TbFirstPage], right before [TbSecondPage], add the following: 23=SEPERATOR, 5 24=ICON , ToolBar1Find , FindLigHyph 25=ICON , ToolBar1Find , FindEOL 26=ICON , ToolBar2Properties , CharacterFormatDesigner 27=ICON , ToolBar2Properties , ParagraphFormatDesigner There's no specific icon for these commands, so I've just used the icon for find. Note that it really is spelled SEPERATOR. This step is optional. You may choose not to do it until you've had some experience with the program. I'd make sure to save a copy of the original fmtoolbr.ini before modifying it. 4) Create a configuration file. It is called xxx.conf, where xxx is the name you use before the = in the maker.ini line. In the example above, it would be filters\Ligatures.conf. It goes in the same directory as the DLL file. (There's an API function that asks where the DLL file was loaded from. I use that to build the file name.) Here's an example config file: L JansonText-Roman ffi JansonText-Expert Y L JansonText-Roman ffl JansonText-Expert Z L JansonText-Roman ff JansonText-Expert V L JansonText-Roman fi JansonText-Expert W L JansonText-Roman fl JansonText-Expert X L JansonText-Roman fj JansonText-Expert [ O JansonText-Roman/n JansonText-Expert/n E JansonText-Roman -20.10,10 Y MinionProSC-Capt/n / -.08 y sclowered -.08 Items are separated by exactly one blank. Don't add extra blanks or leading or trailing blanks. Lines starting with L define ligatures. Lines starting with O define OSF (old-style figure) mappings. The first line: L JansonText-Roman ffi JansonText-Expert Y means: If you see the sequence ffi in Postscript font named JansonText-Roman, replace it with Y in the font JansonText-Expert. (Y could be a sequence too.) It is perfectly legitimate for the font names to be the same. While it's unusual, there are a few fonts where ligatures are placed in the main font in positions that are accessible under Windows. The line O JansonText-Roman/n JansonText-Expert/n means: If you see a digit in Postscript font JansonText-Roman, convert it to the font JansonText-Expert (which presumably will have old style figures). However do it only for text with normal capitalization. I.e. not for text with all-caps or all-lowercase properties. The same restriction is present if you ask to remove the changes. The line E JansonText-Roman -20.10,10 means: If the last character in a line is in the font JansonText-Roman, adjust it if it is hyphenated or ends in period or comma. Use the number after the character that is matched. It's a percent of an em by which you should move into the margin. E.g. if the line is hyphenated, move 20% of an em into the margin. The numbers will need to be larger for larger characters. The line Y MinionProSC-Capt/n / -.08 means If you see a / in Postscript font MinionProSC-Capt, lower it by .08 em. Only do this for text with normal capitalization. The line y sclowered -.08 means If there is a character format "sclowered" defined, change the KernY property so that chracters to which the format applies are lowered by .08 em. The format is not reapplied to characters that currently have it. However this feature is intended primarily for use in variables. Variables will be recomputed, so the change takes effect immediately there. You'll want to use the ATM user interface or the utility fontview to find the Postscript names of the fonts. It is also possible to use Truetype fonts. However for them you will need to use the "platform name", quoted, e.g. "W.Arial.R.400" fi "W.ArialExpert.R.400" W (This is hypothetical. As far as I know, there is no expert font for Arial.) The presence of the "" tells the program that you have specified a platform name rather than a Postscript name. (Some platform names have spaces in them.) Getting the proper platform name isn't easy. The simplest approach is to save your file in MIF format, and look for the FPlatformName property there. It is valid for both font names to be the same, in case the ligatures are present in the main font with a character code that Windows can access. USAGE This program adds several items to the Edit menu: add and remove ligatures, convert to and from old-style figures convert and restore end of lines apply and remove Y adjustments fixup character format definitions find words with ligatures that have been hyphenated convert lines one at a time, moving the cursor to them. They work on all flows in the current document. (The logic is based on Adobe's word count sample from the FM 6.0 FDK. I trust it has been updated to handle books properly.) However they do not apply to text generated by variables or crossreferences. Sorry. Add ligatures does all the replacements specified in the configuration file. It displays a count of the number of replacements done. Remove ligatures does the replacements in reverse. If the mappings are unique, this replaces the ligatures with the original text. Convert to old-style figures replaces all figures as specified. Convert from old-style figures does the replacement in reverse. Convert end of lines extends all lines into the margin, when they end in a character defined in an E line. Typically these include hyphens and a few other punctuation characters. Restore end of lines undoes "convert end of lines." Apply Y adjustments raises or lowers all characters in fonts as specified. This is intended primarily for non-alphabetic characters that need to be raised for certain fonts. E.g. / is often positioned for upper-case characters, and needs to be lowered in a font that uses text figures. - often needs to be raised for use with upper-case characters. The can be done automatically if you use different fonts for upper-case text (e.g. if you use an OSF font normally and the base font only for upper-case text). Remove Y adjustments removes the adjustments just described. Fixup character formats fixes a defect in the Framemaker user interface: Character formats can specify X and Y position shifts. I don't see any use for a uniform X shift, but a uniform Y shift can be used to define a format that raises or lowers characters. The are situations such as variable definitions where you can specify a character format name, but you can't manually adjust character positions. For example, in many fonts with text figures a date like 1/23/45 will look odd, because the / is too high. You can fix this in the main text with the generic Y adjustment feature described above. However that feature will not work in variables or cross-references. But you can define a character format "lowered", and use it in the variable definition to lower the /. Anyway, the defect in the GUI is that there's no way to set the X and Y position shifts. That is, the feature is there, but there's no way to use it. The character format dialog box doesn't have any place for you to specify position shifts. So you should use the character format dialog box to define a format, and then use the "fixup character formats" command to add the Y position shift to the format. Once you've got a character format that includes a position shift, you can apply it using the character format menu. Warning: I'm referring to the separate menu that you bring up by hitting the little "f" icon at the upper right of the screen. Choosing the format in the character format dialog and hitting "apply" doesn't apply the position shift. This sounds like a bug to me -- it looks like a feature that was only half implemented. Find words that have ligatures and have been automatically hyphenated is necessary because the hyphenation code often does a bad job with words that have ligatures. The ligatures typically look like random capital letters. (E.g. in most fonts, the "fi" ligature is a "W" in the "expert" font.) The ligature code will treat it as the capital letter. For some reason that seems to result in bogus hyphenation. Before printing a final draft, I suggest looking at all the words with ligatures that were hyphenated. If you find any bad hyphenation, you can use the spelling checker to add the right hypenation. E.g. suppose it hypenates "different" improperly. You would go into the spell checker, and look up "different". It would show as "dif-fer-ent", which shows where hyphens are legal when there aren't any ligatures. Change that to "diVer-ent", and hit "learn." V represents the "ff" ligature in most expert fonts. You'll need to force rehyphenation of the current word. The easiest way is to remove and put back the space before the word. There should be no danger of collision with normal words, since (except in Klingon) you won't find capital letters in the middle of words. The hyphenation dictionary appears to be case-sensitive. I recommend doing a remove ligatures before spell checking, since otherwise the spell checker will see ligatures as misspellings. You probably also want to remove ligatures before saving as HTML, since normally HTML documents don't assume that the user has an expert font. I can't quite come up with a need for undoing old-style figures. The command is there just for completeness. Think carefully about the implications before using it. Before printing a final draft I recommend - remove ligatures - add ligatures - restore end of lines - convert end of lines - use "find hyphenated ligatures" and make sure there is no bad hyphenation - use "find first end of line" to see whether any of the end of line changes are unstable. It shouldn't find anything. If it does, the end of line adjustments changed the hyphenation of the paragraph. You're likely to have to do something about that paragraph manually, e.g. move some or all of it back to the normal font. The ligature replacement actually depends upon line breaks. E.g. if you have the word "official" with "of-" at the end of one line and "ficial" at the beginning of the next, the "fi" will turn into a ligature, but you won't get the "ffi" ligature. In the course of editing, it's possible that the line break will change. E.g. you might now have "official" all on the same line. If you remove ligatures and add them again, you'll get the "ffi" ligature, as appropriate. If you don't do this, you'll still have just the "fi". In a 100 page document using all 5 Latin "f" ligatures I have only 9 hyphenated words with ligatures, so checking them seems practical. Whenever you run one of these commands, the program starts by seeing whether the configuration file has changed. If so, it throws away the existing data structures and rereads the file. NOTE ON CAPITALIZATION When you specify a font, you can optionally include a restriction on capitalization. JansonText-Regular/n will match only text using the font JansonText-Regular, with normal capitalization. After the slash you can put one or more of the following n - normal u - forced uppercase l - forced lowercase s - simulated small caps These refer to capitalization attributes as set in the character or paragraph format menus. That is /u matches text in a format that has the uppercase attribute set. It does match capital letters in normal text. Here's the problem: Text figures are appropriate for normal text, but not for titles in all caps. Thus we want to restrict the replacement so that figures aren't turned into text figures in these titles. For the L and O commands, putting a qualifier on the second font name restricts the "remove" command. Here's the problem: Normally text figures are in the "expert" or "SC/OSF" font. But you also use that font for headings in small caps. When you ask to remove the OSF translation, you want to undo translations done by the add OSF command. If we don't restrict it, any digits in small caps titles would get affected as well. I believe that normally you will want to use /n after both font names in an O line. Probably you won't normally need it for the L line, unless you're doing something odd. There are similar issues with the Y specification. This is intended to let you lower / or raise -, etc. In most fonts / is defined appropriately for uppercase text. It's a bit too high for normal text, particularly if you're using text figures. So you can ask for /'s to be lowered. But only only want to lower them in normal text, not in uppercase titles. Thus I recommend using something like the following: Y JansonText/n / -.08 Y JansonTextSC/nl / -.08 This lowers it for normal text, and for the small caps font. The small caps font uses /nl because small caps headings are often forced into lowercase. On the other hand, you might well want something like Y JansonText/u - .08 This raises the hyphen, but only in all-caps text. In many fonts that's a good idea. It is valid to give different specifications with the same font but different restrictions. CAVEATS 1) For any font, list the most specific mappings first. If you do ff before ffi, you'll never find ffi, since the ff transformation will happen first. (Actually the program constructs a tree. It doesn't actually do every line as a separate test. However for each font it should preserve the order of tests, roughly. The main issue would be if not all your ligatures start with f. In that case a separate set of tests is used for each starting letter. I think in practice this is OK.) 2) If you plan to undo the ligatures (and you'll probably need to), make sure that the mappings are unique in both directions. I.e. you wouldn't want to map two different normal fonts into the same expert font. When I have both a normal and OSF font, I map just the OSF font, since that's what I use for normal text. That lets me use the normal font in case I ever need to protect something from having ligatures inserted. In theory mapping to different fonts into the same expert font might work, as long as the fonts are consistent. E.g. suppose you did JansonText-Roman fi JansonText-Expert W JansonTextOSF-Roman fi JansonText-Expert W "fi" in both the normal and OSF font would turn into the same thing. But when you go back, both would end up in the regular font (since it is listed first). Since the f and i are the probably the same in regular and OSF fonts, this isn't a disaster. But it could produce unexpected font changes. 3) The program disables pair kerning for the letter following the ligature. Here's why: Suppose you've got the sequence "fic". This will turn into "Wc" with W in the expert font. If we didn't do something, Framemaker would kern this under the assumption that it's an actual W. Commonly Wc is given negative kerning. So the c would get moved on top of the fi ligature. Yuck. There's sort of a problem when removing the ligature. We normally want to put back the kerning. But we've lost the original setting of the kerning for the c. I reset it to whatever the kerning was for the "fi" originally. This is just fine as long as you don't change pair kerning inside words. E.g. if you had "fiction" and originally kerning was different for the fi and the c, the difference would get lost. This seems like a really unlikely situation. 4) No change is made to instances of variables and crossreferences. Framemaker assumes it owns this text. If I make changes, very odd results can occur. 5) I have only tried it on Windows. It will probably work on Unix, if you build the source with the Unix FDK. Whether it works on the Mac depends upon what the Mac C compilers look like. If they emulate POSIX as well as the Microsoft C compiler on Windows, you'll be OK. 6) I have no idea what would happen in FM+SGML. 7) In theory the add and remove commands are supposed to exactly reverse each other. This will only be true if the fonts are unique. There's more likely to be trouble with the command to undo old-style figures. If you use the expert or SC/OSF font yourself, digits in those areas are likely to get put back to the main font. If you're lucky, proper use of capitalization qualifiers will fix this.