Around 17 o'clock on Aug 12, Juliusz Chroboczek wrote:
Neither have I (with over 20 years exposure to the language). I
suggest you remove it -- it's not in the Adobe Standard encoding, so
some fonts may lack it.
Ok, I've found further references that don't include ñ for French.
Here's my
any solid
information.
I'm still missing most of the African languages; any help here would be
greatly appreciated.
Out of 139 ISO 639-1 languages, I have 95 covered, I've also managed to
collect 13 of the languages only in ISO 639-2.
Keith PackardXFree86 Core TeamHP Cambridge
, then it
couldn't even distinguish between Ming and Sung forms.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
orthgraphy over fonts which are missing these
few characters when applications don't provide an explicit family name.
It sounds like the answer to this is yes, so I should add the
non Latin-1 codepoints to the set required to display French.
Keith PackardXFree86 Core TeamHP
that POSIX specifies the order in which these are used, and given
that all of my test programs don't call setlocale, I've added the trivial
code to fetch from the environment.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
I18n
with applications which haven't called
setlocale (LC_ALL, )? Do I:
a) call setlocal (LC_ALL, ) myself?
b) use $LANG or $LC_CTYPE?
c) Ignore the locale information and leave the
font language preference unset?
Keith PackardXFree86 Core
1651 HKSCS-2001 characters
And that doesn't even mention the remaining glyphs int HKSCS which aren't
currently assigned official Unicode codepoints.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
I18n mailing list
[EMAIL
. A secondary question is whether I should
check the PUA entries; I believe I probably shouldn't, and let the zh-hk
support rest on whether the font covers the non-PUA BMP subset of HKSCS.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
Around 16 o'clock on Jul 8, Jungshik Shin wrote:
Don't you mean LC_MESSAGES?
I believe it should be LC_CTYPE. Some people like me
Check. LC_CTYPE it is. Sometimes life in en_US is so insular...
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
based on the codePageRange bits.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
were some in the wild. I suppose that was rather naïve of me.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
have a complete codepoint set for HKSCS; can someone point me at
one?
With these additions, a GB18030 font would advertise support for:
zh, zh-cn, zh-tw, zh-sg, zh-mo
while older GB2312 fonts would be limited to
zh-cn, zh-sg
Keith PackardXFree86 Core TeamHP
the results they want that it is capable of
producing.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
at least some coverage for the
missing languages; even a small number of glyphs for each one would help a
lot.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman
in Big5. Again, we're
fortunate that more and more fonts are pre tagged with OS/2 language
tables from which we can deduce intended language targets far more
accurately.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
I18n
to take information in whatever format you have.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
--
LangDoneDescription
AA Afar Djibouti, N Ethiopia Hamito-Semitic F., Cushitic Br.
AB * Abkhazian Abkhazia (Georgia) Caucasian F.
AF
name the symbol?
Does it currently have an X keysym? If not, we will create an new keysym.
Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
for taking that
keysym and performing whatever action is appropriate, perhaps inserting two
characters into the document.
Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab
___
I18n mailing list
[EMAIL PROTECTED]
http
of the letter returned ? it is sure some X part :-) am I right ?
That portion is application dependent, or at least input-method dependent.
There is no standard place in X to convert a single keysym into multiple
characters, except in the input methods, and those aren't used by all
applications.
Keith
on top of the glyph layer, but
that is only a convenience for locales where a 1-1 mapping from Unicode
char to glyph exists and where layout is straightforward.
Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab
___
I18n
of slack in this computation; it should
match if the resulting pixel size is within 1.
Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
without some minor modifications.
Existing applications avoiding the XftFreeType interfaces will work just
fine.
Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman
and bitmap fonts can be used. A version of Xft that
supports PCF fonts but still requires Render can be found in my CVS
repository at http://keithp.com.
Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab
___
I18n mailing list
[EMAIL
files directly, using either FreeType or some
other font library.
Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
for UCS-2 encoding.
Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
in resolution, I expect Render will be
relatively well established and core protocol workarounds needed only for
really old (and low resolution) hardware.
Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab
___
I18n mailing list
than attempting to work around deficiencies
in the original core X text design.
I think there is concensus that client-side text (in whatever guise -- Xft
or ST) is the best way forward. Let's focus on making that solution
available on all desktops as soon as possible.
Keith Packard
existing font users. The immediate goal is to standardize how fonts are
located so that all fonts are available to all applications.
Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab
___
I18n mailing list
[EMAIL PROTECTED
source of
glyph images as far as the X server is concerned. I hope it will also
become a cooperative partner in simplifying and standardizing the use of
fonts within the open source environment.
Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab
Around 9 o'clock on Sep 29, Brian Stell wrote:
Xft is clearly the 1st choice (and perhaps only choice) most
single language apps should look at to make this transition.
As Xft can also use core fonts, and will provide a Unicode API for those,
Xft should be useful even when running on
Around 16 o'clock on Sep 29, Brian Stell wrote:
My only word of caution here is that recently people have
been generating bitmap fonts from outline fonts and installing
them as bitmap fonts. These are at best only fair and often
are mediorce. At present I do not know how to distinguish
Around 11 o'clock on Sep 29, Brian Stell wrote:
Using hand tuned bitmap fonts is a very important consideration
as they almost always look better than outline rendered bitmaps.
Many people prefer them over anti-aliased fonts at the same
size.
I'll fix Xft to use them; I believe it
Around 23 o'clock on Sep 28, Juliusz Chroboczek wrote:
We're aware of that (Tifinagh is the example I like to give). The
point Keith was making (if I understood him correctly) was that core X
fonts should only be used for glyphs covered by legacy encodings. For
new glyphs, client-side
33 matches
Mail list logo
