Re: [Fonts] Weird Font Bug?

2004-03-03 Thread Chisato Yamauchi 
From: Chisato Yamauchi [EMAIL PROTECTED]
Subject: Re: [Fonts] Weird Font Bug?
Date: Tue, 02 Mar 2004 20:31:08 +0900 (JST)

 if (!pfont-fpe)
 pfont-fpe = fpe;
 pfont-refcnt++;
 if (pfont-refcnt == 1) {
 UseFPE(pfont-fpe);
 for (i = 0; i  screenInfo.numScreens; i++) {
 pScr = screenInfo.screens[i];
 if (pScr-RealizeFont)
 {
 if (!(*pScr-RealizeFont) (pScr, pfont))

  xnestRealizeFont() in xnest/Font.c is substituted for 
(*pScr-RealizeFont)().  It seems that xnestRealizeFont() 
function depends on installed fonts of parent X server.

  Although I add new font path on Xnest,

  xset +fp $HOME/fonts/

the fonts in $HOME/fonts/ cannot be displayed, and I got
the BadAlloc error.  So I add the font path on parent X server,
the Xnest can display the fonts in $HOME/fonts/.

  By the way, the Xnest uses statically linked FreeType backend.
One of them depends on parent X server and the other does not...
I think that this may be strange implementation.

 [EMAIL PROTECTED]:~# xterm -fn 10x20 -display :1
 X Error of failed request:  BadAlloc (insufficient resources for operation)

  This error may be caused by another problem.


Chisato Yamauchi
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] Weird Font Bug?

2004-03-02 Thread Chisato Yamauchi 
From: Fred Richards [EMAIL PROTECTED]
Subject: [Fonts] Weird Font Bug?
Date: Mon, 01 Mar 2004 22:26:29 -0500

 xterm.  But I noticed a problem.  Whenever I start an Xnest (from within 
 an already running X session) with the command Xnest :1 -ac , then as 
 root run windomaker with wmaker -display :1  ... I have a dock icon 
 that did with with 4.3.0, that basically loaded an xterm with a 10x20 
 font, but instead, I get this error:
 
 [EMAIL PROTECTED]:~# xterm -fn 10x20 -display :1
 X Error of failed request:  BadAlloc (insufficient resources for operation)
   Major opcode of failed request:  45 (X_OpenFont)
   Serial number of failed request:  49
   Current serial number in output stream:  50

  I also got the error using Xnest.  It seems that 
doOpenFont() function of dixfonts.c returns AllocError
(line 327):

if (!pfont-fpe)
pfont-fpe = fpe;
pfont-refcnt++;
if (pfont-refcnt == 1) {
UseFPE(pfont-fpe);
for (i = 0; i  screenInfo.numScreens; i++) {
pScr = screenInfo.screens[i];
if (pScr-RealizeFont)
{
if (!(*pScr-RealizeFont) (pScr, pfont))
{
CloseFont (pfont, (Font) 0);
err = AllocError;
goto bail;
}
}
}
}

  But I don't know the detail of this code...


Chisato Yamauchi
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] freetype module sometimes gets font height (descent?)

2004-02-22 Thread Chisato Yamauchi 
From: Michael Lampe [EMAIL PROTECTED]
Subject: Re: [Fonts] freetype module sometimes gets font height (descent?)
Date: Sat, 21 Feb 2004 18:54:14 +0100

  I cannot reprodeuce them using xedit... Why?   How is your 
  resolution of xdpyinfo.  100x100 dots per inch?
 
 Manually set to 75 dpi, real value is almost exactly 96 dpi. But this is
 not the problem. If I replace '...-100-100-...' in the LFD with
 '...-75-75-...' or enforce any other dpi value on the X server or let it 
 choose its own, it's exactly the same.
 
 fontpropdump with freetype:

  Thanks.  I've fixed the problem:

--- xc/lib/font/FreeType.orig/ftfuncs.c 2004-02-17 16:44:59.0 +0900
+++ xc/lib/font/FreeType/ftfuncs.c  2004-02-22 18:06:54.0 +0900
@@ -3319,8 +3341,12 @@
 /* set info */
 
 if( info ){
+   /*
info-fontAscent = ascent;
info-fontDescent = descent;
+   */
+   info-fontAscent = info-maxbounds.ascent;
+   info-fontDescent = info-maxbounds.descent;
/* Glyph metrics are accurate */
info-inkMetrics=1;

 PIXEL_SIZE : 12
 POINT_SIZE : 87
 RESOLUTION_X : 100
 RESOLUTION_Y : 100
 AVERAGE_WIDTH : 70
 RAW_AVERAGE_WIDTH : 6001
 FONT_ASCENT : 12  
 RAW_ASCENT : (none)
 FONT_DESCENT : 8  
 RAW_DESCENT : (none)

  RAW_ASCENT and RAW_DESCENT have disappeared.  There are
simple bugs in the backend, so I've fixed in attached new
patch.

 RAW_PIXEL_SIZE : (none)
 RAW_POINT_SIZE : (none)

  The Type1 backend also returns these values.  I've added 
them in the patch.

  Additionally, in the new patch, fp=n TTCap option makes
FreeType backend behave like X-TT backend about font properties.


Chisato Yamauchi
--- xc/lib/font/FreeType.orig/ftfuncs.c 2004-02-17 16:44:59.0 +0900
+++ xc/lib/font/FreeType/ftfuncs.c  2004-02-22 18:38:57.0 +0900
@@ -1327,7 +1327,7 @@
 
 static int
 FreeTypeAddProperties(FTFontPtr font, FontScalablePtr vals, FontInfoPtr info, 
-  char *fontname, int rawAverageWidth)
+  char *fontname, int rawAverageWidth, Bool font_properties)
 {
 int i, j, maxprops;
 char *sp, *ep, val[MAXFONTNAMELEN], *vp;
@@ -1376,9 +1376,11 @@
 maxprops=
 1 + /* NAME */
 (xlfdProps ? 14 : 0) +  /* from XLFD */
-8 +
-(os2 ? 6 : 0) +
-(post || t1info? 3 : 0) +
+5 +
+( !face-bitmap ? 3 : 0 ) +/* raw_av,raw_asc,raw_dec */
+( font_properties ? 2 : 0 ) +  /* asc,dec */
+( (font_properties  os2) ? 6 : 0 ) +
+( (font_properties  (post || t1info)) ? 3 : 0 ) +
 2;  /* type */
 
 info-props = (FontPropPtr)xalloc(maxprops * sizeof(FontPropRec));
@@ -1444,29 +1446,41 @@
 }
 }
 
