Hi Russell
you wrote:
If multiple fonts exist for a language, then for all these font
files to work with an editor, then all these glyphs must be indexed
the same.
For complex scripts rarely will glyphs for the combinations you need to display
be indexed the same from font to font - you
Rich Felker wrote:
On Fri, Apr 27, 2007 at 05:15:16PM +0600, Christopher Fynn wrote:
N3266 was discussed and rejected by WG2 yesterday. As you pointed out
there are all sorts of problems with this proposal, and accepting it
would break many existing implementations.
That's good to hear
N3266
UCS Transformation Formats summary, non-error and error sequences –
feedback on N3248
http://std.dkuug.dk/jtc1/sc2/wg2/docs/N3266.doc
- c
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
ISO/IEC 10646 JTC1/SC2/WG2 N3248 Synchronization Issues for UTF-8
see: http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3248.doc
The document referenced above proposes changes to the specification of
UTF-8 in Annexe D of the ISO/IEC 10646 Standard to make it effectively
the same as the specification of
Colin Paul Adams wrote:
Rich == Rich Felker [EMAIL PROTECTED] writes:
Rich Indeed, this was what I was thinking of. Thanks for
Rich clarifying. BTW, any idea WHY they brought the UTF-16
Rich nonsense to DOM/DHTML/etc.?
I don't know for certain, but I can speculate well, I
After, e.g., placing a top accent on a base character, I could
increment the top coordinate by a certain amount, so a following
stacked character can also be placed correctly (but it seems not
even pango does this).
You can do this with mark-to-base and mark-to-mark GPOS lookups.
under the
Andries Brouwer wrote:
...
Now that this is being discussed, recently I needed to use
vocalized Hebrew, and found that all that I tried was broken.
Is there a version of Java, or a Java function perhaps other than
Graphics.drawString(), that correctly handles vocalized Hebrew?
Is there a
rajeev joseph sebastian wrote:
Hi Rich Felker,
I find your work to provide support for Indic text on console/terminal to be
admirable, and yes, any kind of display is far better than none at all (and I
do not consider your statement insulting) :)
What I was referring to was a comment along
Arne Gtje () wrote:
3. Varient selectors: OTF includes a feature in the GSUB table to
specify which glyphs should be used for which codepoint in a specific
region (simplified chinese, trad. chinese, japanese, etc.). Currently
OO.o is the only application supposed to support this feature.
I will
Denis Barbier wrote:
Out of curiosity, why are people willing to contribute to the CLDR
project, which has the worst bug tracking system and gives mailing lists
access only to its members? I for one am not willing to pay $120/year
in order to be able to follow its development.
I had no problem
Edward H. Trager wrote:
But even this is not enough. One also needs to have a glyph substitution
table (like GSUB in OpenType) which would allow you to map a sequence of
UNICODE_VALUEs or GLYPH_IDs to the GLYPH_IDs representing mandatory ligatures,
consonant conjuncts in Indic scripts, and so
Edward, in the murky past (maybe 17-18 years ago I saw console /
terminal type applications and utilities that worked with CJK scripts,
Indic scripts, Tibetan, Arabic or CJK scripts running under both PC DOS
and Xenix. (The systems for Indic scripts Tibetan were made by CDAC in
Pune India)
registered.
srintuar wrote:
Christopher Fynn wrote:
The Transliteration feature types allows text is one format to be
displayed using another format. An example is taking a hiragana string
and displaying it as katakana. This is an exclusive feature type.
Currently defined selectors for this feature
srintuar wrote:
Danilo Segan wrote:
The only possible reform that would alleviate this condition would
be to completely unify the latin and cyrillic scripts or to
eliminate one of them. Then cyrillic or latin could simply be a font
setting for users of all languages.
(I dont know if this is even
Edward H. Trager wrote:
Mlterm (http://mlterm.sourceforge.net/) is a multilingual-capable terminal
emulator which handles combining characters. Mlterm with a console-based
mail reader like mutt works pretty well. However, one is still at the
mercy of the fonts. Even an OpenType font which
srintuar wrote:
This may be more of a practical issue: for some scripts such as Korean,
representing every possible character and partial character could
require a very large amount of codespace. We only have the precomposed
characters now for compatibility with platforms that simply dont support
wiss wrote:
Hi!, My name is Martin Wiss and I live in Sweden.
I am currently working on an open source multilingual dictionary.
Or maybe it is better to call it just an open dictionary or database.
The words are kept in an postgresql database.
When I do queries on the database from a webpage I
Is there someone who might be willing to help write LC_COLLATE elements
for Dzongkha (dz) Tibetan (bo) locales for glibc? A Bhutanese friend
has been trying to do this for months with and has asked me for
help, but I know next to nothing about LC_COLLATE.
I do know the rules for Dzongkha and
18 matches
Mail list logo
