Bug#818634: xserver-xorg-core: system log flooded by GetModeLine messages

2016-03-21 Thread Anthony Fok 
On Sat, 19 Mar 2016 13:43:13 +0100 Julien Cristau 
wrote:
> Control: tag -1 fixed-upstream
>
> On Sat, Mar 19, 2016 at 00:48:15 +0200, Alberto Garcia wrote:
>
> > Package: xserver-xorg-core
> > Version: 2:1.18.2-1
> > Severity: normal
> > Tags: upstream patch
> >
> > Hey,
> >
> > the system journal is being flooded by thousands of 'GetModeLine ...'
> > messages.
> >
> > This problem was reported in Fedora a couple of days ago:
> >
> >https://bugzilla.redhat.com/show_bug.cgi?id=1318545
> >
> > Here's the upstream fix:
> >
> >
https://cgit.freedesktop.org/xorg/xserver/commit/?id=75eecf28ae3709181a51571132b0accd9cae316e
> >
> Well, the fix is to stop using xf86vidmode...
>
> Cheers,
> Julien

So, is a fix forthcoming?  It is not just a minor annoyance: the flooding
log messages are simultaneously written to /var/log/messages,
/var/log/syslog and /var/log/user.log, not only thrashing the hard drive
and slowing down the system, but also quickly growing to hundreds and
thousands of megabytes in size, easily filling up a smaller hard drive
within a short period of time.  And it is not just going to affect a
handful of users.

I suppose that is why Fedora uploaded a fix within 32 hours of receiving
the initial bug report.

So, is a fix forthcoming, soon?  If not, I am more than happy to make a NMU
today.

Many thanks,
Anthony

Re: RFC: define FontLibSharedFreeType=NO

2003-06-08 Thread Anthony Fok 
Hello,

Does the same crash exists between libfreetype6_2.1.3-2 and 2.1.3-3? In
2.1.3-4 (which I uploaded this morning), I tried to revert the change with
respect to PS_FontInfoRec (while going to CVS 2003-06-07), and I had been
wondering whether I did it correctly or not.

My apologies for the troubles caused.

Anthony

On Sun, Jun 08, 2003 at 07:36:13PM +0900, ISHIKAWA Mutsumi wrote:
  In [EMAIL PROTECTED] 
  Branden Robinson [EMAIL PROTECTED] wrote:
 
  On Sat, Jun 07, 2003 at 11:20:01PM +0900, ISHIKAWA Mutsumi wrote:
I got a report in private mail (grrr) from a person who ran into the
very problem you describe, so I appreciate you tracking this down and
fixing it.  Your analysis looks reasonable and I agree with your
solution.
   
Sorry, I found my mistakes by my self.
   