+info-props[i].name = MakeAtom(RAW_PIXEL_SIZE, 14, TRUE);
+info-props[i].value = 1000;
+i++;
+
+info-props[i].name = MakeAtom(RAW_POINT_SIZE, 14, TRUE);
+info-props[i].value = (long)(72270.0 / (double)vals-y + .5);
+i++;
+
 if(!face-bitmap) {
 info-props[i].name = MakeAtom(RAW_AVERAGE_WIDTH, 17, TRUE);
 info-props[i].value = rawAverageWidth;
 i++;
 }
 
-info-props[i].name = MakeAtom(FONT_ASCENT, 11, TRUE);
-info-props[i].value = info-fontAscent;
-i++;
+if ( font_properties ) {
+   info-props[i].name = MakeAtom(FONT_ASCENT, 11, TRUE);
+   info-props[i].value = info-fontAscent;
+   i++;
+}
 
 if(!face-bitmap) {
-info-props[i].name = MakeAtom(RAW_ASCENT, 15, TRUE);
+info-props[i].name = MakeAtom(RAW_ASCENT, 10, TRUE);
 info-props[i].value = 
 ((double)face-face-ascender/(double)upm*1000.0);
 i++;
 }
 
-info-props[i].name = MakeAtom(FONT_DESCENT, 12, TRUE);
-info-props[i].value = info-fontDescent;
-i++;
+if ( font_properties ) {
+   info-props[i].name = MakeAtom(FONT_DESCENT, 12, TRUE);
+   info-props[i].value = info-fontDescent;
+   i++;
+}
 
 if(!face-bitmap) {
-info-props[i].name = MakeAtom(RAW_DESCENT, 16, TRUE);
+info-props[i].name = MakeAtom(RAW_DESCENT, 11, TRUE);
 info-props[i].value = 
 -((double)face-face-descender/(double)upm*1000.0);
 i++;
@@ -1541,7 +1555,7 @@
   /* In what follows, we assume the matrix is diagonal.  In the rare
  case when it is not, the values will be somewhat wrong. */
   
-if(os2) {
+if( font_properties  os2 ) {
 info-props[i].name = MakeAtom(SUBSCRIPT_SIZE,14,TRUE);
 info-props[i].value = 
 TRANSFORM_FUNITS_Y(os2-ySubscriptYSize);
@@ -1568,7 +1582,7 @@
 i++;
 }
 
-if(post || t1info) {
+if( font_properties  (post || t1info) ) {
 int underlinePosition, underlineThickness;
 
/* Raw underlineposition counts upwards, 
@@ -1909,8 +1923,8 @@
 static int 
 FreeTypeSetUpTTCap( char *fileName

Re: [Fonts] freetype module sometimes gets font height (descent?) wrong

2004-02-21 Thread Chisato Yamauchi 
From: Michael Lampe [EMAIL PROTECTED]
Subject: [Fonts] freetype module sometimes gets font height (descent?) wrong
Date: Fri, 20 Feb 2004 17:39:58 +0100

 xlsfonts lists the font in question.
 
 Emacs bluntly says No fonts match ... and aborts.
 
 xfd seems to use it, but displays unknown font in the first line. And 
 contrary to what I said before you can see the overall problem with xfd 
 too if you increase the font size.

  OK. That patch was broken.  I somewhat misunderstood...

 I'm still wondering if you are able to reproduce what I'm talking about. 
   Please try
 
 xedit
   -fn -monotype-courier new-medium-r-normal--12-0-100-100-m-0-iso8859-1
 
 Two small images of what it looks like for me are here:
 
 http://cox.iwr.uni-heidelberg.de/~lampe/xedit-xtt.png
 http://cox.iwr.uni-heidelberg.de/~lampe/xedit-freetype.png

  I cannot reprodeuce them using xedit... Why?   How is your 
resolution of xdpyinfo.  100x100 dots per inch?

  I attach fontpropdump.c.  Would you tell me the results of
freetype and xtt?

  usage:

  ./fontpropdump -monotype-courier new-medium-r-normal--12-0-100-100-m-0-iso8859-1

  Here are my results:

[X-TT]
PIXEL_SIZE : 12
POINT_SIZE : 87
RESOLUTION_X : 100
RESOLUTION_Y : 100
AVERAGE_WIDTH : 70
RAW_AVERAGE_WIDTH : 6001
FONT_ASCENT : 11
RAW_ASCENT : (none)
FONT_DESCENT : 4
RAW_DESCENT : (none)
SUBSCRIPT_SIZE : 8
SUBSCRIPT_X : 0
SUBSCRIPT_Y : 2
SUPERSCRIPT_SIZE : 8
SUPERSCRIPT_X : 0
SUPERSCRIPT_Y : 5
UNDERLINE_THICKNESS : 1
UNDERLINE_POSITION : 3
RAW_PIXEL_SIZE : (none)
RAW_POINT_SIZE : (none)

[FreeType]
PIXEL_SIZE : 12
POINT_SIZE : 87
RESOLUTION_X : 100
RESOLUTION_Y : 100
AVERAGE_WIDTH : 70
RAW_AVERAGE_WIDTH : 600
FONT_ASCENT : (none)
RAW_ASCENT : 832
FONT_DESCENT : (none)
RAW_DESCENT : 300
SUBSCRIPT_SIZE : (none)
SUBSCRIPT_X : (none)
SUBSCRIPT_Y : (none)
SUPERSCRIPT_SIZE : (none)
SUPERSCRIPT_X : (none)
SUPERSCRIPT_Y : (none)
UNDERLINE_THICKNESS : (none)
UNDERLINE_POSITION : (none)
RAW_PIXEL_SIZE : 1000
RAW_POINT_SIZE : 723

  The resolution of Xserver is 100x100 dots per inch.


Chisato Yamauchi
#include stdio.h
#include X11/Xlib.h

int main( int argc, char *argv[] )
{
Display *dis;
XFontStruct *fs;
Atom atom;
unsigned long val;
char *name;
Bool result;
char *props[] = {
PIXEL_SIZE,
POINT_SIZE,
RESOLUTION_X,
RESOLUTION_Y,
AVERAGE_WIDTH,
RAW_AVERAGE_WIDTH,
FONT_ASCENT,
RAW_ASCENT,
FONT_DESCENT,
RAW_DESCENT,
SUBSCRIPT_SIZE,
SUBSCRIPT_X,
SUBSCRIPT_Y,
SUPERSCRIPT_SIZE,
SUPERSCRIPT_X,
SUPERSCRIPT_Y,
UNDERLINE_THICKNESS,
UNDERLINE_POSITION,
RAW_PIXEL_SIZE,
RAW_POINT_SIZE,
NULL,
};
int i;

if( argc  2 ) return -1;
dis=XOpenDisplay(NULL);
fs = XLoadQueryFont(dis,argv[1]);
if( fs==NULL ) return -1;

i=0;
while ( props[i] != NULL ) {
atom = XInternAtom(dis, props[i], True);
result = XGetFontProperty(fs,atom,val);
if ( result )
printf(%s : %d\n,props[i],val);
else
printf(%s : (none)\n,props[i]);
i++;
}
return 0;
}

Re: [Fonts] freetype module sometimes gets font height (descent?) wrong

2004-02-21 Thread Chisato Yamauchi 
From: Chisato Yamauchi [EMAIL PROTECTED]
Subject: Re: [Fonts] freetype module sometimes gets font height (descent?) wrong
Date: Sat, 21 Feb 2004 20:32:28 +0900 (JST)

  Sorry,

 [X-TT]

  s/X-TT/FreeType/

 PIXEL_SIZE : 12
 POINT_SIZE : 87
 RESOLUTION_X : 100
 RESOLUTION_Y : 100
 AVERAGE_WIDTH : 70
 RAW_AVERAGE_WIDTH : 6001
 FONT_ASCENT : 11
 RAW_ASCENT : (none)
 FONT_DESCENT : 4
 RAW_DESCENT : (none)
 SUBSCRIPT_SIZE : 8
 SUBSCRIPT_X : 0
 SUBSCRIPT_Y : 2
 SUPERSCRIPT_SIZE : 8
 SUPERSCRIPT_X : 0
 SUPERSCRIPT_Y : 5
 UNDERLINE_THICKNESS : 1
 UNDERLINE_POSITION : 3
 RAW_PIXEL_SIZE : (none)
 RAW_POINT_SIZE : (none)
 
 [FreeType]

  s/FreeType/X-TT/

 PIXEL_SIZE : 12
 POINT_SIZE : 87
 RESOLUTION_X : 100
 RESOLUTION_Y : 100
 AVERAGE_WIDTH : 70
 RAW_AVERAGE_WIDTH : 600
 FONT_ASCENT : (none)
 RAW_ASCENT : 832
 FONT_DESCENT : (none)
 RAW_DESCENT : 300
 SUBSCRIPT_SIZE : (none)
 SUBSCRIPT_X : (none)
 SUBSCRIPT_Y : (none)
 SUPERSCRIPT_SIZE : (none)
 SUPERSCRIPT_X : (none)
 SUPERSCRIPT_Y : (none)
 UNDERLINE_THICKNESS : (none)
 UNDERLINE_POSITION : (none)
 RAW_PIXEL_SIZE : 1000
 RAW_POINT_SIZE : 723


Chisato Yamauchi
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] freetype module sometimes gets font height (descent?)

2004-02-17 Thread Chisato Yamauchi 
From: Michael Lampe [EMAIL PROTECTED]
Subject: Re: [Fonts] freetype module sometimes gets font height (descent?)
Date: Mon, 16 Feb 2004 19:38:40 +0100

  Monotype Courier New from M$'s webfonts, cour.ttf, 302688 bytes, most probably the 
  same font you get from a WindowsNT installation.
  
 
 Hmmm... Seems you need emacs 20.7 to reproduce. Emacs 21.x makes no 
 difference to me, too.
 
 Another way to see the same problem is to change the font for the 
 playlist in xmms to Monotype Arial (arial.ttf).

  I think that this problem is related to FreeType's additional
font properties.  Try xfd command,

  xfd -fn -monotype-courier new-medium-r-normal--13-0-100-100-m-0-iso8859-1

and check the differences of ascent and descent between xtt and 
freetype.  Perhaps no difference will be seen.  If so, try the
attached patch and set fp=n option to fonts.dir:

  fp=n:cour.ttf -monotype-courier new-medium-r-normal--0-0-0-0-m-0-iso8859-1

and would you tell the result?  If fp=n is set, the freetype
backend does not add the font properties.


Chisato Yamauchi
*** xc/lib/font/FreeType.orig/ftfuncs.c 2004-02-17 16:44:59.0 +0900
--- xc/lib/font/FreeType/ftfuncs.c  2004-02-17 17:29:33.0 +0900
***
*** 1909,1916 
  static int 
  FreeTypeSetUpTTCap( char *fileName, FontScalablePtr vals,
char **dynStrRealFileName, char **dynStrFTFileName,
!   struct TTCapInfo *ret, int *face_number,
!   FT_Int32 *load_flags, int *spacing, char **dynStrTTCapCodeRange )
  {
  int result = Successful;
  SDynPropRecValList listPropRecVal;
--- 1909,1916 
  static int 
  FreeTypeSetUpTTCap( char *fileName, FontScalablePtr vals,
char **dynStrRealFileName, char **dynStrFTFileName,
!   struct TTCapInfo *ret, int *face_number, FT_Int32 *load_flags,
!   int *spacing, Bool *font_properties, char **dynStrTTCapCodeRange )
  {
  int result = Successful;
  SDynPropRecValList listPropRecVal;
***
*** 1920,1925 
--- 1920,1926 
  Bool alwaysEmbeddedBitmap = False;
  int pixel = vals-pixel;
  
+ *font_properties=True;
  *dynStrRealFileName=NULL;
  *dynStrFTFileName=NULL;
  *dynStrTTCapCodeRange=NULL;
***
*** 2404,2409 
--- 2405,2417 
  }
  }
  
+ if (SPropRecValList_search_record(listPropRecVal,
+   contRecValue,
+   FontProperties)) {
+ /* Set or Reset the Flag of FontProperties */
+ *font_properties=SPropContainer_value_bool(contRecValue);
+ }
+ 
  ret-force_c_scale_b_box_width *= ret-scaleBBoxWidth;
  ret-force_c_scale_b_box_height *= ret-scaleBBoxHeight;
  
***
*** 2870,2876 
  long rawWidth = 0, rawAverageWidth = 0;
  int upm, minLsb, maxRsb, ascent, descent, width, averageWidth;
  double scale, base_width, base_height;
! Bool orig_is_matrix_unit;
  int face_number, ttcap_spacing;
  struct TTCapInfo tmp_ttcap;
  struct TTCapInfo *ins_ttcap;
--- 2878,2884 
  long rawWidth = 0, rawAverageWidth = 0;
  int upm, minLsb, maxRsb, ascent, descent, width, averageWidth;
  double scale, base_width, base_height;
! Bool orig_is_matrix_unit, font_properties;
  int face_number, ttcap_spacing;
  struct TTCapInfo tmp_ttcap;
  struct TTCapInfo *ins_ttcap;
***
*** 2890,2896 
 dynStrRealFileName, dynStrFTFileName,
 tmp_ttcap, face_number, 
 load_flags, ttcap_spacing,
!dynStrTTCapCodeRange);
  if ( xrc != Successful ) {
goto quit;
  }
--- 2898,2904 
 dynStrRealFileName, dynStrFTFileName,
 tmp_ttcap, face_number, 
 load_flags, ttcap_spacing,
!font_properties, dynStrTTCapCodeRange);
  if ( xrc != Successful ) {
goto quit;
  }
***
*** 3347,3353 
  if(xf)
  xf-fontPrivate = (void*)font;

! if(info) {
  xrc = FreeTypeAddProperties(font, vals, info, entry-name.name, 
  rawAverageWidth);
  if (xrc != Successful) {
--- 3355,3361 
  if(xf)
  xf-fontPrivate = (void*)font;

! if(info  font_properties) {
  xrc = FreeTypeAddProperties(font, vals, info, entry-name.name, 
  rawAverageWidth);
  if (xrc != Successful) {
*** xc/lib/font/FreeType.orig/xttcap.c  2003-10-20 03:53:50.0 +0900
--- xc/lib/font/FreeType/xttcap.c   2004-02-17 17:07:43.0 +0900
***
*** 102,108 
  { FaceNumber, eRecTypeString },
  { AutoItalic

Re: [Fonts] freetype module sometimes gets font height (descent?) wrong

2004-02-12 Thread Chisato Yamauchi 
From: Michael Lampe [EMAIL PROTECTED]
Subject: [Fonts] freetype module sometimes gets font height (descent?) wrong
Date: Sun, 08 Feb 2004 20:00:25 +0100

 Try once with freetype and once with xtt loaded:
 
 emacs -fn
   -monotype-courier new-medium-r-normal--13-0-100-100-m-0-iso8859-1
 
 With freetype it looks like double-spaced. With xtt it's ok.
 
 This is with current cvs, 4.3 and probably before.

  I've tested using cour.ttf(included in WindowsNT), but
I cannot reproduce the problem.  There are no differences 
between xtt and freetype with current cvs.

  What font do you use?


Chisato Yamauchi
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] libfreetype-xtt2 version 1.0 released

2003-10-18 Thread Chisato Yamauchi 
  Hi,

  The After X-TT Project released libfreetype-xtt2 patch version 1.0
for enhancements of libfreetype.a.  
  In this release, the complete vl=y option is suppoted.

  I write the CHANGES:

=
CHANGES
==
MAJOR CHANGES AND FIXES:
- Fixed crash caused by using fonts which have OS2 sfnt table.
- Corrected metrics calculation error.  Although the original code uses
   size-metrics, the FT_Size_Metrics does not have exact values when
   handling the outline.  So the codes for metrics calculation were
   drastically rewritten.
- Fixed some problems with FreeTypeRasteriseGlyph().
   - Made only metrics is required distinct from both metrics and
 rasterised bitmap are required to improve performance when loading
 large charset.
   - Fixed the erroneous usage of freetype2 API.  To get valid metrics,
 FT_Outline_Get_BBox() is used for outline.
   - Took the strange code for raster copying and rewrote it.
- Fixed UNDERLINE_POSITION so that it counts downwards.
- Fixed a risky calculational method for info-maxbound and
   info-minbound when spacing is not charcell.  All glyphs' metrics are
   calculated and valid info-maxbounds and info-minbounds are set
   without cutting any corners.

ADDITIONAL FUNCTIONALITIES:
- Added TTCap option fn,ai,ds,fs,vl,cr,bw,eb,hi,
   fc and fm which are compatible with X-TT 1.4.
- Supported character width for vertical layouts.
- Removed jisx0208.1983-0.enc.
- Added ALIAS jisx0208.1983-0 to jisx0208.1990-0.enc.
- Added Windows ucs2 cmap(3,1) to jisx0208.1990-0.enc.
- Added Windows ucs2 cmap(3,1) to jisx0201.1976-0.enc.
- Added enc file for GB18030-0.
- Added enc file for GB18030-1.

=

  In addition, we have important comments regarding fixes
for developer in following files:

  http://x-tt.sourceforge.jp/arch/libfreetype-xtt2-CHANGES_AND_COMMENTS.txt


  Download the patch - http://x-tt.sourceforge.jp/


  Thanks.


Chisato Yamauchi
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] libfreetype-xtt2 version 1.0 released

2003-10-18 Thread Chisato Yamauchi 
From: Chisato Yamauchi [EMAIL PROTECTED]
Subject: Re: [Fonts] libfreetype-xtt2 version 1.0 released
Date: Sun, 19 Oct 2003 02:24:18 +0900 (JST)

   Download the patch - http://x-tt.sourceforge.jp/

  I've uploaded version 1.0a.  If you downloaded 1.0, please
update to 1.0a.

  Thanks.


Chisato Yamauchi
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts] libfreetype-xtt2 beta1 released

2003-10-13 Thread Chisato Yamauchi 
  Hi,

  On Oct. 14, the After X-TT Project released libfreetype-xtt2
beta1 patch for enhancements of libfreetype.a.  This patch provides 
almost perfect TTCap options and various bug fixes in libfreetype.a
font backend. 

  Applying beta1 patch, the fn,ai,ds,fs,vl,cr,bw,eb,
hi,fc and fm options can be used.  Our patch also contains 
various fixes for bugs and wrong design in original code. 

  Using fc and fm option, the X loads the large charset
as fast as X-TT version 1.4.  But vl option is not complete.
Although we use FT_Outline_Get_CBox() when vl=y, it is not so
fast...

  Download - http://x-tt.sourceforge.jp/


  This beta1 patch works stable on my environment.  Please
try and report to us.


  Thanks.


Chisato Yamauchi
After X-TT Project
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] After-XTT's extension of the encoding field.

2003-09-04 Thread Chisato Yamauchi 
From: Juliusz Chroboczek [EMAIL PROTECTED]
Subject: Re: [Fonts] After-XTT's extension of the encoding field.
Date: 04 Sep 2003 17:04:08 +0200

 I do not believe that TTCap is a good idea, and will not implement it
 in the FreeType backend.

  However, I already started the experiment of enhancemnet of libfreetype.a

 The way to go is to implement all font configuration through
 fontconfig.  Unlike fonts.dir, the fontconfig cache is an extensible
 data structure that can be used to store any relevant information.

  Probably, I think that I understand what you want to do.
Perhaps you are going to do fundamental solution.
  Althougn I don't believe fontconfig itself, when can the people
in CJK use OpenType satisfactorily in XLFD?  Next release of XFree?


Chisato Yamauchi
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] Problem of Xft2

2003-08-14 Thread Chisato Yamauchi 
From: Pablo Saratxaga [EMAIL PROTECTED]
Subject: Re: [Fonts] Problem of Xft2
Date: Fri, 8 Aug 2003 18:32:34 +0200

The right and wrong of a toolkit become clear when using 
  Xft2.  For me, Qt is the only choice when using Xft2. So I do
 
 I feel exactly the opposite: as Qt doesn't have automatic fontset mechanism,
 I very often end with characters displayed as empty white squares, giving
 unreadable text.

  When I used Qt version 3.0.x, I saw many empty white squares.
It was quite insufficient.  But in version 3.1.x, almost all 
problems are solved.  So the usefulness of Xft2 takes a step
forward.

 Gtk may choose automatically a font that looks funny, but at least a character
 is always displayed in a readable way, I prefer it that way.

  Automatic only is quite insufficient.  We do not want to
see mismatched glyphs.

 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, then characters of range 0x00-0xff should be ignored, and taken
 from font  instead. The ascii range of some CJK fonts is simply 
 too ugly... or even bugged in some cases. 

  Yes.  You know CJK environment very well.  In addition, there
are few CJK fonts which have PROPORTIONAL ascii glyphs.  But the
alphabet should be displayed by proportional except terminal and
editor.
  When I use Konqueror, I set Nimbus Sans l as default font.
Of course, Nimbus Sans l does not have CJK glyphs.  So I set
a CJK fonts which matchs it to Font Substitution.  Then characters
of the ascii range in CJK font are ignored, we can get the proper
style of pages.

  Perhaps the approach of fontset will become obsolete.
I cannot understand details, but I have a feeling that
the approach of Font Substitution simplifies the mechanism
of CJK support.  Therefore probably Qt introduced Font Substitution.

  Anyway, the combination of Xft2 and Gtk2 is the worst.
For me, the combination is THE POOR THING.

  Doesn't XFree86 provide a Font Substitution mechanism for Xft2?
This will be a heavy weight for development of toolkit.  I think
that XFree86 should provide a standard library for it, or Xft2
will not advance.


Chisato Yamauchi
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts] Problem of Xft2

