Egbert Eich wrote:
Mattias Ellert writes:
> Syriac fonts uses non standard codepoints screwing things up - bugzilla
> #1084
>
> It was suggested that I should forward this to this mailing list. See
> the bugzilla report for details. There are attachments to the report in
> bugzilla.
>
Hi,
This is to inform the Linux community and the open source community
(and distribution builders) of new sets of Korean truetype fonts,
Un-series fonts (GPL'd) made available thanks to UN Koaunghi
(who painstakingly scanned, converted to outlines and hand-hinted
them all) and PARK Won-Kyu. They'
On Sat, 6 Sep 2003, Anuradha Ratnaweera wrote:
> Let me put this in a simple point form using a hypothetical example:
>
> Now, if I want to render character 51 of X inplace of the composite
> character 4001+4010, how should I proceed? Is there a way to map
> unicode sequences to actual (physical)
On Thu, 7 Aug 2003, Steve Sullivan wrote:
> For example, the Terminal "edit current profile" gui shows
> the Miriam font, but Miriam isn't listed by xfontsel or xlsfonts.
There are two separate font systems, the X11 core font system and
the client-side system with Xft/fontconfig. What you get
On Fri, 8 Aug 2003, Pablo Saratxaga wrote:
> On Fri, Aug 08, 2003 at 06:59:43PM +0900, Chisato Yamauchi wrote:
>
> > But Gtk2 has not complete font-substitution mechanism.
> > Therefore, Gtk2 is insufficient in CJK environment.
>
> GTk2, using pango, has builtin fontset mechanism.
> (it is always
On Fri, 8 Aug 2003, Mike FABIAN wrote:
> Jungshik Shin <[EMAIL PROTECTED]> さんは書きました:
> > On Thu, 7 Aug 2003, Mike FABIAN wrote:
> >> It can be automatically generated. The /usr/sbin/fonts-config script
> >> on SuSE Linux generates such TTCap entries automat
On Sat, 9 Aug 2003, Jungshik Shin wrote:
> On Fri, 8 Aug 2003, Pablo Saratxaga wrote:
> > That being said, it would be nice to have the ability to do
> > user-configuration
> > of glyph substitutions in gtk2; eg telling that when a given font is
> > choosen, th
On Thu, 7 Aug 2003, Mike FABIAN wrote:
> Jungshik Shin <[EMAIL PROTECTED]> さんは書きました:
>
> > On Sat, 2 Aug 2003, Chisato Yamauchi wrote:
> >
> >> Have you seen CJK's *TYPICAL* fonts.dir of TrueType fonts?
> >> It is following:
> >
> >
On Sat, 2 Aug 2003, Chisato Yamauchi wrote:
> Although the pliability of handling such special fonts is also important,
> non BMP plane in XLFD is now the most important problem. Confusion is
> already seen such as linux-utf8 list. An official definition should be
> indicated right now. Why h
On Wed, 9 Jul 2003, Yu Shao wrote:
> Jungshik Shin wrote:
>
> >On Tue, 8 Jul 2003, Yu Shao wrote:
> I don't get you here, the first version of the patch was made for Red
> Hat 7.3, at that time we have to use Mozilla with X core font. Since
> then the patch has b
Hi,
I sent the following to James Su to seek his opinion, but it was bounced. Now
I'm sending to 1i8n and fonts list expecting him or other Chinese experts to
pick this up.
Jungshik
Hi,
Could you make a comment on
http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=441?
It'
On Tue, 10 Dec 2002, Anthony Fok wrote:
Thank you for bringing up this important issue.
> I was assigned with the task of dealing with "s p a c e d - o u t " CJK
> "fixedPitch" font issue in konsole.
In addition to Konsole, gnome-terminal, Mozilla-xft(for rendering
text/plain or a portion of h
On 11 Dec 2002, Juliusz Chroboczek wrote:
> Sorry for mis-reading your mail, then.
No problem :-)
> JS> As for complex script rendering, it's possible...
> You'll doubtless agree with me that what you're describing are a
...
> for decades now -- it's high time to move on.
Yes, I agree wi
On 10 Dec 2002, Juliusz Chroboczek wrote:
JS> Even with this weakness, Xprint is by far the best printing
JS> solution available at the moment for Mozilla under Unix/X11
JS> because postscript printing module of Mozilla does not work very
JS> well yet
JC> Xprint might work for CJK fonts,
It
27;s mozilla RPMs do not have Xprint enabled).
I'm not sure why RH disabled Xprint in their Mozilla RPM.
Xft, Xprint and PS printing module can coexist in Mozilla without
much problem as far as I can tell. Perhaps, that blocking I mentioned
above may no
On Tue, 3 Dec 2002, Jungshik Shin wrote:
> Attached is my patch(a bit revised) to extend XftTextExtents16 to
> support UTF-16 and to fix a typo in fstr.c of fontconfig(which makes the
> conversion from UTF-16 to UCS-4 not work correctly for characters in
Sorry I forogot to attach
On Sun, 1 Dec 2002, Jungshik Shin wrote:
> While trying to make Mozilla-Xft support non-BMP characters with fonts
> like CODE2001.TTF (with pid=3/eid=10 Cmap), I found that freetype
> and Xft need a little change. Details are sent to linux-utf8 list
> (http://mail.nl.linux.org/linux-
Hi,
While trying to make Mozilla-Xft support non-BMP characters with fonts
like CODE2001.TTF (with pid=3/eid=10 Cmap), I found that freetype
and Xft need a little change. Details are sent to linux-utf8 list
(http://mail.nl.linux.org/linux-utf8/2002-12/msg0.html) and Bugzilla
(http://bugzilla
On 17 Nov 2002, Juliusz Chroboczek wrote:
> GC> ttmkfdir -d /usr/share/fonts/dir1 -o /usr/share/fonts/fonts.scale
> GC> and fonts.scale is created in the first directory but test.scale
> One possibility would be a -o flag that only makes sense when no more
> than one directory is specified.
On Tue, 22 Oct 2002, Keith Packard wrote:
Thank you for your explanation.
> Around 12 o'clock on Oct 22, Jungshik Shin wrote:
>
> > 1. get a pattern from an application(fontconfig client)
> > 2. apply configuration-specified editing rules to the pattern.
> &g
On Sun, 20 Oct 2002, Jungshik Shin wrote:
> On Fri, 18 Oct 2002, Keith Packard wrote:
> > As per my comment above, I strongly prefer to make the contents of the
> > cache files independent of the configuration so that multiple
> > configurations can share the same cache fil
On Fri, 18 Oct 2002, Keith Packard wrote:
> Around 12 o'clock on Oct 18, Jungshik Shin wrote:
> > One possible explanation is that Code2000 isn't marked as supporting 'ko'
> > in font-cache for some reason while Ngulim is.
This explanation only makes
On Fri, 18 Oct 2002, Keith Packard wrote:
> Around 7 o'clock on Oct 18, Jungshik Shin wrote:
>
> > For some unknown reason, 'New Gulim' is picked up by 'fontconfig' or 'Xft'
> > for a certain characters when CODE2000 is explicitly requested
Hi,
I've found a strange problem that I believed to be
caused by fontconfig. On my RedHat 8.0 box, I added
MS-Windows font path at the top of font dir. list in fonts.conf.
That directory has CODE2000.TTF(http://home.att.net/~jameskass)
and 'New Gulim' (from MS's old Korean support tool:
http:/
Hello,
I'm wondering if I can use fonts.config to make Xft believe that a
range of characters are absent in a TTF/OTF although they're actually
present in the font. If not, I think it's a feature worth considering.
I hit upon the need for this feature because some Korean fonts (MS Gulim,
MS B
On 8 Sep 2002, Juliusz Chroboczek wrote:
> There are three standards for TTFs: Apple's TTF spec, which you're
> quoting, Microsoft's TTF spec, and the Adobe-Microsoft OpenType spec.
> Embedded bitmaps are treated differently by the Apple and Microsoft
> specs, and I'm trying to follow Microso
On Sat, 7 Sep 2002, Keith Packard wrote:
> Around 9 o'clock on Sep 7, Jungshik Shin wrote:
>
> > I'm not sure adding U+115F/U+1160 to the blank glyph list is the best
> > way, but it works. Keith, could you consider this?
>
> The blank glyph list is sup
Since the release of a new CODE2000 font(by James Kass at
http://home.att.net/~jameskass) with glyphs for Hangul Jamos, I've
been trying to test how it works with various browsers. Mozilla
with direct access to truetype fonts works fine, but Mozilla
with Xft patch has a problem with U+115F(Hangu
On Wed, 14 Aug 2002, Owen Taylor wrote:
> Jungshik Shin <[EMAIL PROTECTED]> writes:
>
> > On Wed, 14 Aug 2002, Owen Taylor wrote:
> >
> > > The current Korean orthography looks like a combination
> > > of KSC-5607.1987 with the complete Hangul Syl
> On Wed, 14 Aug 2002, Owen Taylor wrote:
> > I think the right thing to do is probably just to use
> > only the KSC-5607.1987 syllables in the Korean orthography;
Despite what I wrote in my previous message, I agree that
this is the right thing to do. This may not be an issue any more once
On Wed, 14 Aug 2002, Owen Taylor wrote:
> The current Korean orthography looks like a combination
> of KSC-5607.1987 with the complete Hangul Syllables
> area of Unicode.
I'm sorry to be 'pedantic'. Strictly speaking, this way of talking
about Korean orthography (in terms of precomposed syl
On Mon, 22 Jul 2002, Keith Packard wrote:
> Around 8 o'clock on Jul 22, Brian Stell wrote:
> > Will there be a way to get the localized name using the ascii only name?
How about the other way around? Given a localized name+lang, would
it be possible to get the ascii name? Put differently,
On Tue, 9 Jul 2002, Keith Packard wrote:
> Ok, so now what do I do with applications which haven't called
> setlocale (LC_ALL, "")? Do I:
>
> a) call setlocal (LC_ALL, "") myself?
I'm afraid this can have an unexpected side effect, which could
surprise/upset some application pro
On Mon, 8 Jul 2002, Jungshik Shin wrote:
> On Mon, 8 Jul 2002, Keith Packard wrote:
> > Around 14 o'clock on Jul 8, Owen Taylor wrote:
> > > +locale = (FcChar8 *)setlocale (LC_CTYPE, NULL);
> > Don't you mean LC_MESSAGES?
>
> I believe it
On Mon, 8 Jul 2002, Keith Packard wrote:
>
> Around 14 o'clock on Jul 8, Owen Taylor wrote:
>
> > +locale = (FcChar8 *)setlocale (LC_CTYPE, NULL);
>
> Don't you mean LC_MESSAGES?
I believe it should be LC_CTYPE. Some people like me
have the following because English menu and (error) mes
y', did you mean all dictionaries used in Taiwan
or just some small (not so extensive) dictionaries supposedly used by
(elementary) school children?
Jungshik Shin
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
ad this and I have to
agree with this. This is better than what I sent earlier. Just forgetting
about GB18030/GBK coverage and concentrating on GB2312 and Big5 coverage
is simpler as well as better.
Jungshik Shin
___
Fonts mailing list
[EMAIL PROTECT
On Sat, 29 Jun 2002, Keith Packard wrote:
Ooops. My message crossed yours in mail :-)
> Around 9 o'clock on Jun 29, Jungshik Shin wrote:
> > IMHO, most problems with Han Unification arise not from using a _single_
> > font targeted at one of zh_TW/zh_CN/ja/ko to ren
On Sat, 29 Jun 2002, Jungshik Shin wrote:
> On Fri, 28 Jun 2002, Keith Packard wrote:
> > I'm confused by this; my exposure to Chinese fonts says that simplified
> > Chinese and traditional Chinese have significant overlap in Unicode
> > codepoints, but that
available. Of
I'm not sure what you meant by 'glyph forms are more likely
simplified'. You might have misunderstood some aspects of Han Unification
in Unicode/10646. In Unicode, simplified forms of Chinese characters are
NOT unified with corresponding traditional forms of C
ze). For
JK> BATANG.TTC, the invisible range of points is [9, 24].
JK>
JK> Is this a bug? I suspect these TTC have some non-common
JK> featutes which are undetectable by current X-rendering
JK> extension engine. I heard some TTC fonts have internal
JK> built-in BITMAP fonts fo
to make of entries
like this (with non-zero pixel_size, point_size but zero average_width)?
-adobe-times-medium-r-normal--17-120-100-100-p-0-iso8859-9
It would be very nice if anybody could enlighten me on this issue.
(there must be something obvious I'm missing)
Jungshik Shin
P.S. I&
42 matches
Mail list logo
