ere are other, better defined, cases of ligatures between
base characters and diacritics in other scripts, i.e. cases where there
is an optional alternative to base character plus diacritic which does
not look like the base character plus the diacritic. Candidates like ø
as an alternative for ö a
On Tue, Jun 11, 2013 at 08:09:31PM -0700, Stephan Stiller wrote:
> Hi,
>
> How is the placement of vowel marks around ligatures handled in Arabic text?
OpenType has special support for placing non combining marks over
ligatures (a subset of the general support for controlling the pla
On Tue, 11 Jun 2013 20:09:31 -0700
Stephan Stiller wrote:
> Hi,
>
> How is the placement of vowel marks around ligatures handled in
> Arabic text?
For OpenType the clue lies in the three types of GPOS
(http://www.microsoft.com/typography/otspec/gpos.htm) lookup for marks
- mark t
Thank you, خالد and Richard.
there is only one Indic mark I can think of for which
the issue of component association arises, and that is the nukta
That is good to know, given the complexity of the Indic scripts.
Other thoughts:
* One could simply break up Arabic ligatures in need of
On Tue, 11 Jun 2013, Stephan Stiller wrote:
> How is the placement of vowel marks around ligatures
> handled in Arabic text?
>
> I'm also wondering how font designers normally handle this.
Older fonts in older operating systems (like Windows XP)
often failed. See
http://www
On Wed, 12 Jun 2013, Richard Wordingham wrote:
> While the same principle applies to Indic scripts (and indeed, to the
> Roman alphabet), there is only one Indic mark I can think of for which
> the issue of component association arises, and that is the nukta.
Sanskrit requires "candrabindu" U+090
Andreas
Have you tried Mihail Bayaryn's Siddhanta font - (or his earlier
Chandas and Uttara fonts)?
http://svayambhava.org/index.php/en/fonts
This font supports many more vertical ligatures for Sanskrit than most
other Devanagri fonts.
- Chris
On 13/06/2013, Andreas Prilop wrote:
>
Please see this page: (for IE, use v 2010 and up)
http://lovatasinhala.com/
The font is almost all ligatures. If you copy and inspect the text, you'll
notice that it is simple romanized Singhala. I am currently in Sri Lanka
demonstrating this. The people at president's office and
Unicode at present has some ligature characters and also a long s on its own
and the German Eszett character.
The long s on its own is encoded in Unicode as U+017F and the Eszett as
U+00DF.
Unicode currently has the ligatures ff, fi, fl, ffi, ffl, long s t and st at
U+FB00 through to U+FB06
At 11:21 7/6/2002, John M. Fiscella wrote:
>This is the first time I have seen an intelligent proposal as to the role
>and application of the ZWJ and ZWNJ in non-Arabic scripts. But one problem
>comes to mind, however. What if a font not having the ZWJ or ZWNJ is used
>in an attempt to render the
At 16:11 7/6/2002, John M. Fiscella wrote:
>You're right. PS Type 1 does not usually pose a problem (because,
>traditionally, the .notdef glyph is usually defined by just about every
>font-making program as: /.notdef 9 RD ND)
>
>But the killers are TrueType fonts, where, if the .notdef is not def
On Saturday, July 6, 2002, at 04:11 PM, John Hudson wrote:
> There are going to be documents containing this character -- and ZWNJ --
> and fonts that do not contain these characters may display them with
> .notdef glyphs. The only solution is system or application intelligence
> that is able
olarship, e.g. document studies,
in which the appearance of texts is germane to the content of studies. I
fully expect that the number of fonts suitable for such scholarship --
using the feature and containing ligatures appropriate to rendering
specific texts -- will be limited; indeed, in many c
germane to the content of studies.
OK. Here we go again. There is simply no way that one can 'typographically'
ligate standard German without text (!) based control, since places where
ligatures are prohibited depend on the meaning (i.e. intended content) of
the text, in a way that's
At 01:20 09/07/2002, Asmus Freytag wrote:
>OK. Here we go again. There is simply no way that one can
>'typographically' ligate standard German without text (!) based control,
>since places where ligatures are prohibited depend on the meaning (i.e.
>intended content)
At 09:23 AM 7/9/02 -0700, John Hudson wrote:
>It seems to me that what German typesetting needs is a way to link
>dictionary support to layout features, so that this stuff can be handled
>automatically. I'm not a programmer, so I can't imagine how difficult this
>is going to be.
in that sense
John Hudson scripsit:
> I'm well aware of the particular needs of ligation in German, but I don't
> think using ZWJ/ZWNJ in the text string is a good solution. Are you really
> expecting German users to type in this way? What are the expectations of
> German spellchecking, sorting anfd searchi
o consider other languages. Saying that the
>ZWJ causes Arabic to ligate would not be correct.
I'm deliberately trying not to consider *any* specific languages, but to
define a general proposal for rendering ZWJ sequences *as* ligatures when
appropriate ligatures are available in a
The mechanism proposed by John to handle ZWJ/ZWNJ makes the implicit assumption
that those characters are transformed into glyphs (via the usual 'cmap' mechanism)
and that this is the avenue to transfer the intent of those characters to
the shaping code in the font (i.e. some kind of ligature lo
I just reread the Unicode 1.0 standard on ZWNJ and ZWJ (p77), and it
seems very similar to the the 3.2 explanation (although not as
detailed). Am correct in thinking that the intents are the same, except
may be for Indic scripts, or is there some other difference I did not spot?
Eric.
I wonder if language/writing system-dependent control isn't appropriate in
the case of German as well as, e.g., Turkish. For instance, in an OT font,
have default lookups to form ligatures, and then have rules specific to
German, just as one would for Turkish, that do not form liguatures
7;typographically'
> >ligate standard German without text (!) based control...
>
>I wonder if language/writing system-dependent control isn't appropriate in
>the case of German as well as, e.g., Turkish. For instance, in an OT font,
>have default lookups to form ligature
On 07/18/2002 12:33:21 AM Asmus Freytag wrote:
>> The German
>>support in the font could still include the rlig lookups John has
>>suggested; and an intelligent app might even activate ligatures
>>automatically (like the SHY analogy Asmus mentioned) either by setting
user that doesn't know to enter any control characters? (Let's suppose that
a font can have German-specific rules, but not the software.) Would you
rather have ligatures appear everywhere they would if English (say) had
been assumed, resulting in ligatures in inappropriate places, or w
> I wonder if there are other, better defined, cases of ligatures between
> base characters and diacritics in other scripts, i.e. cases where there
> is an optional alternative to base character plus diacritic which does
> not look like the base character plus the diacritic.
vowels.
We should probably be careful to distinguish between ligation explicitly
requested in text using ZWJ -- which is very much a minority case -- and
ligation that occurs as either default rendering or as the result of a
higher level font feature request. There are lots of ligatures of bases
Philippe Verdy schreef:
> 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.
>
> Thi
> "Philippe" == Philippe Verdy <[EMAIL PROTECTED]> writes:
Philippe> But if one wants to restore the preious visual behavior,
Philippe> even if it's incorrect for languages using this digraph as a
Philippe> letter, what would be the behavior of using the following
Philippe> sequence:
Philippe
I think the answer is, regarding the soft dot property, please leave
the ij ligature alone.
--
Michael Everson * * Everson Typography * * http://www.evertype.com
uage has no dotless-i.
>
> Just browsed some old book with that in mind and I cannot really
> corroborate. I've even seen some other more exotic ligatures, such as
> "st" and "ct".
>
> Maybe there was such a reccomendation in some portugguese type-setti
Philippe Verdy posted:
In French typography, we also find the special ligatures for the French
(and Roman Latin) word "et" (means "and"), using old alternate forms for
the lowercase letter "e", looking mostly like a Greek epsilon (or the Latin
Small Open E, stil
- Original Message -
From: "Jim Allan" <[EMAIL PROTECTED]>
> See http://www.adobe.com/type/topics/theampersand.html for a short
> history of the ampersand and some of its variations in modern computer
> fonts.
Whole article (17 pages) about ampersand ligature in French (and other
langu
Jim Allan scripsit:
> What this doesn't indicate is that sometimes in medieval text the
> ampersand ligature is used to spell _et_ as part of a longer word.
Not just mediaeval text; "&c." for "etc." (= "et cetera") was common
right through the 19th century if not later.
--
John Cowan [EMAIL
Jim Allan scripsit:
> See http://www.adobe.com/type/topics/theampersand.html for a short
> history of the ampersand and some of its variations in modern computer
> fonts.
Unfortunately the explanation of the name "ampersand" given there
is exactly backwards: it is not "& per se and", but "and
hen
> drawing a solidus over it.
All this discussion shows that there is an extremely large number of
glyph variation for the ampersand which is both (at the abstract level)
a symbol character, and a ligature of two lowercase abstract
characters. But ligatures for the uppercase "ET"
At 01:21 -0400 2003-07-13, John Cowan wrote:
I hand-write & by making a tall lower-case epsilon glyph and then drawing
a solidus over it.
I just use the TIRONIAN SIGN ET.
--
Michael Everson * * Everson Typography * * http://www.evertype.com
> "John" == John Cowan <[EMAIL PROTECTED]> writes:
John> Not just mediaeval text; "&c." for "etc." (= "et cetera") was
John> common right through the 19th century if not later.
And picked up steam again online in the 1980s; groups.google.com
should have lots of examples of "&c".
-JimC
Michael Everson scripsit:
> >I hand-write & by making a tall lower-case epsilon glyph and then drawing
> >a solidus over it.
>
> I just use the TIRONIAN SIGN ET.
A good choice if you don't slash your DIGIT SEVENs and can make your
DIGIT ONEs sufficiently distinct.
--
Dream projects long deferr
John Cowan posted:
Not just mediaeval text; "&c." for "etc." (= "et cetera") was common
right through the 19th century if not later.
The combination _&c_ is still used. Search for "&c" in
http://www.scotland.gov.uk/consultations/environment/tacnh-00.asp for
example.
But in mentioning medieval
At 14:09 -0400 2003-07-13, John Cowan wrote:
Michael Everson scripsit:
>I hand-write & by making a tall lower-case epsilon glyph and then drawing
>a solidus over it.
I just use the TIRONIAN SIGN ET.
A good choice if you don't slash your DIGIT SEVENs and can make your
DIGIT ONEs sufficiently dis
Michael Everson scripsit:
> >A good choice if you don't slash your DIGIT SEVENs and can make your
> >DIGIT ONEs sufficiently distinct.
>
> Eh? I *do* slash my DIGITs SEVEN and I use a single vertical stroke
> from my DIGITs ONE. The TIRONIAN SIGN ET as used in Ireland has no
> horizontal stroke
At 16:21 -0400 2003-07-13, John Cowan wrote:
I should have said "do slash your DIGIT SEVENs". So the glyph in the
Unicode 3.0 book is not typical of Irish practice? It seems to have a
horizontal stroke all right.
It is utterly typical of Irish practice. I meant that it doesn't have
an additiona
Philippe Verdy wrote:
> All this discussion shows that there is an extremely large number of
> glyph variation for the ampersand which is both (at the abstract
> level) a symbol character, and a ligature of two lowercase abstract
> characters. But ligatures for the uppercase "
On Sunday, July 13, 2003 10:21 PM, John Cowan <[EMAIL PROTECTED]> wrote:
> Michael Everson scripsit:
>
> > > A good choice if you don't slash your DIGIT SEVENs and can make
> > > your DIGIT ONEs sufficiently distinct.
> >
> > Eh? I *do* slash my DIGITs SEVEN and I use a single vertical stroke
>
At 09:19 +0100 2002-05-25, William Overington wrote:
>This list, the code points being entirely the choice of the present author,
>is published by the present author.
I take this to mean: "I am publishing this list and the choices for
the code points are mine."
--
ME
ght have any
knowledge of what was the situation in olden days when long s characters
were widely in use in relation to languages where there is today an accent
on a letter s. Did accented long s characters exist, and did accented long
s ligatures exist please, or were the accents disregarded or
e voice.
William: If you have something to say, try to say it in plain
English. Use short sentences. Avoid needless words.
And *listen* to people on this list if they say you come up with an
idea which is a waste of time. Ligatures are meant to be encoded in
the font. You can use ZWJ to inv
e is as follows.
>
>http://www.waldenfont.com/public/gbpmanual.pdf
>
>On page 14 are some special characters, ligatures and abbreviations, as
used
>by Gutenberg.
>
>Searching through the table is great fun so I will only mention here the
>first entry in the table which shows a letter
script, for each style of each script, for each local
typographic tradition for each style, and so on.
And once you start down that road -- as John Hudson pointed out --
you would quickly find that the problem is not one of
"enumerating the list of required ligatures", but is rather
more
Thank you for your comments.
I am not going to attempt to produce the list of ligatures myself.
I am writing the paper to draw attention to the problem which exists in
relation to the DVB-MHP (Digital Video Broadcasting - Multimedia Home
Platform) system of interactive broadcasting and its
mbinations of
consonant+vowel, and a table of the essential consonant clusters, and of
half or subjoined consonants. If you compare the grammars of languages
sharing the same script (such as Sanskrit, Hindi, and Marathi, all written
with the Devanagari script), you can verify how the list of required
On Monday, June 30, 2003 1:58 PM, Pim Blokland <[EMAIL PROTECTED]> wrote:
> Philippe Verdy schreef:
>
> > 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 appli
On Monday, June 30, 2003 9:13 PM, James H. Cloos Jr. <[EMAIL PROTECTED]> wrote:
> So if you want two dots and an acute use ‹ij, U+0308, U+0301›: ij̈́
>
> Of course a given font’s diaeresis will often not line up with the
> stems of its ij, and a custom one should be used instead. Or
> features an
> > I don't know of any instances where a ij digraph would keep the dots
> > AND get additional accent marks, nor of any where the ij would
> > appear with a dotless i and dotless j and a single dot above,
> > centered between them. Can you give examples?
>
> No of course:
So why do you care?
>
ll other cases, the ligature should be avoided, simply because
there are other better choices with /// and
//, in combination with double diacritics
inserted between them to produce the desired effect.
In either cases, the "Soft_Dotted" property is probably overkill on
the existing or
Michael Everson schreef:
> I think the answer is, regarding the soft dot property, please
leave
> the ij ligature alone.
And I think not.
When putting accents on the ij (which does happen!), the dots must
go. Simple as that.
Maybe it was a bad idea to include ij as a character in Unicode at
all, bu
needed for correct Dutch support. Look at the case
conversion of into , even with titlecase...
The character itself is not breakable in Dutch where it is definitely
not a ligature, but a single character, with its own case conversion
rule, exactly like the and letters (considered as
ligatures
Philippe Verdy wrote:
>> Maybe it was a bad idea to include ij as a character in Unicode at
>> all, but now it's there, there's no reason to ignore it when
>> refining the rules, to deprecate it practically.
>
> No, that was needed for correct Dutch support. Look at the case
> conversion of into
one. It could have been: none; like for the oe and ae ligatures.
This is in contrast to the MICRO SIGN which ideally should have had
a canonical decomposition; but Latin-1 characters got special treatment
(and ASCII characters have even more special treatment in this regard,
where some spa
> In either cases, the "Soft_Dotted" property is probably overkill on
> the existing or ligatures (should should have been better
There is no point in having a soft-dotted property for the capital
letter...
> named "letters" and not "ligatures") f
Kent Karlsson wrote:
>> Believe it or not, the IJ and ij digraphs *were* included for
>> compatibility with an 8-bit legacy character set (ISO 6937).
>
> 6937 is a multibyte encoding (one or two bytes per character).
> There are no combining characters at all in 6937, even though
> there is a com
Following on from the publication of the document "Some Private Use Area
code points for ligatures." one correspondent has asked me to include an ffj
ligature. There was also a suggestion that as there is an ff ligature, any
f ligature should probably also be accompanied by a corres
resting, as the fact that your system was set up for
> ConScript and Doug wrote using a character from what is now called
> the golden ligatures collection provides a good practical example of
> the need for the use of the classification codes which I suggested
> some time ago.
>
&g
Philipp Reichmuth wrote:
> Is there a standard way to handle ZWJ/ZWNJ in sorting & searching?
> I think in quite a lot of situations and/or scripts it would be
> feasible just to ignore ZWJ (or give the user the choice to ignore
> it). Especially in a Latin context.
I would ignore ZWJ, ZWNJ, an
> U+E707 for the ct ligature.
Well, you probably could have guessed on your own what belongs between
"Respe" and "fully". :-)
> This is interesting, as the fact that your system was set up for
> ConScript and Doug wrote using a character from what is now called
>
Doug Ewell wrote,
> Philipp Reichmuth wrote:
>
> > Is there a standard way to handle ZWJ/ZWNJ in sorting & searching?
> > I think in quite a lot of situations and/or scripts it would be
> > feasible just to ignore ZWJ (or give the user the choice to ignore
> > it). Especially in a Latin contex
should go down in Unicode
history as "The Respectfully Experiment".
William published a list of code points for ligatures. Quite independently
of each other, James used the list to add a code point for a ct ligature
into his fount, Doug used the list to include a code point for a ct liga
A bunch of side notes for William.
From: "William Overington" <[EMAIL PROTECTED]>
> William published a list of code points for ligatures.
In academia, speaking of oneself in third person may be expected at times.
Here on the Unicode List, its basically pretentious.
&g
William Overington
wrote:
> I feel that what happened is very interesting and should go down in
> Unicode history as "The Respectfully Experiment".
>
> William published a list of code points for ligatures. Quite
> independently of each other, James used the list to ad
William Overington wrote this:
WO> I then formatted the text in PowerPoint to 200 points, italic and
WO> green.
WO> So, it appears that SC UniPad used in conjunction with Word and
WO> PowerPoint can be used to prepare elegant presentations in the
WO> languages of the world. Wow!
And this:
WO>
>From the "oops" file...
A few days ago I replied to William Overington:
>> I have also analysed the other black rectangle which appears in your
>> posting by the same process. It comes out as decimal 9785 which
>> converts to hexadecimal 2639 which, upon looking in the code charts,
>> gives a v
OWING LIGATURE
The idea is as follows.
Firstly, the background. In the light of The Respectfully Experiment, in
the way that Mr James Kass utilised the golden ligatures collection code for
a ct ligature, U+E707, to designate, within a fount which he himself
authors, the glyph for a ct ligature wh
Please find attached a .gif file showing the way that the U+E707 code
displayed when I received it here in England, using Outlook Express upon a
Windows 95 platform. This is as a contribution to the documentation of The
Respectfully Experiment for the Unicode archive.
The golden ligatures
At 14:39 +0100 2002-08-14, William Overington wrote:
>Suggestions for other ligatures and abbreviations to add into the
>golden ligatures collection are also welcome.
I suggest you stop calling it the "golden ligatures collection". This
term imputes a status and nobility to it
Michael Everson wrote in response to William Overington,
>
> I suggest you stop calling it the "golden ligatures collection". This
> term imputes a status and nobility to it which it simply doesn't
> have. Indeed, I suggest that you abandon this task and use
>
At 12:07 -0700 2002-08-14, James Kass wrote:
>Michael Everson wrote in response to William Overington,
>
>>
>> I suggest you stop calling it the "golden ligatures collection". This
>> term imputes a status and nobility to it which it simply doesn't
>&
Michael Everson wrote,
> >Appropriate font technology for Latin ligature display exists,
> >but it isn't enabled yet in Microsoft's Uniscribe.*
>
> That doesn't mean that this particular cataloguing of ligatures in
> the PUA is a good idea.
>
> >
John Hudson wrote as follows.
>Here's an exercise for your enthusiasm, William: devise the form of the
>perfect .notdef glyph. It needs to unambiguously indicate that a glyph is
>missing, i.e. it should be something that can easily be mistaken for a
>dingbat, and it needs to be easy to spot in pro
At 11:24 +0100 2002-05-30, William Overington wrote:
>I am also having a look at the idea of having code points for the famous
>combination border of the type used by Robert Granjon in the sixteenth
>century.
Code points are assigned to characters. Even in the PUA, it would be
advisable to keep
ny list of ligatures you define, I can design
additional ligatures. There are more type designers working in the world
today than at any time in history. What you are attempting to define is,
effectively, an open set, and deciding to provide PUA codepoints only for
'traditional' ligatur
John,
> You are trying to find a solution to a problem that has already
> been solved in a better way, and in the process you will create
> more problems for anyone who uses your solution. So give it
> up already.
I will buy a drink for whoever can truly make William understand this point
so tha
Michael Everson wrote as follows.
>At 11:24 +0100 2002-05-30, William Overington wrote:
>
>>I am also having a look at the idea of having code points for the famous
>>combination border of the type used by Robert Granjon in the sixteenth
>>century.
>
>Code points are assigned to characters. Even
At 01:01 5/31/2002, William Overington wrote:
> >>I am also having a look at the idea of having code points for the famous
> >>combination border of the type used by Robert Granjon in the sixteenth
> >>century.
To which Michael Everson replied:
> >Code points are assigned to characters. Even in
John H. Jenkins wrote,
> I must point out that for English (and a lot of other languages), the use
> of ZWJ to control ligation is considered improper. The ZWJ technique for
> requesting ligatures is intended to be limited to cases where the word is
> spelled incorrectly if *
At 11:34 -0600 2002-06-30, John H. Jenkins wrote:
>
>Remember, Unicode is aiming at encoding *plain text*. For the bulk
>of Latin-based languages, ligation control is simply not a matter of
>*plain text*-that is, the message is still perfectly correct whether
>ligatures are on
On Sunday, June 30, 2002, at 05:31 AM, James Kass wrote:
> Can you please point me to a URL for Unicode 3.2 ligature control?
> This link (March 2002):
> http://www.unicode.org/unicode/reports/tr28/
> ...glosses over Latin ligatures suggesting that mark-up should be
> used in som
xisting tables where "f+i"
is already present.
Another problem with TR28 is that its date is earlier than the date
on TR27. This suggests that TR27 is more current.
Another issue is that a search of the Unicode site for "controlling
ligatures" gives TR27 as a hit, but not TR28
one, are still valid. In TR27, font developers are
> urged to add things like "f+ZWJ+i" to existing tables where "f+i"
> is already present.
>
And for the record, Apple is doing that.
> Another problem with TR28 is that its date is earlier than the date
> on
At 11:34 AM 6/30/02 -0600, John H. Jenkins wrote:
>Remember, Unicode is aiming at encoding *plain text*. For the bulk of
>Latin-based languages, ligation control is simply not a matter of *plain
>text*that is, the message is still perfectly correct whether ligatures
>are on or
at is, the message is still perfectly correct whether ligatures
>> are on or off. There are some exceptional cases. The ZWJ/ZWNJ is
>> available for such exceptional cases.
>
> Remember also that the simplistic model you present already breaks down
> for German, since th
ate notice. That documentation was rolled forward
into UAX #27 (Unicode 3.1), where it was explicitly cast as text
to replace the Unicode 3.0 text on p. 318 re Controlling Ligatures,
including an update of the example table. The additional text in
UAX #28 is just that -- an *addition* to the Unicode 3.1 text,
n
At 14:31 6/30/2002, James Kass wrote:
>Sounds like a giant step backwards from Unicode 3.0.1 (March 2002)
>http://www.unicode.org/unicode/standard/versions/Unicode3.0.1.html
>(see section "Controlling Ligatures")
>
>This page clearly states that ZWJ is proper for cont
relegated to *plain* text.
>
>Therefore, I would be much happier if the discussion of the 'standard'
>case wasn't as anglo-centric and allowed more directly for the fact that
>while fonts are in control of what ligatures are provided, layout engines
>may be in control
s in the font, and to just use f l if it doesn't. Some
fonts will be able to display the ligature, others won't. For "p ZWJ q"
every font will just display p q. That's completely consistent with
both the wording and the intent of ligation-by-ZWJ.
There's nothi
At 19:53 +0300 2002-07-04, John Hudson wrote:
>Well, we need and have (in OpenType and AAT) a general purpose
>mechanism for typesetting texts employing ligatures as deemed fit by
>the professional typographer. The expectation of such a mechanism is
>that layout is applied to
that while fonts are in control of what ligatures
> are provided, layout engines may be in control of what and how
> many optional ligatures to use, the text (!) must be in control of
> where ligatures are mandatory or prohibited.
Well stated.
Perhaps the best 'higher level p
e font?
> The implication of what you're saying is that Latin typefaces should be
> *required* to have a "ct" ligature on the off chance that the author of
> text determines that it's "required" in a particular context. That gives
> most type designers th
Kenneth Whistler wrote,
>
> > Another problem with TR28 is that its date is earlier than the date
> > on TR27. This suggests that TR27 is more current.
>
> I don't understand this claim.
>
After misreading the dates and writing the letter last Monday,
the internet connection was lost here f
All your other good points noted:
At 02:57 PM 7/1/02 -0600, John H. Jenkins wrote:
>>Therefore, I would be much happier if the discussion of the 'standard'
>>case wasn't as anglo-centric and allowed more directly for the fact that
>>while fonts are in contr
sociated with different
>orthographic systems. Unfortunately, the German rules really require
>dictionary support to be properly implemented, since the rules for
>word-internal ligature use/prohibition are intimately linked to spelling
>and cannot be algorithmically arrived at.
Once you
201 - 300 of 316 matches
Mail list logo