2003-08-10 Thread Chisato Yamauchi 
From: Mike FABIAN [EMAIL PROTECTED]
Subject: [Fonts] Re: After-XTT's extension of the encoding field.
Date: Thu, 07 Aug 2003 18:55:26 +0200

 I agree that the old X fonts are broken beyond repair and we should
 move on to use fontconfig/Xft as much as possible.

  The Xft2 seems to have a very important problem in CJK 
environment.

  As you know, people in CJK use FontSet or FontList 
when using XLFD.  However, the Xft2 does not have such a
mechanism.  Therefore, a toolkit using Xft2 must have it.

  In fact, Qt has a mechanism of Font Substitutions. We 
can set it easily by qtconfig.  This mechanism is 
excellent.  So I always use Konqueror as my browser.

  But Gtk2 has not complete font-substitution mechanism.
Therefore, Gtk2 is insufficient in CJK environment.
So I *NEVER* use Gtk2-mozilla.  It has no flexibility of a 
font setting.

  The right and wrong of a toolkit become clear when using 
Xft2.  For me, Qt is the only choice when using Xft2. So I do
not feel charm for Xft2 now.

  If the Xft2 itself has Font Substitutions, I may like it.


Chisato Yamauchi
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] After-XTT's extension of the encoding field.

2003-08-02 Thread Chisato Yamauchi 
-0xe7ff:vl=y:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
pmincho-medium-i-normal--0-0-0-0-p-0-iso10646-1
hi=y:fc=0x3400-0xe7ff:vl=y:ds=mb:eb=y:ai=0.21:kochi-mincho.ttf -kochi-kochi 
pmincho-bold-i-normal--0-0-0-0-p-0-iso10646-1


  We are going to continue development of X-TT until libfreetype.a can
