From: Kent Karlsson (kentk@cs.chalmers.se)
Date: Mon Jun 30 2003 - 07:33:54 EDT
Re. the ij ligature and soft-dottedness:
This is a compatibility letter, both in the sense that it has a
compatibility mapping
and is taken from a “legacy” character encoding. It is, however, not
necessarily a
character that should not be used. Even though in most cases it is
sufficient to use
ordinary i and j in sequence to write the Dutch ij, in some cases it may
still be best
to use the ij ligature character, for best spacing, titlecasing, and
vertical layout.
This was discussed on this list a while ago. Also discussed on this
list was the following:
The ij can in some cases be acute accented, in which case both of the
dots should
be replaced by acute accents. The representation of this is quite
straightforward if
ordinary i and j are used. If, however, the ij ligature is used, the ij
ligature must first
of all be soft-dotted. Applying just ordinary combining acute accent to
produce an
accent on each part of the ligature may be a bit strange. It may be
more logical to
apply combining double acute accent to the ij ligature to get the
desired effect. A
(small) typographic problem is to align the two acute accents over the
constituent
letter bodies. It is not certain that a grave accent may be applicable
to the ij, but
if it is, the story is similar. At least one Dutch dictionary (Ter
Laan, Niew Groninger
Wordenboek, 1929) uses a macron over the ij. If coded as separate i and
j, one would
use 035E;COMBINING DOUBLE MACRON in-between. If the ij ligature is
used, a
combining macron should be applied after the ligature character to get a
macron
that goes over both the dotless constituent letter bodies.
In each of these cases (of accented ij ligature), the ij ligature must
be soft-dotted.
> Interesting issue for the Latin Small "ij" Ligature (U+0133):
> Normally the Soft_Dotted issupposed to make disappear one dot when
> there's and additional diacritic above, but many applications may
> keep these two dots above, fitting the diacritic in the middle.
Examples? (Of actual use of such a letter+marks combination, not of
applications that currently do what you say.)
> This proposal would mean that this become illegal, and it promote the
> use of an additional intermediate dot-above diacritic if the dot must
> be kept.
>
> What would be the interpretation of this dot added on top of the
> ligature? Should it be still a single dot centered above the "ij"
Probably. Examples of use?
> digraph, requiring two dots to be encoded if both "i" and "j" must
> have their own dot above?
They would stack on top of eachother (unless you want additional
special rules, which seems very uncalled for).
> Or would this require using a diaeresis instead centered above the
> digraph?
Probably. But are there any examples of this in use (ever, not
necessarily
Unicode encoded, or at all digitally encoded)? If that kind of thing
never
has occured before, it does not really matter very much, and some coarse
approximation will do fine.
> For the modifier letter j or Greek letter yot, this is less ambiguous.
>
> The proposal however is fine for the mathematical variants of i and j,
> (including the double struck italic, for unification reasons)
I think so too (though I don't know what you mean by "unification"
here).
But there are also cases where "math" diacritics go over a larger
expression
than just a single-letter variable name (the span being expressed via
markup). It
is probably not wise to automatically remove the dots on i's and j's in
such cases.
However, for cases where a "math" diacritic goes on top of just a
single-letter
i-like or j-like name, the dot should automatically be "removed" (or,
rather,
an alternate dotless glyph be used). For other cases, like
"more-than-a-variable"
expressions getting a diacritic, or when actual undotted i or j is
desired
(compare TeXs \imath and \jmath), dotless i and dotless j characters
should
be used. (But that is another matter, though related to the soft-dotted
issue.)
/kent k
> (Note I also posted this comment in the online report form)
>
> -- Philippe.
>
>
This archive was generated by hypermail 2.1.5 : Mon Jun 30 2003 - 08:34:56 EDT