For me the OPs problem sounds as it follows:

A font as part of its data provides information about mappings of
charsets to the glyphs contained in the font. Not each such mapping can
point to all glyphs in a font. E.g. an ISO Lantin 1 mapping provided by
a font would of course only point to the glyphs in the font which are
part of ISO Latin 1. A Unicode mapping can only point to glyphs in the
font which have a place in Unicode.

Now, Unicode defines very few ligatures, much less than one would need
in serious typesetting. Fonts (apparently his fonts) can contain glyphs
for many more ligatures than Unicode knows about.

But he can't get to these additional (ligature) glyphs in the font,
because they have no Unicode code point, are therefor not in a font's
Unicode-to-glyph mapping, and are therefore not addressable by Java.
Because Java only deals with Unicode.

I just learned that (contrary to what I originally wrote) high quality
fonts even contain "glyph substitution" data. Lists which provide a
mapping of character combinations to special glyphs for these
combinations, e.g. ligatures. Java provides no API to access such lists.
And even it it would, the resulting glyph has no Unicode code point, so
could not be represented in a Java char.

So from a typesetting point of view already Java's Font API is very poor.

Hi also can't simply circumvent the Font API and somehow create his own
GlypheVector. At least not with some huge effort. From what I see, doing
this would (a) require to write an own font file reader, capable of
getting all the necessary information out of a font file, (b) a layout
algorithm to place glyph data in a GlypheVector, which (c) requires to
write an own font renderer to interpret the glyph data in a font and
convert it to Java glyph information.

I would be very surprised if you haven't seen your native language
(American English?) printed with ligatures. It is a matter of aesthetic
typesetting. High-quality newspaper, magazine or book printers for sure
use ligatures.

Do you happen to have the GoF book at hand? For example the first
paragraph of the first page (xi) of the prefix contains a ligature.
"This book assumes you are reasonably proficient ...". See the "fi" in
"proficient"? IMHO it is printed as a ligature.

There aren't any Unicode characters.

/Thomas

The problem with that is there is no protocol to ask fonts whether
they do or not have such ligatures.

[...]

The correct model is to produce a GlyphVector, which includes all the
ligatured glyph, from a sequence of logical characters, which is
entirely oblivious to ligatures.  What I lack is hooks into that
process; what you are suggesting is to munge the characters instead
which is a presumably workable hack for some cases, but see below.

I don't think it's unreasonable to want what I want, and it certainly
isn't unanticipated: the Java official documentation says: "In Figure
4-14, the custom layout algorithm replaces the fi substring with the
ligature fi."
<http://java.sun.com/j2se/1.3/docs/guide/2d/spec/j2d-fonts.fm5.html#67469>

That's what I want to do.  Write such a "custom layout algorithm".

They are essentially deprecated:

"""
The existing ligatures exist basically for compatibility and
round-tripping with non-Unicode character sets. Their use is
discouraged. No more will be encoded in any circumstances.
"""
<http://www.unicode.org/faq/ligature_digraph.html>

It's the rendering engine's job to do this stuff.
The current Java rendering engine does not do this stuff.
The current Java rendering engine does not have hooks to allow me to
do this stuff.  (Yes, I can feed it deprecated characters.  No, I'm
not going to.)

Note that some fonts have a fancy 'st' ligature which has no Unicode
codepoint and which isn't going to get one.  

There isn't just a lack of docs, there's a lack of hooks into the
character rendering pipeline.

Just to put the matter beyond reasonable doubt, though, I have decided
that the showpiece for my implementation will be the correct handling
of Fraktur writing, which has many ligatures not encoded in Unicode
code-points.  

Des

Yes, of course.

German ß is usually considered a character in its own right;
iso-latins give it its own codepoint.

Arabic isn't really that bad, if you abandon a naive belief in a 1-1
mapping of characters and glyphs.  Since I have abandoned such a
belief, I am not very intimidated.  What I am asking does indeed
amount to a recognition that proper typesetting of even English
requires comparable resources to typesetting Arabic.  But that's
because it does.

They do.  That's the point.  They already do.  Consider the following
fragment of the Abode Font Metrics (afm) file for a passing Palatino:

"""
C 102 ; WX 333 ; N f ; B 23 -3 341 728 ; L i fi ; L l fl ;
"""

This is the letter 'f', and the Ls say how it combines with 'i' and
'l' to form ligatures.  This is typical of Abode's Type 1 fonts.

No, it can be done programmatically from afm files (or equivalent data
included with, say, TrueType fonts).

That's a crossable bridge, if I come to it.

Maybe.  But at the moment the user is me, and I want them all.

I can Google up other forlorn unsuccesses with Java.  At the moment
I'm working on parsing Type 1 font afm files, and the most hospitable
framework seems to be the Gnome project's Pango, which specialises in
internationalised text and already has an Arabic shaper module.

Des