be used in CJK.  Of course, there is also a plan using freetype2.
Or it may be possible that we provide patches for libfreetype.a
for implementing TTCap options.  But do XFree86's developers accept
our patches for libfreetype.a?


Chisato Yamauchi
After X-TT Project
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] After-XTT's extension of the encoding field.

2003-07-29 Thread Chisato Yamauchi 
From: Egbert Eich [EMAIL PROTECTED]
Subject: Re: [Fonts] After-XTT's extension of the encoding field.
Date: Tue, 29 Jul 2003 18:11:21 +0200

 This extension came from the After-XTT people from Japan.

  I thought of this extension from a argument with
Jamus Su.  It seems that there were some discussion on 
some mail lists of supporting non BMP glyphs.
  For example,

  http://mail.nl.linux.org/linux-utf8/2000-12/index.html
   Re: X font aliases and UTF-8 xterm, Ienup Sung
 Re: X font aliases and UTF-8 xterm, Robert Brady 
 Re: X font aliases and UTF-8 xterm, Roman Czyborra 

  But I like no proposals in them which cause confusion obviously.
Therefore I think that we actually cannot but extend Encoding Field.
The extension of X-TT 1.4 does not have any problems about compatibility,
so I implemented this extention to X-TT without many discussion.
Even if this extension is not accepted, there is no necessity of
deleting this extension.

  In Japan, there are the GT fonts which includes 66773 glyphs.