1) PS_FontInfoRec was not changed between FreeeType 2.1.3 and
   2.1.4. It makes after FreeType 2.1.4 release (please see
   freetype-2.1.4/debian/patches/001-freetype-2.1.4+cvs20030601.diff).
 
  If this is true, then, FreeType maintainer: *please stop doing this*.
 
  Debian needs to have FreeType packages that are compatible with the rest
  of the world's FreeType packages.
 
  Perhaps what we really need is a freetype-snapshot package, which ships
  a libfreetype6-snapshot package which Conflicts/Replaces/Provides:
  libfreetype6.  For reasons that should be obvious, there should be no
  snapshot -dev package at all.
 
  Please, please, please, I beg of you, do not break binary compatibility
  in library packages.
 
  Humm, I found a message from Werner LEMBERG posted to
 [EMAIL PROTECTED] I believe libfreetype6 incompatible between
 2.1.4-3 and 2.1.4-4.
 
   Application build with libfreetype6_2.1.4-4 (use PS_FontInfoRec)
 will crash with libfreetype6_2.1.4-3.
 
   Application build with libfreetype6_2.1.4-3 (use PS_FontInfoRec)
 will crash with libfreetype6_2.1.4-4.
 
  But SONAME is not changed yet (on upstream).
 
 
  In [EMAIL PROTECTED] 
  Werner LEMBERG [EMAIL PROTECTED] wrote:
  
  You might want to reconsider the change...
   
   * src/type1/t1tokens.h: Change italic_angle, is_fixed_pitch,
   underline_position, and underline_thickness to pointers.  Change
   the type of the latter two to `fixed'.
   
   in current freetype6 without a change in version numbering of the shared
   libraries.
 
  Our normal strategy is to increase the shared library version number
  right before a new release (as suggested by libtool).  We will do
  that, of course, but not now.
 
  Is there a better strategy?
 
 
  Werner
 
 -- 
 ISHIKAWA Mutsumi
  [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]

-- 
Anthony Fok Tung-Ling
ThizLinux Laboratory   [EMAIL PROTECTED] http://www.thizlinux.com/
Debian Chinese Project [EMAIL PROTECTED]   http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!   http://www.olvc.ab.ca/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: RFC: define FontLibSharedFreeType=NO

2003-06-08 Thread Anthony Fok 
Hello,

Does the same crash exists between libfreetype6_2.1.3-2 and 2.1.3-3? In
2.1.3-4 (which I uploaded this morning), I tried to revert the change with
respect to PS_FontInfoRec (while going to CVS 2003-06-07), and I had been
wondering whether I did it correctly or not.

My apologies for the troubles caused.

Anthony

On Sun, Jun 08, 2003 at 07:36:13PM +0900, ISHIKAWA Mutsumi wrote:
  In [EMAIL PROTECTED] 
  Branden Robinson [EMAIL PROTECTED] wrote:
 
  On Sat, Jun 07, 2003 at 11:20:01PM +0900, ISHIKAWA Mutsumi wrote:
I got a report in private mail (grrr) from a person who ran into the
very problem you describe, so I appreciate you tracking this down and
fixing it.  Your analysis looks reasonable and I agree with your
solution.
   
Sorry, I found my mistakes by my self.
   
1) PS_FontInfoRec was not changed between FreeeType 2.1.3 and
   2.1.4. It makes after FreeType 2.1.4 release (please see
   freetype-2.1.4/debian/patches/001-freetype-2.1.4+cvs20030601.diff).
 
  If this is true, then, FreeType maintainer: *please stop doing this*.
 
  Debian needs to have FreeType packages that are compatible with the rest
  of the world's FreeType packages.
 
  Perhaps what we really need is a freetype-snapshot package, which ships
  a libfreetype6-snapshot package which Conflicts/Replaces/Provides:
  libfreetype6.  For reasons that should be obvious, there should be no
  snapshot -dev package at all.
 
  Please, please, please, I beg of you, do not break binary compatibility
  in library packages.
 
  Humm, I found a message from Werner LEMBERG posted to
 [EMAIL PROTECTED] I believe libfreetype6 incompatible between
 2.1.4-3 and 2.1.4-4.
 
   Application build with libfreetype6_2.1.4-4 (use PS_FontInfoRec)
 will crash with libfreetype6_2.1.4-3.
 
   Application build with libfreetype6_2.1.4-3 (use PS_FontInfoRec)
 will crash with libfreetype6_2.1.4-4.
 
  But SONAME is not changed yet (on upstream).
 
 
  In [EMAIL PROTECTED] 
  Werner LEMBERG [EMAIL PROTECTED] wrote:
  
  You might want to reconsider the change...
   
   * src/type1/t1tokens.h: Change italic_angle, is_fixed_pitch,
   underline_position, and underline_thickness to pointers.  Change
   the type of the latter two to `fixed'.
   
   in current freetype6 without a change in version numbering of the shared
   libraries.
 
  Our normal strategy is to increase the shared library version number
  right before a new release (as suggested by libtool).  We will do
  that, of course, but not now.
 
  Is there a better strategy?
 
 
  Werner
 
 -- 
 ISHIKAWA Mutsumi
  [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]

-- 
Anthony Fok Tung-Ling
ThizLinux Laboratory   [EMAIL PROTECTED] http://www.thizlinux.com/
Debian Chinese Project [EMAIL PROTECTED]   http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!   http://www.olvc.ab.ca/

Bug#181815: xlibs: Problem with XRenderCompositeText16 in Render extension

2003-02-20 Thread Anthony Fok 
Package: xlibs
Version: 4.2.1-5
Severity: important
Tags: patch upstream sid

Hello Branden,

Mozilla Xft users (including myself) have been experiencing strange
disappearing text problem, as explained in Mozilla Bugzilla Bug
#187377: Characters disappear with xft if fallback triggered twice on
the same line and related bug reports.  See:

http://bugzilla.mozilla.org/show_bug.cgi?id=187377

Most bug reporters use Debian or FreeBSD.  This problem does not happen
on Red Hat 8.0.  I guess not many people know the fix yet.

The details of this bug came up on the XFree86 fonts mailing list just
two days ago:

  ITO Tsuyoshi says:

While performing some test about Mozilla Bugzilla Bug #187377 [1], I
found that XRenderCompositeText16 function in Render extension does
not draw text as intended when multiple glyphsets are involved in one
call.

According to the code of the Render extension on X server side,
XRenderCompositeText16 should send a glyphset-switch sign (a glyph
element with len = 0xff) to the X server when it encounters a glyph
element whose glyphset is different from the one of the previous glyph
element.  However, it actually sends the glyphset-switch sign when it
encounters a glyph element whose glyphset is different from the one of
the _first_ glyph element.  XRenderCompositeText{8,32} probably have
the same problem.

  and provided a patch.  Keith Packard replied:

Your analysis is quite correct.  A fix solving this issue was placed in
XFree86 CVS on 2002-8-31.

That patch was also included in Red Hat 8.0, probably days before it
was final:

  * Sun Sep 01 2002 Mike A. Harris [EMAIL PROTECTED] 4.2.0-70
  ...
  - Added XFree86-4.2.0-libXrender-bugfix.patch to fix showstopper (#73243)

That patch (still identical to the one in current XFree86-4.3 CVS) is
attached.  Please include this in your next upload.  (Feel free to change
the 094_ number.  :-)

Thanks!

Anthony

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux anthony 2.4.21-pre4-ac1 #1 Mon Feb 3 03:11:48 HKT 2003 i686

Versions of packages xlibs depends on:
ii  libc6 2.3.1-12   GNU C Library: Shared libraries an
ii  libfreetype6  2.1.3-10   FreeType 2 font engine, shared lib
ii  xfree86-common4.2.1-5X Window System (XFree86) infrastr

-- no debconf information

Index: lib/Xrender/Glyph.c
===
RCS file: /cvs/xc/lib/Xrender/Glyph.c,v
retrieving revision 1.7
retrieving revision 1.10
diff -u -p -r1.7 -r1.10
--- xc/lib/Xrender/Glyph.c	2001/12/27 01:16:00	1.7
+++ xc/lib/Xrender/Glyph.c	2002/08/31 18:15:45	1.10
@@ -125,6 +125,7 @@ XRenderFreeGlyphs (Display   *dpy,
 GetReq(RenderFreeGlyphs, req);
 req-reqType = info-codes-major_opcode;
 req-renderReqType = X_RenderFreeGlyphs;
+req-glyphset = glyphset;
 len = nglyphs;
 SetReqLen(req, len, len);
 len = 2;
@@ -390,6 +391,7 @@ XRenderCompositeText8 (Display			*dp
 {
 XExtDisplayInfo		*info = XRenderFindDisplay (dpy);
 xRenderCompositeGlyphs8Req	*req;
+GlyphSet			glyphset;
 long			len;
 long			elen;
 xGlyphElt			*elt;
@@ -419,10 +421,17 @@ XRenderCompositeText8 (Display			*dp
  */
 len = 0;
 
+glyphset = elts[0].glyphset;
 for (i = 0; i  nelt; i++)
 {
-	if (elts[i].glyphset != req-glyphset)
+	/*
+	 * Check for glyphset change
+	 */
+	if (elts[i].glyphset != glyphset)
+	{
+	glyphset = elts[i].glyphset;
 	len += (SIZEOF (xGlyphElt) + 4)  2;
+	}
 	nchars = elts[i].nchars;
 	/*
 	 * xGlyphElt must be aligned on a 32-bit boundary; this is
@@ -434,26 +443,24 @@ XRenderCompositeText8 (Display			*dp
 }
 
 req-length += len;
-/* 
- * If the entire request does not fit into the remaining space in the
- * buffer, flush the buffer first.
- */
 
-if (dpy-bufptr + (len  2)  dpy-bufmax)
-	_XFlush (dpy);
-
+/*
+ * Send the glyphs
+ */
+glyphset = elts[0].glyphset;
 for (i = 0; i  nelt; i++)
 {
 	/*
 	 * Switch glyphsets
 	 */
-	if (elts[i].glyphset != req-glyphset)
+	if (elts[i].glyphset != glyphset)
 	{
+	glyphset = elts[i].glyphset;
 	BufAlloc (xGlyphElt *, elt, SIZEOF (xGlyphElt));
 	elt-len = 0xff;
 	elt-deltax = 0;
 	elt-deltay = 0;
-	Data32(dpy, elts[i].glyphset, 4);
+	Data32(dpy, glyphset, 4);
 	}
 	nchars = elts[i].nchars;
 	xDst = elts[i].xOff;
@@ -461,15 +468,17 @@ XRenderCompositeText8 (Display			*dp
 	chars = elts[i].chars;
 	while (nchars)
 	{
+	int this_chars = nchars  MAX_8 ? MAX_8 : nchars;
+
 	BufAlloc (xGlyphElt *, elt, SIZEOF(xGlyphElt))
-	elt-len = nchars  MAX_8 ? MAX_8 : nchars;
+	elt-len = this_chars;
 	elt-deltax = xDst;
 	elt-deltay = yDst;
 	xDst = 0;
 	yDst = 0;
-	Data (dpy, chars, elt-len);
-	nchars -= elt-len;
-	chars += elt-len;
+	Data (dpy,

Re: xft and xfree86-truetype-fonts

2002-08-09 Thread Anthony Fok 
Hi all,

On Thu, Aug 08, 2002 at 10:27:22PM -0500, Branden Robinson wrote:
 On Thu, Aug 08, 2002 at 04:59:52PM -0700, Michael Cardenas wrote:
  The new redhat beta, limbo, uses xft and a package called
  xfree86-truetype-fonts for displaying schweet looking fonts. 
  
  These packages are not included in the 4.2.0 series of debs. Do they
  just have different names? Is there some reason we don't include them?
 
 Well, why don't you tell us what files are in those packages, and maybe
 we can tell you if they come from the XFree86 source package or not?

According to www.rpmfind.net, Red Hat's XFree86-truetype-fonts package
contains:

/usr/X11R6/lib/X11/fonts/TTF
/usr/X11R6/lib/X11/fonts/TTF/encodings.dir
/usr/X11R6/lib/X11/fonts/TTF/fonts.alias
/usr/X11R6/lib/X11/fonts/TTF/fonts.dir
/usr/X11R6/lib/X11/fonts/TTF/fonts.scale
/usr/X11R6/lib/X11/fonts/TTF/luximb.ttf
/usr/X11R6/lib/X11/fonts/TTF/luximbi.ttf
/usr/X11R6/lib/X11/fonts/TTF/luximr.ttf
/usr/X11R6/lib/X11/fonts/TTF/luximri.ttf
/usr/X11R6/lib/X11/fonts/TTF/luxirb.ttf
/usr/X11R6/lib/X11/fonts/TTF/luxirbi.ttf
/usr/X11R6/lib/X11/fonts/TTF/luxirr.ttf
/usr/X11R6/lib/X11/fonts/TTF/luxirri.ttf
/usr/X11R6/lib/X11/fonts/TTF/luxisb.ttf
/usr/X11R6/lib/X11/fonts/TTF/luxisbi.ttf
/usr/X11R6/lib/X11/fonts/TTF/luxisr.ttf
/usr/X11R6/lib/X11/fonts/TTF/luxisri.ttf

 * The name of a Red Hat package is not particularly meaningful.
 * As far as I've been able to tell I'm shipping just about everything
   new that there is to ship.
 * Do you read debian-devel, debian-legal, or Debian Weekly News?  You
   might interested to learn that most schweet TrueType fonts are
   non-free.  Red Hat cares a lot less about licensing than Debian does.
 
 http://lists.debian.org/debian-devel/2002/debian-devel-200208/msg00080.html

i.e. XFree86-truetype-fonts in Red Hat corresponds to the
 xfonts-scalable-nonfree package in Debian.  :-)

Cheers,

Anthony

-- 
Anthony Fok Tung-Ling
ThizLinux Laboratory   [EMAIL PROTECTED] http://www.thizlinux.com/
Debian Chinese Project [EMAIL PROTECTED]   http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!   http://www.olvc.ab.ca/

Re: xft and xfree86-truetype-fonts

2002-08-09 Thread Anthony Fok 
On Thu, Aug 08, 2002 at 10:28:11PM -0700, Michael Cardenas wrote:
  I'd rather wait until Keith has given some indication that the code is
  stable before I'd even want to consider patching up to it.
  
  Most likely, the best approach is just to get it with the rest of 4.3.0
  when that is released.
 
 Don't you think that we could include it now in testing or in
 unstable? I'll probably be making a deb package for it for lindows, so
 if you're interested, let me know and I'll post it somewhere so people
 can test it. 

Xft2 and fontconfig are probably still a bit experimental.  But yes,
Red Hat developers have been experimenting with it in Rawhide.  Note
that the Xft1 - Xft2 upgrade will affect quite a few package,
including XFree86, Qt, Gtk2, and probably more.  Do figure out the
roadmap before diving into it.  :-)

Cheers,

Anthony

-- 
Anthony Fok Tung-Ling
ThizLinux Laboratory   [EMAIL PROTECTED] http://www.thizlinux.com/
Debian Chinese Project [EMAIL PROTECTED]   http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!   http://www.olvc.ab.ca/

More locale patches for Chinese, courtesy of ThizLinux

2001-09-20 Thread Anthony Fok 
Hello Branden,

Attached is two more patches that deals with XFree86 4.1.0's Chinese
locale support, courtesy of ThizLinux Laboratory Ltd. (because I worked
on these patches during company time, under the direction of ThizLinux.
:-)

A patch adds more encoding names to locale.dir esp. now that IANA uses
Big5-HKSCS as the canonical name (instead of Big5HKSCS).

Another patch fixes a missing portion in X-TT's Big5HKSCS-Unicode table.
It seems that the original patch provided by Roger So [EMAIL PROTECTED]
was complete, but for some reasons, upstream didn't include the F9D6-F9FE
portion.  Anyhow, some commonly used characters are in that area, hence
this fix.  :-)

When you have a chance, it would be great if you could apply these patches
upstream.  Also, instead of acknowledging me [EMAIL PROTECTED], it would be
really nice if you could acknowledge ThizLinux Laboratory Ltd. instead.
( http://www.thizlinux.com/ ).  (You may include [EMAIL PROTECTED]
too.  ;-)  It's because ThizLinux really wants to contribute back to the
Free Software / Open Source community, and I really appreciate ThizLinux
for letting me contribute patches as before.  So yeah, even though these
patches are not big at all, but it is a start.  :-)

(And yes, more patches from ThizLinux will find their way to Debian or other
upstream projects soon.  :-)

Thanks for your help!  :-)

Anthony

-- 
Anthony Fok Tung-Ling
ThizLinux developer[EMAIL PROTECTED] http://www.thizlinux.com/
Debian Chinese Project [EMAIL PROTECTED]   http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!   http://www.olvc.ab.ca/
--- xc~/extras/X-TrueType/BIG5HKSCS/BIG5HKSCStoUCS2.c   Wed Mar  7 02:54:40 2001
+++ xc/extras/X-TrueType/BIG5HKSCS/BIG5HKSCStoUCS2.cWed Sep  5 17:27:09 2001
@@ -3091,12 +3091,12 @@
 0x9E17, 0x9F48, 0x6207, 0x6B1E, 0x7227, 0x864C, 0x8EA8, 0x9482, 
 0x9480, 0x9481, 0x9A69, 0x9A68, 0x9B2E, 0x9E19, 0x7229, 0x864B, 
 0x8B9F, 0x9483, 0x9C79, 0x9EB7, 0x7675, 0x9A6B, 0x9C7A, 0x9E1D, 
-0x7069, 0x706A, 0x9EA4, 0x9F7E, 0x9F49, 0x9F98, ALTCHR, ALTCHR, 
-ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, 
-ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, 
-ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, 
-ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, 
-ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, 
+0x7069, 0x706A, 0x9EA4, 0x9F7E, 0x9F49, 0x9F98, 0x7881, 0x92B9, 
+0x88CF, 0x58BB, 0x6052, 0x7CA7, 0x5AFA, 0x2554, 0x2566, 0x2557, 
+0x2560, 0x256C, 0x2563, 0x255A, 0x2569, 0x255D, 0x2552, 0x2564, 
+0x2555, 0x255E, 0x256A, 0x2561, 0x2558, 0x2567, 0x255B, 0x2553, 
+0x2565, 0x2556, 0x255F, 0x256B, 0x2562, 0x2559, 0x2568, 0x255C, 
+0x2551, 0x2550, 0x256D, 0x256E, 0x2570, 0x256F, 0xFFED, ALTCHR, 
 /* start of HKSCS area */
 /* 0xFA40 - 0xFAFF */
 0xE000, 0x92DB, 0xE002, 0xE003, 0x854C, 0x42B5, 0x73EF, 0x51B5, 
diff -urN xc~/nls/locale.dir xc/nls/locale.dir
--- xc~/nls/locale.dir  Fri Aug 31 12:30:48 2001
+++ xc/nls/locale.dir   Wed Sep  5 21:49:58 2001
@@ -205,6 +205,7 @@
 iso8859-15/XLC_LOCALE  wa_BE.ISO8859-15
 microsoft-cp1255/XLC_LOCALEyi_US.CP1255
 zh_CN/XLC_LOCALE   zh_CN.eucCN
+zh_CN/XLC_LOCALE   zh_CN.GB2312
 zh_CN.gbk/XLC_LOCALE   zh_CN.gbk
 zh_HK.big5/XLC_LOCALE  zh_HK.big5
 zh_HK.big5hkscs/XLC_LOCALE zh_HK.big5hkscs
@@ -552,7 +553,10 @@
 zh_CN/XLC_LOCALE:  zh_CN.eucCN
 zh_CN/XLC_LOCALE:  zh_CN.GB2312
 zh_CN.gbk/XLC_LOCALE:  zh_CN.GBK
+zh_HK.big5hkscs/XLC_LOCALE:zh_HK.big5-hkscs
+zh_HK.big5hkscs/XLC_LOCALE:zh_HK.Big5-HKSCS
 zh_HK.big5hkscs/XLC_LOCALE:zh_HK.big5hkscs
+zh_HK.big5hkscs/XLC_LOCALE:zh_HK.Big5HKSCS
 zh_TW.big5/XLC_LOCALE: zh_TW.big5
 zh_TW.big5/XLC_LOCALE: zh_TW.Big5
 zh_TW/XLC_LOCALE:  zh_TW.eucTW


pgpX0B4OfcYR3.pgp
Description: PGP signature

More locale patches for Chinese, courtesy of ThizLinux

2001-09-19 Thread Anthony Fok 

Hello Branden,

Attached is two more patches that deals with XFree86 4.1.0's Chinese
locale support, courtesy of ThizLinux Laboratory Ltd. (because I worked
on these patches during company time, under the direction of ThizLinux.
:-)

A patch adds more encoding names to locale.dir esp. now that IANA uses
Big5-HKSCS as the canonical name (instead of Big5HKSCS).

Another patch fixes a missing portion in X-TT's Big5HKSCS-Unicode table.
It seems that the original patch provided by Roger So [EMAIL PROTECTED]
was complete, but for some reasons, upstream didn't include the F9D6-F9FE
portion.  Anyhow, some commonly used characters are in that area, hence
this fix.  :-)

When you have a chance, it would be great if you could apply these patches
upstream.  Also, instead of acknowledging me [EMAIL PROTECTED], it would be
really nice if you could acknowledge ThizLinux Laboratory Ltd. instead.
( http://www.thizlinux.com/ ).  (You may include [EMAIL PROTECTED]
too.  ;-)  It's because ThizLinux really wants to contribute back to the
Free Software / Open Source community, and I really appreciate ThizLinux
for letting me contribute patches as before.  So yeah, even though these
patches are not big at all, but it is a start.  :-)

(And yes, more patches from ThizLinux will find their way to Debian or other
upstream projects soon.  :-)

Thanks for your help!  :-)

Anthony

-- 
Anthony Fok Tung-Ling
ThizLinux developer[EMAIL PROTECTED] http://www.thizlinux.com/
Debian Chinese Project [EMAIL PROTECTED]   http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!   http://www.olvc.ab.ca/


--- xc~/extras/X-TrueType/BIG5HKSCS/BIG5HKSCStoUCS2.c   Wed Mar  7 02:54:40 2001
+++ xc/extras/X-TrueType/BIG5HKSCS/BIG5HKSCStoUCS2.cWed Sep  5 17:27:09 2001
@@ -3091,12 +3091,12 @@
 0x9E17, 0x9F48, 0x6207, 0x6B1E, 0x7227, 0x864C, 0x8EA8, 0x9482, 
 0x9480, 0x9481, 0x9A69, 0x9A68, 0x9B2E, 0x9E19, 0x7229, 0x864B, 
 0x8B9F, 0x9483, 0x9C79, 0x9EB7, 0x7675, 0x9A6B, 0x9C7A, 0x9E1D, 
-0x7069, 0x706A, 0x9EA4, 0x9F7E, 0x9F49, 0x9F98, ALTCHR, ALTCHR, 
-ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, 
-ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, 
-ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, 
-ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, 
-ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, ALTCHR, 
+0x7069, 0x706A, 0x9EA4, 0x9F7E, 0x9F49, 0x9F98, 0x7881, 0x92B9, 
+0x88CF, 0x58BB, 0x6052, 0x7CA7, 0x5AFA, 0x2554, 0x2566, 0x2557, 
+0x2560, 0x256C, 0x2563, 0x255A, 0x2569, 0x255D, 0x2552, 0x2564, 
+0x2555, 0x255E, 0x256A, 0x2561, 0x2558, 0x2567, 0x255B, 0x2553, 
+0x2565, 0x2556, 0x255F, 0x256B, 0x2562, 0x2559, 0x2568, 0x255C, 
+0x2551, 0x2550, 0x256D, 0x256E, 0x2570, 0x256F, 0xFFED, ALTCHR, 
 /* start of HKSCS area */
 /* 0xFA40 - 0xFAFF */
 0xE000, 0x92DB, 0xE002, 0xE003, 0x854C, 0x42B5, 0x73EF, 0x51B5, 


diff -urN xc~/nls/locale.dir xc/nls/locale.dir
--- xc~/nls/locale.dir  Fri Aug 31 12:30:48 2001
+++ xc/nls/locale.dir   Wed Sep  5 21:49:58 2001
@@ -205,6 +205,7 @@
 iso8859-15/XLC_LOCALE  wa_BE.ISO8859-15
 microsoft-cp1255/XLC_LOCALEyi_US.CP1255
 zh_CN/XLC_LOCALE   zh_CN.eucCN
+zh_CN/XLC_LOCALE   zh_CN.GB2312
 zh_CN.gbk/XLC_LOCALE   zh_CN.gbk
 zh_HK.big5/XLC_LOCALE  zh_HK.big5
 zh_HK.big5hkscs/XLC_LOCALE zh_HK.big5hkscs
@@ -552,7 +553,10 @@
 zh_CN/XLC_LOCALE:  zh_CN.eucCN
 zh_CN/XLC_LOCALE:  zh_CN.GB2312
 zh_CN.gbk/XLC_LOCALE:  zh_CN.GBK
+zh_HK.big5hkscs/XLC_LOCALE:zh_HK.big5-hkscs
+zh_HK.big5hkscs/XLC_LOCALE:zh_HK.Big5-HKSCS
 zh_HK.big5hkscs/XLC_LOCALE:zh_HK.big5hkscs
+zh_HK.big5hkscs/XLC_LOCALE:zh_HK.Big5HKSCS
 zh_TW.big5/XLC_LOCALE: zh_TW.big5
 zh_TW.big5/XLC_LOCALE: zh_TW.Big5
 zh_TW/XLC_LOCALE:  zh_TW.eucTW

 PGP signature

zh_CN X locale in Debian's XFree86-4.1.0-1 / -2

2001-08-04 Thread Anthony Fok 
(Oops, I sent the previous message too soon because I pressed the wrong
key...)  :-)

Hello Branden,

As per our discussion on IRC, locale.dir (or its source) needs to be
updated to reflect the move of zh/XLC_LOCALE to zh_CN/XLC_LOCALE.

Also, please move zh/Compose to zh_CN/Compose, and remember
to update compose.dir (or its source)!  :-)

Thanks again!

Anthony

-- 
  Debian GNU/Linux Chinese Project .. http://www.debian.org/intl/zh/
  Come visit Our Lady of Victory Camp ... http://www.olvc.ab.ca/
--- /usr/lib/X11/locale/locale.dir~ Sat Jul 28 15:40:32 2001
+++ /usr/lib/X11/locale/locale.dir  Fri Aug  3 15:30:45 2001
@@ -549,8 +549,8 @@
 iso8859-1/XLC_LOCALE:  wa_BE.ISO8859-1
 iso8859-15/XLC_LOCALE: wa_BE.ISO8859-15
 microsoft-cp1255/XLC_LOCALE:   yi_US.CP1255
-zh/XLC_LOCALE: zh_CN.eucCN
-zh/XLC_LOCALE: zh_CN.GB2312
+zh_CN/XLC_LOCALE:  zh_CN.eucCN
+zh_CN/XLC_LOCALE:  zh_CN.GB2312
 zh_CN.gbk/XLC_LOCALE:  zh_CN.GBK
 zh_HK.big5hkscs/XLC_LOCALE:zh_HK.big5hkscs
 zh_TW.big5/XLC_LOCALE: zh_TW.big5

Re: TrueType fonts in X.

2001-03-30 Thread Anthony Fok 

Hello Take-san,

I just noticed yesterday that both defoma and gs-5.50 (with defoma
support) are in the Debian unstable archive now.  I was pleasantly
surprised!  :-)

Yes, it is a goal that the font packages migrate to use defoma, at least
for the Chinese fonts that the Debian Chinese Project is doing.
Having said that, I probably won't have time to look into it until mid or
late April because of all the projects at school that are due very soon
now.  (And I am really behind... Yikes!)

Anyhow, I am interested in what Branden thinks too and it would be great
if you, Branden and other developers could work out the migration strategy
or even put everything into the Debian Policy eventually.  :-)

Thanks a lot for your great work!  The defoma framework opens up great
opportunity for better font management and user-installable fonts etc.
etc.  :-)

Cheers,

Anthony

-- 
Anthony Fok Tung-LingCivil and Environmental Engineering
[EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada
   Debian GNU/Linux Chinese Project -- http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: TrueType fonts in X.

2001-03-30 Thread Anthony Fok 
Hello Take-san,

I just noticed yesterday that both defoma and gs-5.50 (with defoma
support) are in the Debian unstable archive now.  I was pleasantly
surprised!  :-)

Yes, it is a goal that the font packages migrate to use defoma, at least
for the Chinese fonts that the Debian Chinese Project is doing.
Having said that, I probably won't have time to look into it until mid or
late April because of all the projects at school that are due very soon
now.  (And I am really behind... Yikes!)

Anyhow, I am interested in what Branden thinks too and it would be great
if you, Branden and other developers could work out the migration strategy
or even put everything into the Debian Policy eventually.  :-)

Thanks a lot for your great work!  The defoma framework opens up great
opportunity for better font management and user-installable fonts etc.
etc.  :-)

Cheers,

Anthony

-- 
Anthony Fok Tung-LingCivil and Environmental Engineering
[EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada
   Debian GNU/Linux Chinese Project -- http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/

Re: compiling XF4 on potato? (fwd)

2001-01-29 Thread Anthony Fok 

On Mon, 29 Jan 2001, Juliusz Chroboczek wrote:
 
 SK  I installed freetype2-dev to get the freetype headers in the first
 SK  place. I also noticed that in the command above we have
 SK  "-I/usr/include/freetype2" while the include files for freetype are in
 SK  "/usr/include/freetype" (notice the missing "2"). Making a symlink from
 SK  freetype to freetype2 didn't help though.
 
 The Debian ``freetype2'' package is FreeType version 1.3 (go figure).
 So your symlink is incorrect.

Yes, it is somewhat unfortunate.  FreeType 1.3.1 (and 1.4) use
libttf.so.2, i.e., the major soname of "2", and that's where the "2" on
"freetype2" comes from. I should have renamed the package to "libttf2"
though.

 For Xft, you really need FreeType version 2.  I don't know if it's
 packaged yet, but you may get the sources from www.freetype.org.  Or
 else you could try building without Xft.

apt-get install libfreetype6 libfreetype6-dev

Enough confusion yet?  :-)

Anthony
Debian maintainer of the FreeType packages.  :-)

-- 
Anthony Fok Tung-LingCivil and Environmental Engineering
[EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada
   Debian GNU/Linux Chinese Project -- http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: compiling XF4 on potato? (fwd)

2001-01-29 Thread Anthony Fok 
On Mon, 29 Jan 2001, Juliusz Chroboczek wrote:
 
 SK  I installed freetype2-dev to get the freetype headers in the first
 SK  place. I also noticed that in the command above we have
 SK  -I/usr/include/freetype2 while the include files for freetype are in
 SK  /usr/include/freetype (notice the missing 2). Making a symlink from
 SK  freetype to freetype2 didn't help though.
 
 The Debian ``freetype2'' package is FreeType version 1.3 (go figure).
 So your symlink is incorrect.

Yes, it is somewhat unfortunate.  FreeType 1.3.1 (and 1.4) use
libttf.so.2, i.e., the major soname of 2, and that's where the 2 on
freetype2 comes from. I should have renamed the package to libttf2
though.

 For Xft, you really need FreeType version 2.  I don't know if it's
 packaged yet, but you may get the sources from www.freetype.org.  Or
 else you could try building without Xft.

apt-get install libfreetype6 libfreetype6-dev

Enough confusion yet?  :-)

Anthony
Debian maintainer of the FreeType packages.  :-)

-- 
Anthony Fok Tung-LingCivil and Environmental Engineering
[EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada
   Debian GNU/Linux Chinese Project -- http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/

Re: Please test: Netscape 4.73 packages with CJK support

2000-07-17 Thread Anthony Fok 
Hello Branden,

On Sun, Jul 16, 2000 at 09:50:00PM -0500, Branden Robinson wrote:
 [Apologies for private mail to so many people.]

I am doing the same, so, my apologies too.  :-)

 On Wed, Jul 12, 2000 at 10:04:19AM +0200, Torsten Landschoff wrote:
  If I understand your description correctly this option is never harmful but
  very useful for some setups. Don't you think that the Debian setup should
  pass this option per default? In that case please ask Branden if he can
  do that (or file a bug, severity wishlist, on xserver-common).
 
 -deferglyph 16 has been in place in the default /etc/X11/xdm/Xservers file
 for quite a while.

Yes, we know.  (Thanks, BTW!)  As you may have read from other posts, from
Debian JP developers, the suggestion is to make startx uses -deferglyphs
16 by default too, because the people running into problem with xfs-xtt 
xserver are the ones who run X manually with startx and didn't know they
needed to use startx -- -deferglyphs 16.

The suggestion from SANO-san is to modify /usr/X11R6/bin/startx,
whereas the suggestion from ISHIKAWA-san is to 
#define DEFAULT_GLYPH_CACHING_MODE CACHE_16_BIT_GLYPHS
in fonts.h.  Their messages were posted to debian-x@lists.debian.org,
so you've probably read them already.  Methinks both of these are excellent
ideas, so, take your pick, or heaven forbids, let's do both!  ;-)

 I am adding deferglyphs = 16 to the default xfs config file for 3.3.6-10.

Hey, that would be a nice idea!  :-)  Although the 16bit CJK PCF fonts aren't
anywhere as huge as the TrueType ones, it would definitely make loading
those PCF fonts faster.  :-)  Thanks!

Anthony

-- 
Anthony Fok Tung-LingCivil and Environmental Engineering
[EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada
Debian Chinese Project -- http://www.debian.org/international/chinese/
Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/

Re: ANNOUNCEMENT: there will be no XFree86 4.0.0 .debs (please read)

2000-05-29 Thread Anthony Fok 
On Mon, May 29, 2000 at 02:30:49PM +0200, Sven LUTHER wrote:
 Branden, i understand Xfree packaging is a big chunk of work, but would it not
 be easier if there was some kind of cvs repository of the packaging stuff, and
 you would post the ideas you had for the new XF4.x packages, and that other
 people could help you work on it ?

You know what?  I really like this idea!  If there are a group of us who
would like to help out with X maintenance, a Debian CVS repository together
with an automatic daily (or bi-daily) build (if there's any changes) would
be really swell.  :-)

Anthony

-- 
Anthony Fok Tung-LingCivil and Environmental Engineering
[EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada
Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/

A tiny bug with xserver-*: /usr/doc/bubble?

2000-05-28 Thread Anthony Fok 
Hello Branden,

I just installed 3.3.6-6pre7v1.  So far so good!  :-)

I was trying to look for the directory /usr/doc/xserver-svga,
but it's not there, so I checked in
/var/lib/dpkg/info/xserver-svga.postinst and noticed the following lines:

if [ -d /usr/doc -a ! -e /usr/doc/xserver-svga -a -d /usr/share/doc/bubble ]; 
then
  ln -sf ../share/doc/xserver-svga /usr/doc/bubble
fi

Hmm... interesting.  What is bubble?  :-)
The same lines are in xserver-s3.postinst, so I assume all the xserver-*
packages (except xserver-common) have this tiny bubble bug.

Cheers,

Anthony

-- 
Anthony Fok Tung-LingCivil and Environmental Engineering
[EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada
Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/