. The Wikipedia article cited as
[1] does not claim otherwise.
Amiri uses contextual alternatives for الله. These ligatures are
used in religious documents[2] via pictures, which seems to be what
the current Unicode standard recommends.
What is your source for this?
Unlike the presentation forms
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 one
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 apri...@freenet.de
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 placement
of non
On Tue, 11 Jun 2013 20:09:31 -0700
Stephan Stiller stephan.stil...@gmail.com 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
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
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.unicode.org/mail-arch
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+0901
Hi,
How is the placement of vowel marks around ligatures handled in Arabic text?
Does anyone have good pointers on this topic?
My guess is that this does not come up often (just like the topic of
pointing for handwritten Hebrew), as vowel marks are mostly not added in
ordinary text
Can you please give me a list of all the ligatures available? Thanks!
- Michael Norton (a.k.a. Flarn)
E-mail address: [EMAIL PROTECTED]
Can you please give me a list of all the ligatures available? Thanks!
- Michael Norton (a.k.a. Flarn)
E-mail address: [EMAIL PROTECTED]
I suppose one could construct such a list, but using them to encode text is a
Very Bad Idea. It is better, for example, to encode the fi ligature as the
letter f followed by the letter i and let rendering software, fonts, and so
forth provide the ligature. Encoding ligatures directly will make
Hopefully not adding 37 pages...
Michael Norton (a.k.a. Flarn) flarn2003 at megapipe dot net wrote:
Can you please give me a list of all the ligatures available? Thanks!
If by available you mean separately encoded in precomposed form, you
could start by checking the online, definitive Unicode
At 07:44 PM 11/27/2004, Doug Ewell wrote:
The problem, as Addison pointed out, is that if you use these forms in
text, most searching and sorting operations will fail to recognize them.
That's not the only problem. In some languages other ligatures, such as
fj might be as commonly needed as fi
What is the string length in semantic meaning for a ligature? For example,
when we impose a length(str) function to them?
Are all the ligatures using the same rule? Or different according to
different scipts of Arabic, Latin, Devanagari, Syriac, etc?
What else if the ligature itself has its
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
On 30/12/2003 15:44, Chris Jacobs wrote:
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
See http://www.unicode.org/versions/Unicode4.0.0/ chapter 9
Interesting. Is this actually valid at the end of a string?
Yes. Figure 9-6 is an example.
Would
syllable, virama, ZWJ as an isolated string be rendered differently
from syllable, virama?
I don't know. syllable, virama ZWJ is
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 ö are ruled out because
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.
Devangari?
Syllabe
Doug Ewell wrote:
...
My copy of Photoshop 7 has an interesting image in its (HTML format)
help file, page 1_16_4_13.html on Using ligatures and old style
numerals. It shows three examples of Type with Ligatures option
unselected and selected: ct, fi and fh.
The bad part
Doug Ewell wrote:
Anto'nio Martins-Tuva'lkin antonio at tuvalkin dot web dot pt wrote:
The bad part of it is that the ligated characters shown (in the
sencond and third examples) seem to include a long "s" instead of an
"f"... ty_06.gif attached for reference.
Thanks for
My copy of Photoshop 7 has an interesting image in its (HTML format)
help file, page 1_16_4_13.html on Using ligatures and old style
numerals. It shows three examples of «Type with Ligatures option
unselected and selected»: ct, fi and fh.
The bad part of it is that the ligated characters shown
Anto'nio Martins-Tuva'lkin antonio at tuvalkin dot web dot pt wrote:
My copy of Photoshop 7 has an interesting image in its (HTML format)
help file, page 1_16_4_13.html on Using ligatures and old style
numerals. It shows three examples of Type with Ligatures option
unselected and selected: ct
At 02:59 AM 8/26/2003, Anto'nio Martins-Tuva'lkin wrote:
My copy of Photoshop 7 has an interesting image in its (HTML format)
help file, page 1_16_4_13.html on Using ligatures and old style
numerals. It shows three examples of «Type with Ligatures option
unselected and selected»: ct, fi and fh
On 2003.07.07, 00:25, Peter Kirk [EMAIL PROTECTED] wrote:
Maybe originally U+044B (cyrillic y, yery) was two separate
letters,
It sure it (though I should provide some references to back this up? Hm,
later...)
but it is certainly considered and used as one letter in Cyrillic
languages
Phillipe wrote:
I hae tried several times to do it. It does not work: you may
effectively remove some tables your don't need, but trying
to extract just the normalizer is a real nightmare. I tried it
in the past, and abondonned: too tricky to maintain, and I
retried it recently (one month ago,
Phillipe wrote:
I hae tried several times to do it. It does not work: you may
effectively remove some tables your don't need, but trying
to extract just the normalizer is a real nightmare. I tried it
in the past, and abondonned: too tricky to maintain, and I
retried it recently (one month ago,
On 2003.07.12, 20:59, Anto'nio Martins-Tuva'lkin
[EMAIL PROTECTED] wrote:
Just browsed some old book with that in mind
I here meant rather books, plural. And I'll keep an eye for this in
the future.
-- .
António
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
from my
for Normalization.
Mark
__
http://www.macchiato.com
Eppur si muove
- Original Message -
From: Philippe Verdy [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, July 14, 2003 11:13
Subject: Re: ISO 639 duplicate codes (was: Re: Ligatures in Turkish
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 per se .
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 deferred
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 use I was
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
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.
I
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 additional
Philippe Verdy verdy_p at wanadoo dot fr 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
- Original Message -
From: Philippe Verdy [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, July 12, 2003 14:45
Subject: Re: ISO 639 duplicate codes (was: Re: Ligatures in Turkish
and Azeri, was: Accented ij ligatures)
On Saturday, July 12, 2003 4:17 PM, Jony Rosenne
[EMAIL PROTECTED
Where does the fact of saying that a Grapheme Disjoiner...
The character you should be referring to is not a new character GDJ, but
rather is the existing ZWNJ, the functions of which include prevention of
a ligature.
- Peter
On Saturday, July 12, 2003 6:51 AM, Doug Ewell [EMAIL PROTECTED] wrote:
Philippe Verdy verdy_p at wanadoo dot fr wrote:
Good luck with ISO language codes which does not even
define them, and contain many duplicate codes even in
the Alpha-2 space (he/iw, in/id), or unprecize codes
On 11/07/2003 11:18, Philippe Verdy wrote:
# T: special case for uppercase I and dotted uppercase I
#- For non-Turkic languages, this mapping is normally not used.
#- For Turkic languages (tr, az), this mapping can be used instead of the normal mapping for these characters.
snip
Is
At 03:25 -0700 2003-07-12, Peter Kirk wrote:
Does anyone know of a good resource on the web, or elsewhere,
listing the alphabets used for different languages around the world?
I know a project was attempted a few years ago at least for Europe.
It would be useful to have this kind of data
Samedi 12 juillet 6h51, Doug Ewell [EMAIL PROTECTED] crivit :
The codes iw for Hebrew and in for Indonesian were deprecated
FOURTEEN YEARS AGO. It is not accurate or fair to refer to them as
duplicates of he and id. The Registration Authority deprecates
such codes, rather than deleting
On 12/07/2003 04:18, Michael Everson wrote:
At 03:25 -0700 2003-07-12, Peter Kirk wrote:
Does anyone know of a good resource on the web, or elsewhere, listing
the alphabets used for different languages around the world? I know a
project was attempted a few years ago at least for Europe. It
At 08:11 -0400 2003-07-12, Patrick Andries wrote:
Just out of curiosity, why was « iw » deprecated ? Seems perfectly fine to
me. And why was « he » chosen (Herero, Hemba, Hellenic Greek) ?
Iwrit (iw), being a German transliteration of the name of the Hebrew
language, and Jiddisch (ji) were both
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Patrick Andries
Sent: Saturday, July 12, 2003 2:12 PM
To: Philippe Verdy; Doug Ewell
Cc: [EMAIL PROTECTED]
Subject: Re: ISO 639 duplicate codes (was: Re: Ligatures in
Turkish and Azeri, was: Accented ij
Michael Everson [EMAIL PROTECTED] écrivit :
At 08:11 -0400 2003-07-12, Patrick Andries wrote:
Just out of curiosity, why was « iw » deprecated ? Seems perfectly fine
to
me. And why was « he » chosen (Herero, Hemba, Hellenic Greek) ?
Iwrit (iw), being a German transliteration of the name of
On Saturday, July 12, 2003 4:17 PM, Jony Rosenne [EMAIL PROTECTED] wrote:
What has iw to with Hebrew?
I wasn't involved with the change, but I'm glad it was done. Java and
other systems probably still use it because they never bothered to
check the latest version of 639. I know for certain
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-setting
manual, but its result doesn't show...
In French typography, we also find the special ligatures
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, still used in Tamazigh as a letter distinct
- 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
languages)
Note also: the Soft_Dotted property was created and considered
specially for Turkish and Azeri.
Adding to the long, and unfortunately getting longer, list of misleading
statements from Philippe! No, the reason for the Soft_Dotted property
was/is to mark which characters (regardless of
. There are certainly many ways
to preserve the semantic difference in the rendered text when this
is really appropriate (for example in Turkish and Azeri, or with a
distinct and emphasized rendering of the Turkish dot, including
in possible ligatures with other letters).
FLAME-OFF
And please, do not flame me
On 11/07/2003 05:56, Philippe Verdy wrote:
Note also: the Soft_Dotted property was created and considered
specially for Turkish and Azeri.
Whatever it was that was specially created or adjusted for Turkish and
Azeri, was it specifically restricted to these two languages? These are
I
On Friday, July 11, 2003 3:50 PM, Peter Kirk [EMAIL PROTECTED] wrote:
So I hope that what is fixed by Unicode is the name not
of two languages but of an extensible family of scripts.
I think you speak about family of languages?
Good luck with ISO language codes which does not even
define them,
On 11/07/2003 08:51, Philippe Verdy wrote:
On Friday, July 11, 2003 3:50 PM, Peter Kirk [EMAIL PROTECTED] wrote:
So I hope that what is fixed by Unicode is the name not
of two languages but of an extensible family of scripts.
I think you speak about family of languages?
Not really. A set
On Friday, July 11, 2003 6:43 PM, Peter Kirk [EMAIL PROTECTED] wrote:
Agreed. But does Unicode actually treat them as non-normative samples?
Note clear here: the reference documents say that these tables are
normative for applications that want to implement a conforming
case folding. But UTR#30
Philippe Verdy verdy_p at wanadoo dot fr wrote:
Good luck with ISO language codes which does not even
define them, and contain many duplicate codes even in
the Alpha-2 space (he/iw, in/id), or unprecize codes
matching sometimes very imprecize families of languages
overlapping other language
fonts are ligating the dot with decorative
curves). These fonts are effectively not suitable for Turkish and
Azeri.
In Turkish and Azeri the sequences f - i and f - dotless i both occur,
and are fairly frequent. So it is inappropriate in these languages to
use fi ligatures in which the dot
On 10/07/2003 08:21, Philippe Verdy wrote:
In Turkish and Azeri the sequences f - i and f - dotless i both occur,
and are fairly frequent. So it is inappropriate in these languages to
use fi ligatures in which the dot on the i is lost or invisible, at
least where the second character is a dotted
On Thursday, July 10, 2003 5:41 PM, Peter Kirk [EMAIL PROTECTED] wrote:
Isn't there a Grapheme Disjoiner format control character to
force the absence of a ligature like fi, i.e. f, GDJ, i?
Maybe, but it is hardly realistic to expect all existing Turkish and
Azeri text to be recoded to
On 10/07/2003 09:34, Stefan Persson wrote:
Peter Kirk wrote:
Maybe, but it is hardly realistic to expect all existing Turkish and
Azeri text to be recoded to insert a character in the middle of each f
- i sequence.
Aren't most Turkish and Azeri text coded as ISO-8859-9 and similar
code
Peter Kirk wrote:
Maybe, but it is hardly realistic to expect all existing Turkish and
Azeri text to be recoded to insert a character in the middle of each f -
i sequence.
Aren't most Turkish and Azeri text coded as ISO-8859-9 and similar code
pages? I that case, it would be enough to add
the fact of saying that a Grapheme Disjoiner can be used in Turkish to
avoid that the f collapses the dot above a next lowercase i?
This does not change anything: existing texts can still produce ligatures in a
renderer, unless explicitly said to not do so with a Grapheme Disjoiner
Peter Kirk asked:
In Turkish and Azeri the sequences f - i and f - dotless i both occur,
and are fairly frequent. So it is inappropriate in these languages to
use fi ligatures in which the dot on the i is lost or invisible, at
least where the second character is a dotted i. Has any
On Thursday, July 10, 2003 8:37 PM, Kenneth Whistler [EMAIL PROTECTED] wrote:
Peter Kirk asked:
In Turkish and Azeri the sequences f - i and f - dotless i both
occur, and are fairly frequent. So it is inappropriate in these
languages to use fi ligatures in which the dot on the i
Philippe Verdy scripsit:
Where does the fact of saying that a Grapheme Disjoiner can be used
in Turkish to avoid that the f collapses the dot above a next lowercase i?
It is settled that ZWNJ is the correct character to break ligatures.
ZWJ means make a ligature if you can; if not, shape
On 10/07/2003 11:37, Kenneth Whistler wrote:
At Peter pointed out, however, it is neither expected or reasonable
to have to go back through and drop in ZWNJ's at every relevant
location in existing Turkish or Azeri text, simply to prevent
fi ligation. Such use of ZWNJ is intended to be
See also
http://www.microsoft.com/typography/developers/opentype/detail.htm
which explains how ligatures can be turned off on a language-dependent basis.
Laurentiu
Peter Kirk asked:
In Turkish and Azeri the sequences f - i and f - dotless i both occur,
and are fairly frequent. So
in fact
select among three ligatures in Turkish: the fi ligature glyph
where the f is ligated with the dot above i (normal ligature for
languages other than Turkish/Azeri, the f-dotted-i and
f-fotted-i ligatures for Turkish/Azeri.
It is unclear that any such ligatures are required or desireable
Peter == Peter Kirk [EMAIL PROTECTED] writes:
Peter Maybe, but it is hardly realistic to expect all existing
Peter Turkish and Azeri text to be recoded to insert a character in
Peter the middle of each f - i sequence.
But a lot of it already does do that. In TeX Turkish uses f{}i to
block the
On 2003.07.01, 15:09, Pim Blokland [EMAIL PROTECTED] wrote:
Maybe it was a bad idea to include ? 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.
Food for thought: How would you compare U+0133 (ij
: 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 spacing accents are not decomposed
In either cases, the Soft_Dotted property is probably overkill on
the existing ij or IJ 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) for Dutch. Or is this update
needed to document
Kent Karlsson kentk at cs dot chalmers dot se 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,
ligatures (should should have been better
named letters and not ligatures) for Dutch. Or is this update
needed to document officially the expected rendering behavior for
sequences ij,accute and ij,macron?
The main interest of the Soft_Dotted property is not to describe the
rendering
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 (which does happen!), the dots must
go. Simple as that.
Maybe it was a bad idea to include as a character in Unicode at
all, but
Pim Blokland wrote:
When putting accents on the (which does happen!), the dots must
go. Simple as that.
Where should the accent be placed in that case? Should the accent be
centered over ij? Should there be one accent over i and then the
same over j? Or should the accent only be an accent
. Look at the case
conversion of ij into IJ, 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 ae and AE letters (considered as
ligatures or as unreakable letters
Philippe Verdy verdy_p at wanadoo dot fr wrote:
Maybe it was a bad idea to include 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
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.
This
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 applications may
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: ij, combining dot
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:
Of course a given fonts diaeresis will often not line up with the
stems of its ij, and a custom one should be used instead. Or
features and/or ligs as
I think the answer is, regarding the soft dot property, please leave
the ij ligature alone.
--
Michael Everson * * Everson Typography * * http://www.evertype.com
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
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
ligatures varies from a language to another. Notice that also these books
And nobody out there is volunteering to do it.
I would do it gladly, but I do not have any skills at Indian languages. My
opinion is that the list is important for the future of digital interactive
broadcasting so I am trying to get the list done so that it is ready for use
in displaying
A few observations, so that William will understand the scope and some of
the issues of what he is proposing.
1. For some Indic scripts, including Devanagari, there is no fixed set of
'ligatures' that would be normative for every typeface, or for every
language using the script. So even
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 complicated than that -- and that the term ligature is
not even
Yesterday, 13 March 2003, I wrote as follows.
quote
So I reasoned that the system might scan through a font when it is loaded
and decide upon the lowest point for the whole font and then proceed on that
basis.
end quote
An email correspondent has kindly written to me privately and I now know
Thank you both for your responses.
Yes, U+2502 or U+2503 would achieve the desired effect for which I devised
U+E700 STAFF without resorting to the Private Use Area.
The only reason for my not using one of those was that I was unaware of
those codes as such. An interesting point is that they
probably didn't come out right. I never meant to say moving the
characters apart was the best solution.
Moving only the
offending accent mark rather than the entire (composite) character might help
in some cases, but this technique also should be used with care. Like in the
At 02:21 AM 3/13/2003, William Overington wrote:
My reason for including the STAFF character, the intended effect of which I
can now produce using U+2502 or U+2503, was that, being fairly new to
producing fonts and just, thus far, using the Softy editor to produce
ordinary TrueType fonts, I had
Century English printing with long s ligatures, German
Fraktur printing and the ligatures of languages of the Indian subcontinent),
and various people produce ordinary TrueType fonts with ligature glyphs
encoded using consistent lists of published Private Use Area code points for
ligatures
.
William Overington wrote,
I have added a new code recently, which is U+E700 STAFF which is a vertical
line from the very top of the glyph and going as far below the 0 line as one
chooses for a particular font. With Quest text I encoded this character
early with a line going vertically from
1 - 100 of 281 matches
Mail list logo