To use GT fonts, I implemented this extention.  It is also one of
the reasons.  I use them like:

  gt21.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.1
  gt22.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.2
  gt23.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.3
   :
   :

  The code range of gt is the same of that of jisx0208.


Chisato Yamauchi
After X-TT Project
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] A serious problem about freetype module

2003-02-11 Thread Chisato Yamauchi 
 The calculation of bpr looks a little unusual to me, but I don't know
 how all the parameters are used.
 
 I'll commit your patch now since it does help prevent a crash.

  Thanks.

  I confirmed that this buffer overflow occurs memcpy() in 
ftfuncs.c:


if(dx == 0  dy == 0  bpr == bitmap-pitch) {
memcpy(raster, bitmap-buffer, bitmap-rows * bitmap-pitch);
} else if(dx == 0) {


  'bitmap-rows * bitmap-pitch' sometimes exceeds 'ht*bpr' 
when displaying kochi-mincho.ttf, so X crashes.

  The following is a patch for improving safety.  Although 
not 'ht+2' but 'ht' is used, the crash does not occur.


Chisato Yamauchi


*** xc/lib/font/FreeType/ftfuncs.c._orig_   2003-02-09 21:02:43.0 +0900
--- xc/lib/font/FreeType/ftfuncs.c  2003-02-11 17:30:35.0 +0900
***
*** 600,627 
  bpr = (((wd + (instance-bmfmt.glyph3) - 1)  3)  
 -instance-bmfmt.glyph);
  if(tgp) {
! raster = (char*)xalloc((ht+2) * bpr);
  if(raster == NULL) 
  return AllocError;
! memset(raster, 0, (ht+2) * bpr);
  }
  
  if(dx == 0  dy == 0  bpr == bitmap-pitch) {
! memcpy(raster, bitmap-buffer, bitmap-rows * bitmap-pitch);
  } else if(dx == 0) {
! for(i = MAX(0, -dy); i  bitmap-rows  i + dy  ht; i++)
! memcpy(raster + (i + dy) * bpr,
!bitmap-buffer + i * bitmap-pitch,
!bitmap-pitch);
  } else {
  for(i = MAX(0, -dy); i  bitmap-rows  i + dy  ht; i++) {
  for(j = MAX(0, -dx); j  bitmap-width  j + dx  wd; j++) {
  int set;
  set = (bitmap-buffer[i * bitmap-pitch + j / 8] 
 1  (7 - j % 8));
! if(set)
! raster[(i + dy) * bpr + (j + dx) / 8] |=
! 1  (7 - (j + dx) % 8);
  }
  }
  }
--- 600,643 
  bpr = (((wd + (instance-bmfmt.glyph3) - 1)  3)  
 -instance-bmfmt.glyph);
  if(tgp) {
! raster = (char*)xalloc(ht * bpr);
  if(raster == NULL) 
  return AllocError;
! memset(raster, 0, ht * bpr);
  }
  
  if(dx == 0  dy == 0  bpr == bitmap-pitch) {
!   size_t cpy_size=bitmap-rows * bitmap-pitch;
!   if( ht*bpr  cpy_size ) cpy_size=ht*bpr;
! memcpy(raster, bitmap-buffer, cpy_size);
  } else if(dx == 0) {
! for(i = MAX(0, -dy); i  bitmap-rows  i + dy  ht; i++){
!   int cpy_begin=(i + dy) * bpr;
!   size_t cpy_size=bitmap-pitch;
!   if( cpy_begin  ht*bpr ){
!   if( ht*bpr  cpy_begin+cpy_size ){
!   cpy_size = ht*bpr-cpy_begin;
!   }
!   memcpy(raster + cpy_begin,
!  bitmap-buffer + i * bitmap-pitch,
!  cpy_size);
!   }
!   }
  } else {
  for(i = MAX(0, -dy); i  bitmap-rows  i + dy  ht; i++) {
  for(j = MAX(0, -dx); j  bitmap-width  j + dx  wd; j++) {
  int set;
  set = (bitmap-buffer[i * bitmap-pitch + j / 8] 
 1  (7 - j % 8));
! if(set){
!   int target = (i + dy) * bpr + (j + dx) / 8;
!   if( target  ht*bpr ){
!   raster[target] |= 1  (7 - (j + dx) % 8);
!   }
!   else{
!   break;
!   }
!   }
  }
  }
  }
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] A serious problem about freetype module

2003-02-08 Thread Chisato Yamauchi 
  Ok.

  This problem is buffer overflow fundamentally.  By applying
the following patch, the crash is avoidable.

*** xc/lib/font/FreeType/ftfuncs.c.orig 2002-10-03 00:06:12.0 +0900
--- xc/lib/font/FreeType/ftfuncs.c  2003-02-08 15:45:38.0 +0900
***
*** 600,609 
  bpr = (((wd + (instance-bmfmt.glyph3) - 1)  3)  
 -instance-bmfmt.glyph);
  if(tgp) {
! raster = (char*)xalloc(ht * bpr);
  if(raster == NULL) 
  return AllocError;
! memset(raster, 0, ht * bpr);
  }
  
  if(dx == 0  dy == 0  bpr == bitmap-pitch) {
--- 600,609 
  bpr = (((wd + (instance-bmfmt.glyph3) - 1)  3)  
 -instance-bmfmt.glyph);
  if(tgp) {
! raster = (char*)xalloc((ht+2) * bpr);
  if(raster == NULL) 
  return AllocError;
! memset(raster, 0, (ht+2) * bpr);
  }
  
  if(dx == 0  dy == 0  bpr == bitmap-pitch) {


  Not (ht+2) but (ht+1) may be more appropriate.  However, I
think that (ht+2) is safer.  Since the calculation of metric
may be wrong.

  I'd like the maintainer of freetype module to investigate
in detail.


Chisato Yamauchi
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] A serious problem about freetype module

2003-02-08 Thread Chisato Yamauchi 
 Can you reproduce this bug with ftview?
 

  No.

  I don't know how to view 2-bytes fonts with ftview.
This crash occurs only with jisx0208.1983 rgstry.
I also confirmed the crash with xfd.


Chisato Yamauchi
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts] A serious problem about freetype module

2003-02-07 Thread Chisato Yamauchi 
  Hi,

  There is a serious problem about freetype module in
XFree86-4.2.99.901.

  If 18-pixels of kochi-mincho.ttf (a famous Japanese font) 
is selected using xfontsel with jisx0208.1983, the X
server crashes.

  I investigated this problem a little.  This crash does not
occur when displaying embedded bitmap of kochi-mincho.ttf.
When the size of the font is 18 pixels or over, X crashes.

  Furthermore, according to my investigation, this crash 
occurs with the following code of ftfuncs.c.

ftrc = FT_Load_Glyph(instance-face-face, idx, 
 FT_LOAD_RENDER | FT_LOAD_MONOCHROME);


  This function seems not to be used in the old freetype 
module and xtt module.  This problem does not occurs in the 
old freetype module, and xtt module.  


  kochi-mincho.ttf is acquirable from the following.

  http://www.a.phys.nagoya-u.ac.jp/~cyamauch/kochi-mincho.ttf.gz

  And the fonts.dir is here.

kochi-mincho.ttf -kochi-mincho-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0


  First, please confirm this problem.  Thanks.


Chisato Yamauchi
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts