Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> > gray2 and gray4 are not supported now. I'll see if I can add > > support to them. If I can't, I'll submit a patch to update the > > documentation :) > > Ok, this patch should fix the problem. Indeed, it does. Thanks again for your efforts. I've applied your patch. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Mon, May 30, 2005 at 03:24:30PM +0800, Chia I Wu wrote:
> gray2 and gray4 are not supported now. I'll see if I can add support to them.
> If I can't, I'll submit a patch to update the documentation :)
Ok, this patch should fix the problem. Instead of supporting gray[24]
directly, convertion from gray[24] to gray8 is done before emboldening.
Changelog:
* include/freetype/ftbitmap.h (FT_Bitmap_Embolden): Fix typos.
Update documentaion a little.
* include/freetype/ftoutline.h (FT_Outline_Embolden): Fix typos.
* src/base/ftbitmap.c (FT_Bitmap_Embolden): Add support for bitmap of
pixel_mode FT_PIXEL_MODE_GRAY2 or FT_PIXEL_MODE_GRAY4.
When xstr is larger than 8 and bitmap is of pixel_mode
FT_PIXEL_MODE_MONO, set xstr to 8 instead of returning error.
--
Regards,
olv
=== include/freetype/ftbitmap.h
==
--- include/freetype/ftbitmap.h (/freetype2/trunk) (revision 931)
+++ include/freetype/ftbitmap.h (/freetype2/branches/embolden) (local)
@@ -97,7 +97,7 @@
/*FT_Bitmap_Embolden */
/* */
/* */
- /*Emboldens a bitmap. The new bitmap will be about `xStrength' */
+ /*Embolden a bitmap. The new bitmap will be about `xStrength' */
/*pixels wider and `yStrength' pixels higher. The left and bottom */
/*borders are kept unchanged.*/
/* */
@@ -105,10 +105,10 @@
/*library :: A handle to a library object. */
/* */
/*xStrength :: How strong the glyph is emboldened horizontally. */
- /* Expressed in 16.16 pixel format. */
+ /* Expressed in 26.6 pixel format. */
/* */
/*yStrength :: How strong the glyph is emboldened vertically.*/
- /* Expressed in 16.16 pixel format. */
+ /* Expressed in 26.6 pixel format. */
/* */
/**/
/*bitmap:: A handle to the target bitmap.*/
@@ -118,7 +118,7 @@
/* */
/* */
/*The current implementation restricts `xStrength' to be less than */
- /*or equal to 8. */
+ /*or equal to 8 when bitmap is of pixel_mode @FT_PIXEL_MODE_MONO.*/
/* */
/*Don't embolden the bitmap owned by a @FT_GlyphSlot directly! Call */
/*@FT_Bitmap_Copy to get a copy and work on the copy instead.*/
=== include/freetype/ftoutln.h
==
--- include/freetype/ftoutln.h (/freetype2/trunk) (revision 931)
+++ include/freetype/ftoutln.h (/freetype2/branches/embolden) (local)
@@ -319,7 +319,7 @@
/* */
/**/
/*strength :: How strong the glyph is emboldened. Expressed in */
- /*16.16 pixel format.*/
+ /*26.6 pixel format. */
/* */
/* */
/*FreeType error code. 0 means success. */
=== src/base/ftbitmap.c
==
--- src/base/ftbitmap.c (/freetype2/trunk) (revision 931)
+++ src/base/ftbitmap.c (/freetype2/branches/embolden) (local)
@@ -211,17 +211,45 @@
if ( !library )
return FT_Err_Invalid_Library_Handle;
-if ( !bitmap )
+if ( !bitmap || !bitmap->buffer )
return FT_Err_Invalid_Argument;
xstr = FT_PIX_ROUND( xStrength ) >> 6;
ystr = FT_PIX_ROUND( yStrength ) >> 6;
+if ( xstr == 0 && ystr == 0 )
+ return FT_Err_Ok;
+else if ( xstr < 0 || ystr < 0 )
+ return FT_Err_Invalid_Argument;
+
switch ( bitmap->pixel_mode )
{
case FT_PIXEL_MODE_GRAY2:
case FT_PIXEL_MODE_GRAY4:
- return FT_Err_Invalid_Glyph_Format;
+ {
+FT_Bitmap tmp;
+FT_Int align;
+
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Mon, May 30, 2005 at 08:26:44AM +0200, Werner LEMBERG wrote: > > > This is introduced by the last patch :( > > Hehe, there still seem to be problems :-) The glyphs in the two > attached fonts don't change at all (neither the appearance nor the > advance width) if I check embolding with ftview (not using your > patch). gray2 and gray4 are not supported now. I'll see if I can add support to them. If I can't, I'll submit a patch to update the documentation :) -- Regards, olv ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> I've dirty hacked ftview for testing bitmap emboldening of various > pixel_mode. You can find the hack in the attachments. OK, I won't apply it right now. Maybe you find time to polish your code... Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> Oops, I forgot to adjust emboldening strength in the last ftsynth.c > patch. Please ignore that one. I've applied your patches, thanks. Please test whether everything is fine. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> This is introduced by the last patch :( Hehe, there still seem to be problems :-) The glyphs in the two attached fonts don't change at all (neither the appearance nor the advance width) if I check embolding with ftview (not using your patch). Werner STARTFONT 2.1 COMMENT "Anti-aliased test font." COMMENT "It uses the BDF of Mark Leisher's xmbdfed package" FONT -Misc-Fixed-Medium-R-Normal--20-200-75-75-C-100-ISO10646-1 SIZE 20 75 75 4 FONTBOUNDINGBOX 10 20 0 -4 STARTPROPERTIES 19 FONTNAME_REGISTRY "" FOUNDRY "Misc" FAMILY_NAME "Fixed" WEIGHT_NAME "Medium" SLANT "R" SETWIDTH_NAME "Normal" ADD_STYLE_NAME "" PIXEL_SIZE 20 POINT_SIZE 200 RESOLUTION_X 75 RESOLUTION_Y 75 SPACING "C" AVERAGE_WIDTH 100 CHARSET_REGISTRY "ISO10646" CHARSET_ENCODING "1" DEFAULT_CHAR 65534 FONT_DESCENT 4 FONT_ASCENT 16 COPYRIGHT "Public domain font. Share and enjoy." ENDPROPERTIES CHARS 1 STARTCHAR char0 ENCODING 0 SWIDTH 480 0 DWIDTH 10 0 BBX 10 20 0 -4 BITMAP 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD 0134679ACD ENDCHAR ENDFONT STARTFONT 2.1 COMMENT "Anti-aliased test font." COMMENT "It uses the BDF of Mark Leisher's xmbdfed package" FONT -Misc-Fixed-Medium-R-Normal--20-200-75-75-C-100-ISO10646-1 SIZE 20 75 75 2 FONTBOUNDINGBOX 17 20 0 -4 STARTPROPERTIES 19 FONTNAME_REGISTRY "" FOUNDRY "Misc" FAMILY_NAME "Fixed" WEIGHT_NAME "Medium" SLANT "R" SETWIDTH_NAME "Normal" ADD_STYLE_NAME "" PIXEL_SIZE 20 POINT_SIZE 200 RESOLUTION_X 75 RESOLUTION_Y 75 SPACING "C" AVERAGE_WIDTH 100 CHARSET_REGISTRY "ISO10646" CHARSET_ENCODING "1" DEFAULT_CHAR 65534 FONT_DESCENT 4 FONT_ASCENT 16 COPYRIGHT "Public domain font. Share and enjoy." ENDPROPERTIES CHARS 1 STARTCHAR char0 ENCODING 0 SWIDTH 480 0 DWIDTH 10 0 BBX 13 20 0 -4 BITMAP 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 05AFA580 ENDCHAR ENDFONT ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Sat, May 28, 2005 at 03:47:49PM +0200, Werner LEMBERG wrote:
>
> > This patch fixes some bugs in FT_Bitmap_Embolden.
>
> Applied, thanks. I think there is still a bug for graymap fonts.
> Have a look at the attached test glyph. Emboldening produces a
> strange result.
Oops, I forgot to adjust emboldening strength in the last ftsynth.c
patch. Please ignore that one.
These changes are suggested by some brave testers.
Changelog:
ft2-ftsynth-advance-fix2.patch:
* src/base/ftsynth.c (FT_GlyphSlot_Embolden): Modify slot->advance
accordingly.
More suited emboldening strength.
--
Regards,
olv
=== src/base/ftsynth.c
==
--- src/base/ftsynth.c (/freetype2/trunk) (revision 923)
+++ src/base/ftsynth.c (/freetype2/branches/embolden) (local)
@@ -81,7 +81,7 @@
/* some reasonable strength */
xstr = FT_MulFix( face->units_per_EM,
- face->size->metrics.y_scale ) / 32;
+ face->size->metrics.y_scale ) / 42;
ystr = xstr;
if ( slot->format == FT_GLYPH_FORMAT_OUTLINE )
@@ -122,6 +122,9 @@
/* modify the metrics accordingly */
if ( !error )
{
+ slot->advance.x += xstr;
+ slot->advance.y += ystr;
+
slot->metrics.width+= xstr;
slot->metrics.height += ystr;
slot->metrics.horiBearingY += ystr;
Property changes on:
___
Name: svk:merge
+5f392c16-9bf0-0310-b16c-a65848a4e34f:/freetype2/trunk:921
___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Sat, May 28, 2005 at 03:47:49PM +0200, Werner LEMBERG wrote:
>
> > This patch fixes some bugs in FT_Bitmap_Embolden.
>
> Applied, thanks. I think there is still a bug for graymap fonts.
> Have a look at the attached test glyph. Emboldening produces a
> strange result.
This is introduced by the last patch :(
I've dirty hacked ftview for testing bitmap emboldening of various
pixel_mode. You can find the hack in the attachments.
For testing, launch ftview with outline font and press 'c' to disable
cache first. Then you can use 'l' to switch between normal/emboldened
mode, and 'L' to rotate between LCD modes. I hope this would help bug
hunting the bitmap emboldening algorithm (and help me not send buggy
patches).
Anyway, here's the changelog:
ft2-bitmap-embolden-fix2.patch
* src/base/ftbitmap.c (FT_Bitmap_Embolden): Fix emboldening bitmap of
mode FT_PIXEL_MODE_GRAY. Also add support for mode FT_PIXEL_MODE_LCD
and FT_PIXEL_MODE_LCD_V.
(ft_bitmap_assure_buffer): FT_PIXEL_MODE_LCD and FT_PIXEL_MODE_LCD_V
should have ppb (pixel per byte) 1.
Zero the padding when there's no need to allocate memory.
ft2-ftsynth-advance.patch
* src/base/ftsynth.c (FT_GlyphSlot_Embolden): Modify slot->advance
accordingly.
--
Regards,
olv
=== src/base/ftbitmap.c
==
--- src/base/ftbitmap.c (/freetype2/trunk) (revision 923)
+++ src/base/ftbitmap.c (/freetype2/branches/embolden) (local)
@@ -115,8 +115,6 @@
switch ( bitmap->pixel_mode )
{
case FT_PIXEL_MODE_MONO:
-case FT_PIXEL_MODE_LCD:
-case FT_PIXEL_MODE_LCD_V:
ppb = 8;
break;
case FT_PIXEL_MODE_GRAY2:
@@ -126,15 +124,44 @@
ppb = 2;
break;
case FT_PIXEL_MODE_GRAY:
+case FT_PIXEL_MODE_LCD:
+case FT_PIXEL_MODE_LCD_V:
ppb = 1;
break;
default:
return FT_Err_Invalid_Glyph_Format;
}
-/* check whether we must allocate memory */
+/* if no need to allocate memory */
if ( ypixels == 0 && pitch * ppb >= bitmap->width + xpixels )
+{
+ /* zero the padding */
+ for ( i = 0; i < bitmap->rows; i++ )
+ {
+unsigned char* last_byte;
+int bits = xpixels * ( 8 / ppb );
+int mask = 0;
+
+
+last_byte = bitmap->buffer + i * pitch + ( bitmap->width - 1 ) / ppb;
+
+if ( bits >= 8 )
+{
+ FT_MEM_ZERO( last_byte + 1, bits / 8 );
+ bits %= 8;
+}
+
+if ( bits > 0 )
+{
+ while ( bits-- > 0 )
+mask |= 1 << bits;
+
+ *last_byte &= ~mask;
+}
+ }
+
return FT_Err_Ok;
+}
new_pitch = ( bitmap->width + xpixels + ppb - 1 ) / ppb;
@@ -187,16 +214,22 @@
if ( !bitmap )
return FT_Err_Invalid_Argument;
+xstr = FT_PIX_ROUND( xStrength ) >> 6;
+ystr = FT_PIX_ROUND( yStrength ) >> 6;
+
switch ( bitmap->pixel_mode )
{
case FT_PIXEL_MODE_GRAY2:
case FT_PIXEL_MODE_GRAY4:
return FT_Err_Invalid_Glyph_Format;
+case FT_PIXEL_MODE_LCD:
+ xstr *= 3;
+ break;
+case FT_PIXEL_MODE_LCD_V:
+ ystr *= 3;
+ break;
}
-xstr = FT_PIX_ROUND( xStrength ) >> 6;
-ystr = FT_PIX_ROUND( yStrength ) >> 6;
-
if ( xstr == 0 && ystr == 0 )
return FT_Err_Ok;
else if ( xstr < 0 || ystr < 0 || xstr > 8 )
@@ -245,19 +278,19 @@
break;
#endif
}
- else if ( bitmap->pixel_mode == FT_PIXEL_MODE_GRAY )
+ else
{
if ( x - i >= 0 )
{
- if ( p[x] + p[x - i] > bitmap->num_grays )
+ if ( p[x] + p[x - i] > bitmap->num_grays - 1 )
{
-p[x] = bitmap->num_grays;
+p[x] = bitmap->num_grays - 1;
break;
}
else
{
p[x] += p[x - i];
-if ( p[x] == bitmap->num_grays )
+if ( p[x] == bitmap->num_grays - 1 )
break;
}
}
=== src/ftcommon.i
==
--- src/ftcommon.i (/freetype2/trunk/ft2demos) (revision 923)
+++ src/ftcommon.i (/freetype2/branches/embolden/ft2demos) (local)
@@ -752,6 +752,39 @@
&glyf,
NULL );
+ /* XXX dirty hack for testing bitmap emboldening */
+ if ( glyf->format == FT_GLYPH_FORMAT_OUTLINE )
+ {
+FT_Render_Mode render_mode;
+
+if ( lcd_mode <= 1 )
+ render_mode = FT_RENDER_MODE_NORMAL;
+else if ( lcd_mode <= 3 )
+ render_mode = FT_RENDER_MODE_LCD;
+else
+ render_mode = FT_RENDER_MODE_LCD_V;
+
+if ( !antialias )
+ render_mode = FT_RENDER_MODE_MONO;
+
+/* render the glyph to a bitmap, don't destroy original */
+error = FT_Glyp
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> This patch fixes some bugs in FT_Bitmap_Embolden. Applied, thanks. I think there is still a bug for graymap fonts. Have a look at the attached test glyph. Emboldening produces a strange result. Werner STARTFONT 2.1 COMMENT "Anti-aliased test font." COMMENT "It uses the BDF of Mark Leisher's xmbdfed package" FONT -Misc-Fixed-Medium-R-Normal--20-200-75-75-C-100-ISO10646-1 SIZE 20 75 75 8 FONTBOUNDINGBOX 17 20 0 -4 STARTPROPERTIES 19 FONTNAME_REGISTRY "" FOUNDRY "Misc" FAMILY_NAME "Fixed" WEIGHT_NAME "Medium" SLANT "R" SETWIDTH_NAME "Normal" ADD_STYLE_NAME "" PIXEL_SIZE 20 POINT_SIZE 200 RESOLUTION_X 75 RESOLUTION_Y 75 SPACING "C" AVERAGE_WIDTH 100 CHARSET_REGISTRY "ISO10646" CHARSET_ENCODING "1" DEFAULT_CHAR 65534 FONT_DESCENT 4 FONT_ASCENT 16 COPYRIGHT "Public domain font. Share and enjoy." ENDPROPERTIES CHARS 1 STARTCHAR char0 ENCODING 0 SWIDTH 480 0 DWIDTH 10 0 BBX 8 20 0 -4 BITMAP 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 05AFA58005AFA580 ENDCHAR ENDFONT ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Wed, May 25, 2005 at 07:50:16AM +0200, Werner LEMBERG wrote:
>
> Thanks, applied! Note that I've changed the third and fourth argument
> of FT_Bitmap_Embolden to be normal values, not pointers. Please test.
>
>
> Werner
Hi Werner,
This patch fixes some bugs in FT_Bitmap_Embolden.
ChangeLog:
* src/base/ftbitmap.c (FT_Bitmap_Embolden): fix a bug when pitch is
negative.
fix a bug when pixel_mode is FT_PIXEL_MODE_GRAY and num_gray != 256.
some speed-up when pixel_mode is FT_PIXEL_MODE_GRAY.
(ft_bitmap_assure_buffer): accept FT_PIXEL_MODE_LCD and
FT_PIXEL_MODE_LCD_V.
--
Regards,
olv
=== src/base/ftbitmap.c
==
--- src/base/ftbitmap.c (revision 909)
+++ src/base/ftbitmap.c (local)
@@ -115,6 +115,8 @@
switch ( bitmap->pixel_mode )
{
case FT_PIXEL_MODE_MONO:
+case FT_PIXEL_MODE_LCD:
+case FT_PIXEL_MODE_LCD_V:
ppb = 8;
break;
case FT_PIXEL_MODE_GRAY2:
@@ -210,7 +212,7 @@
else
{
pitch = -pitch;
- p = bitmap->buffer + pitch * ( bitmap->rows - ystr - 1 );
+ p = bitmap->buffer + pitch * ( bitmap->rows - 1 );
}
/* for each row */
@@ -237,16 +239,30 @@
/* the maximum value of 8 for `xstr' comes from here */
if ( x > 0 )
p[x] |= p[x - 1] << ( 8 - i );
+
+#if 0
+if ( p[x] == 0xff )
+ break;
+#endif
}
else if ( bitmap->pixel_mode == FT_PIXEL_MODE_GRAY )
{
if ( x - i >= 0 )
{
- if ( p[x] + p[x - i] > 0xff )
-p[x] = 0xff;
+ if ( p[x] + p[x - i] > bitmap->num_grays )
+ {
+p[x] = bitmap->num_grays;
+break;
+ }
else
+ {
p[x] += p[x - i];
+if ( p[x] == bitmap->num_grays )
+ break;
+ }
}
+else
+ break;
}
}
}
___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> There is one stupid bug in the last patch. Please apply this one. Applied, thanks. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> > [...] you can see that the glyphs get fatter and fatter. > Thanks for testing. The attached patch should fix the problem. Applied, 謝謝你. > (Changelog entry included. You may need to change the date.) It's better to include the ChangeLog entry in the mail instead of the patch. In case someone else has added a different patch, the ChangeLog chunk will fail. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Thu, May 26, 2005 at 05:25:33PM +0800, Chia I Wu wrote:
> On Thu, May 26, 2005 at 07:32:49AM +0200, Werner LEMBERG wrote:
> > Anyway, there is a bug, either in your emboldening code or in ftview.
> > Load the attached font with
> >
> > ftview 15 Chicago.12.bdf
> >
> > then press the space key, arrow up, arrow down, arrow up, arrow down,
> > etc., and you can see that the glyphs get fatter and fatter.
> Thanks for testing. The attached patch should fix the problem.
> (Changelog entry included. You may need to change the date.)
>
> This happens when slot is not bitmap-owner (like this case of bdf font).
> I also make the metrics always being modified in this patch, as those
> who want more control should use FT_{Bitmap,Outline}_Embolden instead.
There is one stupid bug in the last patch. Please apply this one.
Sorry for the inconvenience.
--
Regards,
olv
=== ChangeLog
==
--- ChangeLog (/freetype2/trunk) (revision 904)
+++ ChangeLog (/freetype2/branches/embolden) (local)
@@ -1,3 +1,12 @@
+2005-05-26 Chia I Wu <[EMAIL PROTECTED]>
+
+ * include/freetype/ftbitmap.h (FT_Bitmap_Embolden): Improve
+ documentation.
+
+ * src/base/ftsynth.c: Remove macro FT_BOLD_THRESHOLD.
+ (FT_GlyphSlot_Embolden): Check whether slot is bitmap-owner.
+ Always modify the metrics.
+
2005-05-24 Werner Lemberg <[EMAIL PROTECTED]>
* docs/CHANGES: Updated.
=== include/freetype/ftbitmap.h
==
--- include/freetype/ftbitmap.h (/freetype2/trunk) (revision 904)
+++ include/freetype/ftbitmap.h (/freetype2/branches/embolden) (local)
@@ -118,6 +118,10 @@
/*The current implementation restricts `xStrength' to be less than */
/*or equal to 8. */
/* */
+ /*Don't embolden the bitmap owned by a @FT_GlyphSlot. Call */
+ /*@FT_Bitmap_Copy to get a copy and work on the copy.*/
+ /* */
+ /* */
FT_EXPORT_DEF( FT_Error )
FT_Bitmap_Embolden( FT_Library library,
FT_Bitmap* bitmap,
=== src/base/ftsynth.c
==
--- src/base/ftsynth.c (/freetype2/trunk) (revision 904)
+++ src/base/ftsynth.c (/freetype2/branches/embolden) (local)
@@ -23,7 +23,6 @@
#include FT_BITMAP_H
-#define FT_BOLD_THRESHOLD 0x0100
/*/
@@ -78,8 +77,8 @@
{
FT_Library library = slot->library;
FT_Face face= FT_SLOT_FACE( slot );
+FT_Errorerror = FT_Err_Ok;
FT_Pos xstr, ystr;
-FT_Errorerror;
/* some reasonable strength */
@@ -90,7 +89,7 @@
if ( slot->format == FT_GLYPH_FORMAT_OUTLINE )
{
error = FT_Outline_Embolden( &slot->outline, xstr );
- xstr = ( xstr * 4 ) & ~63;
+ xstr = xstr * 4 ; /* according to the document */
ystr = xstr;
}
else if ( slot->format == FT_GLYPH_FORMAT_BITMAP )
@@ -100,25 +99,41 @@
xstr = 1 << 6;
ystr = FT_PIX_FLOOR( ystr );
- error = FT_Bitmap_Embolden( library, &slot->bitmap, xstr, ystr );
+ /* slot must be bitmap-owner */
+ if ( !(slot->internal->flags & FT_GLYPH_OWN_BITMAP) )
+ {
+FT_Bitmap bitmap;
- /* XXX should we set these? */
+
+FT_Bitmap_New( &bitmap );
+error = FT_Bitmap_Copy( library, &slot->bitmap, &bitmap );
+
+if ( !error )
+{
+ slot->bitmap = bitmap;
+ slot->internal->flags |= FT_GLYPH_OWN_BITMAP;
+}
+ }
+
if ( !error )
-slot->bitmap_top += ystr >> 6;
+error = FT_Bitmap_Embolden( library, &slot->bitmap, xstr, ystr );
}
else
error = FT_Err_Invalid_Argument;
-/* XXX should we set these? */
+/* modify the metrics accordingly */
if ( !error )
{
-#if 0
- slot->advance.x+= xstr;
slot->metrics.width+= xstr;
slot->metrics.height += ystr;
slot->metrics.horiBearingY += ystr;
-#endif
slot->metrics.horiAdvance += xstr;
+ slot->metrics.vertBearingX -= xstr / 2;
+ slot->metrics.vertBearingY += ystr;
+ slot->metrics.vertAdvance += ystr;
+
+ if ( slot->format == FT_GLYPH_FORMAT_BITMAP )
+slot->bitmap_top += ystr >> 6;
}
}
Property changes on:
___
Name: svk:merge
+5f392c16-9bf0-0310-b16c-a65848a4e34f:/freetype2/trunk:903
___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mail
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Thu, May 26, 2005 at 07:32:49AM +0200, Werner LEMBERG wrote:
> Anyway, there is a bug, either in your emboldening code or in ftview.
> Load the attached font with
>
> ftview 15 Chicago.12.bdf
>
> then press the space key, arrow up, arrow down, arrow up, arrow down,
> etc., and you can see that the glyphs get fatter and fatter.
Thanks for testing. The attached patch should fix the problem.
(Changelog entry included. You may need to change the date.)
This happens when slot is not bitmap-owner (like this case of bdf font).
I also make the metrics always being modified in this patch, as those
who want more control should use FT_{Bitmap,Outline}_Embolden instead.
--
Regards,
olv
=== ChangeLog
==
--- ChangeLog (/freetype2/trunk) (revision 904)
+++ ChangeLog (/freetype2/branches/embolden) (local)
@@ -1,3 +1,12 @@
+2005-05-26 Chia I Wu <[EMAIL PROTECTED]>
+
+ * include/freetype/ftbitmap.h (FT_Bitmap_Embolden): Improve
+ documentation.
+
+ * src/base/ftsynth.c: Remove macro FT_BOLD_THRESHOLD.
+ (FT_GlyphSlot_Embolden): Check whether slot is bitmap-owner.
+ Always modify the metrics.
+
2005-05-24 Werner Lemberg <[EMAIL PROTECTED]>
* docs/CHANGES: Updated.
=== include/freetype/ftbitmap.h
==
--- include/freetype/ftbitmap.h (/freetype2/trunk) (revision 904)
+++ include/freetype/ftbitmap.h (/freetype2/branches/embolden) (local)
@@ -118,6 +118,10 @@
/*The current implementation restricts `xStrength' to be less than */
/*or equal to 8. */
/* */
+ /*Don't embolden the bitmap owned by a @FT_GlyphSlot. Call */
+ /*@FT_Bitmap_Copy to get a copy and work on the copy.*/
+ /* */
+ /* */
FT_EXPORT_DEF( FT_Error )
FT_Bitmap_Embolden( FT_Library library,
FT_Bitmap* bitmap,
=== src/base/ftsynth.c
==
--- src/base/ftsynth.c (/freetype2/trunk) (revision 904)
+++ src/base/ftsynth.c (/freetype2/branches/embolden) (local)
@@ -23,7 +23,6 @@
#include FT_BITMAP_H
-#define FT_BOLD_THRESHOLD 0x0100
/*/
@@ -90,7 +89,7 @@
if ( slot->format == FT_GLYPH_FORMAT_OUTLINE )
{
error = FT_Outline_Embolden( &slot->outline, xstr );
- xstr = ( xstr * 4 ) & ~63;
+ xstr = xstr * 4 ; /* according to the document */
ystr = xstr;
}
else if ( slot->format == FT_GLYPH_FORMAT_BITMAP )
@@ -100,25 +99,41 @@
xstr = 1 << 6;
ystr = FT_PIX_FLOOR( ystr );
- error = FT_Bitmap_Embolden( library, &slot->bitmap, xstr, ystr );
+ /* slot must be bitmap-owner */
+ if ( !(slot->internal->flags & FT_GLYPH_OWN_BITMAP) )
+ {
+FT_Bitmap bitmap;
- /* XXX should we set these? */
+
+FT_Bitmap_New( &bitmap );
+error = FT_Bitmap_Copy( library, &slot->bitmap, &bitmap );
+
+if ( !error )
+{
+ slot->bitmap = bitmap;
+ slot->internal->flags |= FT_GLYPH_OWN_BITMAP;
+}
+ }
+
if ( !error )
-slot->bitmap_top += ystr >> 6;
+error = FT_Bitmap_Embolden( library, &slot->bitmap, xstr, ystr );
}
else
error = FT_Err_Invalid_Argument;
-/* XXX should we set these? */
+/* modify the metrics accordingly */
if ( !error )
{
-#if 0
- slot->advance.x+= xstr;
slot->metrics.width+= xstr;
slot->metrics.height += ystr;
slot->metrics.horiBearingY += ystr;
-#endif
slot->metrics.horiAdvance += xstr;
+ slot->metrics.vertBearingX -= xstr / 2;
+ slot->metrics.vertBearingY += ystr;
+ slot->metrics.vertAdvance += ystr;
+
+ if ( slot->format == FT_GLYPH_FORMAT_BITMAP )
+slot->bitmap_top += ystr >> 6;
}
}
Property changes on:
___
Name: svk:merge
+5f392c16-9bf0-0310-b16c-a65848a4e34f:/freetype2/trunk:903
___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> I tried to make this patch elegant, but, well, ftview.c needs > refactoring. Thanks a lot! It's now in the CVS. And a special thank you to you for obeying or strange formatting rules :-) Anyway, there is a bug, either in your emboldening code or in ftview. Load the attached font with ftview 15 Chicago.12.bdf then press the space key, arrow up, arrow down, arrow up, arrow down, etc., and you can see that the glyphs get fatter and fatter. Werner Chicago.12.bdf.bz2 Description: Binary data ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Wed, May 25, 2005 at 07:54:56AM +0200, Werner LEMBERG wrote:
>
> > > I'm unfamiliar with this API and never checked the bolden result
> > > in detail, could you show some demo program?
> >
> > I've made a quick hack to ftview.c for demo. See applied patch.
>
> Can you update this patch too, please? This is, add emboldening to
> the rendering mode cycle.
>
>
> Werner
I tried to make this patch elegant, but, well, ftview.c needs
refactoring.
Most codes of Render_Embolden are copied from Render_Stroke.
--
Regards,
olv
=== src/ftcommon.i
==
--- src/ftcommon.i (revision 901)
+++ src/ftcommon.i (local)
@@ -19,6 +19,7 @@
#include FT_STROKER_H
#include FT_BITMAP_H
+#include FT_SYNTHESIS_H
/* the following header shouldn't be used in normal programs */
#include FT_INTERNAL_DEBUG_H
@@ -79,7 +80,15 @@
int graph_init = 0;
double the_gamma = 1.0;
- int render_mode = 0;
+ enum {
+RENDER_MODE_ALL = 0,
+RENDER_MODE_EMBOLDEN,
+RENDER_MODE_STROKE,
+RENDER_MODE_TEXT,
+RENDER_MODE_WATERFALL,
+RENDER_MODE_GAMMAGRID /* this mode must be the last one */
+ } render_mode = 0;
+
int debug = 0;
int trace_level = 0;
=== src/ftview.c
==
--- src/ftview.c (revision 901)
+++ src/ftview.c (local)
@@ -191,7 +191,105 @@
return error;
}
+
+ /* most codes are copied from Render_Stroke */
static FT_Error
+ Render_Embolden( int first_index )
+ {
+FT_F26Dot6 start_x, start_y, step_x, step_y, x, y;
+FTC_ScalerRec scaler;
+inti;
+grBitmap bit3;
+
+
+start_x = 4;
+start_y = 16 + current_font.height;
+
+
+scaler.face_id = current_font.face_id;
+scaler.width = current_font.width;
+scaler.height = current_font.height;
+scaler.pixel = 1;
+
+error = FTC_Manager_LookupSize( cache_manager, &scaler, &size );
+if ( error )
+ goto Exit;
+
+step_x = size->metrics.x_ppem + 4;
+step_y = ( size->metrics.height >> 6 ) + 4;
+
+x = start_x;
+y = start_y;
+
+i = first_index;
+i = first_index;
+
+while ( i < face->num_glyphs )
+{
+ int left, top, x_advance, y_advance, x_top, y_top;
+ FT_GlyphSlot slot = size->face->glyph;
+ FT_Glyph glyphp;
+
+#if 0
+ gindex = *(unsigned char*)p;
+ if ( encoding == FT_ENCODING_NONE )
+gindex = get_glyph_index( gindex );
+#endif
+ error = FT_Load_Glyph( size->face, i, FT_LOAD_DEFAULT );
+ if ( !error )
+ {
+FT_Glyph glyphb;
+
+
+FT_GlyphSlot_Embolden( slot );
+error = FT_Get_Glyph( slot, &glyphp );
+if ( error )
+ goto Next;
+
+error = glyph_to_bitmap( glyphp, &bit3, &left, &top,
+ &x_advance, &y_advance, (FT_Pointer*)&glyphb
);
+if ( !error )
+{
+ /* now render the bitmap into the display surface */
+ x_top = x + left;
+ y_top = y - top;
+ grBlitGlyphToBitmap( &bit, &bit3, x_top, y_top, fore_color );
+
+ FT_Done_Glyph( glyphb );
+ FT_Done_Glyph( glyphp );
+
+ x += x_advance + 1;
+
+ if ( x + size->metrics.x_ppem > bit.width )
+ {
+x = start_x;
+y += step_y;
+
+if ( y >= bit.rows )
+ goto Exit;
+ }
+}
+else
+ FT_Done_Glyph( glyphp );
+
+if ( error )
+ goto Next;
+ }
+ else
+ {
+ Next:
+Fail++;
+ }
+
+ i++;
+}
+
+ Exit:
+return error;
+ }
+
+
+ static FT_Error
Render_All( int first_index )
{
FT_F26Dot6 start_x, start_y, step_x, step_y, x, y;
@@ -649,26 +747,32 @@
break;
case grKEY( 'K' ):
- render_mode = 4;
+ render_mode = RENDER_MODE_GAMMAGRID;
new_header = (char*)"rendering gamma grid";
break;
case grKEY( ' ' ):
- render_mode = ( render_mode + 1 ) % 4;
+ render_mode = ( render_mode + 1 ) % RENDER_MODE_GAMMAGRID;
switch ( render_mode )
{
-case 0:
- new_header = (char*)"rendering all glyphs in font";
- break;
-case 1:
- new_header = (char*)"rendering test text string";
- break;
-case 2:
- new_header = (char*)"rendering stroked text";
- break;
-
-default:
- new_header = (char*)"rendering glyph waterfall";
+ case RENDER_MODE_ALL:
+new_header = (char*)"rendering all glyphs in font";
+break;
+ case RENDER_MODE_EMBOLDEN:
+new_header = (char*)"rendering emboldened text";
+break;
+ case RENDER_MODE_STROKE:
+new_header = (char*)"rendering stroked text";
+break;
+ case RENDER_MODE_TEXT:
+new_header = (char*)"rendering test text string";
+break;
+ case
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> > I'm unfamiliar with this API and never checked the bolden result > > in detail, could you show some demo program? > > I've made a quick hack to ftview.c for demo. See applied patch. Can you update this patch too, please? This is, add emboldening to the rendering mode cycle. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> This patch implements FT_Bitmap_Embolden and FT_Outline_Embolden. > It is intended for testing the algorithm and for discussing what > arguments should these function calls take. Since David has fixed the problem (and rejected your modifications because of too great distortions under some circumstances), can you update your patch? > I also make FT_GlyphSlot_Embolden to use these function calls. You > can see it as an example of how applications are gonna use the > function calls and it will eventually be removed. You mean FT_GlyphSlot_Embolden shall not be added to the library? Then I suggest that you add this functionality to ftview instead. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
Hi all, This patch implements FT_Bitmap_Embolden and FT_Outline_Embolden. It is intended for testing the algorithm and for discussing what arguments should these function calls take. Both function calls are documented, and you can read them directly in the patch. I also make FT_GlyphSlot_Embolden to use these function calls. You can see it as an example of how applications are gonna use the function calls and it will eventually be removed. Regards, olv === include/freetype/ftbitmap.h == --- include/freetype/ftbitmap.h (/freetype2/trunk) (revision 240) +++ include/freetype/ftbitmap.h (/freetype2/branches/embolden) (local) @@ -92,6 +92,42 @@ /*/ /* */ /* */ + /*FT_Bitmap_Embolden */ + /* */ + /* */ + /*Emboldens a bitmap. The new bitmap will be about xStrength */ + /*pixels wider and yStrength pixels higher. (The left and bottom */ + /*borders are kept unchanged)*/ + /* */ + /**/ + /*library :: A handle to a library object. */ + /* */ + /**/ + /*bitmap:: A handle to the target bitmap.*/ + /* */ + /*xStrength :: How strong the glyph is emboldened horizontally. */ + /* Expressed in 16.16 pixel format. */ + /* */ + /*yStrength :: How strong the glyph is emboldened vertically.*/ + /* Expressed in 16.16 pixel format. */ + /* */ + /* */ + /*FreeType error code*/ + /* */ + /* */ + /*Current implementation restricts xStrength to be less than or */ + /*equal to 8.*/ + /* */ + FT_EXPORT_DEF( FT_Error ) + FT_Bitmap_Embolden( FT_Library library, + FT_Bitmap* bitmap, + FT_Pos* xStrength, + FT_Pos* yStrength ); + + + /*/ + /* */ + /* */ /*FT_Bitmap_Convert */ /* */ /* */ === include/freetype/ftoutln.h == --- include/freetype/ftoutln.h (/freetype2/trunk) (revision 240) +++ include/freetype/ftoutln.h (/freetype2/branches/embolden) (local) @@ -58,6 +58,7 @@ /*FT_Outline_Copy*/ /*FT_Outline_Translate */ /*FT_Outline_Transform */ + /*FT_Outline_Embolden*/ /*FT_Outline_Reverse */ /*FT_Outline_Check */ /* */ @@ -306,6 +307,33 @@ /*/ /* */ /* */ + /*FT_Outline_Embolden*/ + /* */ + /* */ + /*Emboldens an outline. The new outline will be about xStrength */ + /*
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> Maybe that's not something FreeType library should care, but some > programs that requires precise positioning of glyphs may not want > glyph metrics to be modified in uncontrollable manner. And I think > keeping full-width always to be full-width is the best way for CJK. I fully agree. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> > >I think glyph metrics should be changed automagically. > > > > Umm, yes, so, when fixed-width font is embolded, the result can be > > proportional? I think there are many X applications (terminal emulators > > and curses applications may be typical examples) which assumes/expects > > the Hanzi glyphs are always fixed to full-width, regardless with > > bold/oblique style. Therefore (if i'm not misunderstanding) switch > > to enable/disable changing glyph metrics is required. > > If we don't change glyph metrics accordingly, won't the script be > rendered wrongly (e.g. two glyphs comes too close)? I think "correct result" depends on the script and also on intended use of individual glyphs. For examples, some Japanese font contains various glyphs for '2', '0', '5', each glyphs having full-, half-, third-, or quater- (and proportional) widths. In horizontal text "2005" placed within vertical writing, quater-width glyphs may be used to make "2005" nicely fit into a single vertical line. In this case, the result may be "wrong" for embolded glyphs if composition program does not understand why quater-width version is choosed and if it does not adjust widths as appropriate. (but I think it's ignorable.) Maybe that's not something FreeType library should care, but some programs that requires precise positioning of glyphs may not want glyph metrics to be modified in uncontrollable manner. And I think keeping full-width always to be full-width is the best way for CJK. Regards, Hirata ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Fri, May 20, 2005 at 06:15:15AM +0200, Werner LEMBERG wrote:
>
> > > > As fontconfig and xft already have the code to "embolden" and
> > > > rely on FT_GlyphSlot_Embolden to do the real job, I think
> > > > FT_GlyphSlot_Embolden should be made standard API. This is an
> > > > important feature for Chinese (maybe also Japanese and Korean)
> > > > users, as most Chinese fonts don't have a real bold style.
> >
> > After some more inspection, I find there is already FT_Glyph for
> > glyph manipulation. Then, why not
> >
> > FT_Glyph_Embolden
> > FT_Glyph_Oblique
> > ?
>
> Are these new structures? Do you suggest them because you can't
> modify the public `FT_Glyph'?
They are new function calls.
We already have FT_Glyph_Translate to translate glyphs,
FT_Glyph_Transform to transform glyphs,
FT_Glyph_Stroke to stroke glyphs,
then why not
FT_Glyph_Embolden to embolden glyphs?
>
> > Also I tried to modify the embolden algorithm for outline glyph, and
> > it now uses similar algorithm as the one I use for bitmap glyph.
> > This is done because the old algorithm generates some artifact.
>
> Aah, another user has reported problems. Can you post the patch to
> the freetype-devel list, please?
Check the patch (algorithm only) in the attachment.
Index: src/base/ftsynth.c
===
RCS file: /home/cvs/freetype2/src/base/ftsynth.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ftsynth.c
--- src/base/ftsynth.c 15 May 2005 07:10:28 - 1.1.1.1
+++ src/base/ftsynth.c 20 May 2005 05:24:57 -
@@ -115,7 +115,9 @@
{
FT_Pos d;
FT_Vector in, out;
+#ifdef OLD_ALGORITHM
FT_Fixed scale;
+#endif
FT_Angle angle_diff;
@@ -132,6 +134,7 @@
angle_in = FT_Atan2( in.x, in.y );
angle_out = FT_Atan2( out.x, out.y );
angle_diff = FT_Angle_Diff( angle_in, angle_out );
+#ifdef OLD_ALGORITHM
scale = FT_Cos( angle_diff/2 );
if ( scale < 0x400L && scale > -0x400L )
@@ -148,6 +151,23 @@
outline->points[n].x = v_cur.x + distance + in.x;
outline->points[n].y = v_cur.y + distance + in.y;
+#else
+ angle_diff = angle_in + angle_diff / 2 - rotate;
+ angle_diff = FT_Angle_Diff( 0, angle_diff );
+
+ d = distance * 2; /* strength */
+
+ if ( -FT_ANGLE_PI2 < angle_diff && angle_diff <= 0 ) {
+ outline->points[n].x = v_cur.x + d;
+ }
+ else if ( 0 < angle_diff && angle_diff < FT_ANGLE_PI2 ) {
+ outline->points[n].x = v_cur.x + d;
+ outline->points[n].y = v_cur.y + d;
+ }
+ else if ( FT_ANGLE_PI2 <= angle_diff && angle_diff < FT_ANGLE_PI ) {
+ outline->points[n].y = v_cur.y + d;
+ }
+#endif
v_prev = v_cur;
v_cur = v_next;
___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Fri, May 13, 2005 at 07:51:12AM +0200, Werner LEMBERG wrote: > > > As fontconfig and xft already have the code to "embolden" and rely > > on FT_GlyphSlot_Embolden to do the real job, I think > > FT_GlyphSlot_Embolden should be made standard API. This is an > > important feature for Chinese (maybe also Japanese and Korean) > > users, as most Chinese fonts don't have a real bold style. > > Basically, I don't object, but this won't happen in the next release > which is in pretest stage right now. Sure. After some more inspection, I find there is already FT_Glyph for glyph manipulation. Then, why not FT_Glyph_Embolden FT_Glyph_Oblique ? Also I tried to modify the embolden algorithm for outline glyph, and it now uses similar algorithm as the one I use for bitmap glyph. This is done because the old algorithm generates some artifact. See: http://www.olv.idv.tw/~olvaffe/tmp/freetype2/b-old.png http://www.olv.idv.tw/~olvaffe/tmp/freetype2/b-new.png ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> Considering there is such root of embolding request, I wonder > whether FT_GlyphSlot_Embolden() API is already enough for the > purpose. It does not receive much parameters to control embolding > (am I misunderstanding?). I'm afraid several control parameters are > requested in future, for example: > > * strength to embolding > * switch to enable/disable changing glyph metrics in embolding > * switch to enable/disable embolding of bitmap font > * choosing embolding algorithm I agree. As already said, nothing for 2.1.10. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
> As fontconfig and xft already have the code to "embolden" and rely > on FT_GlyphSlot_Embolden to do the real job, I think > FT_GlyphSlot_Embolden should be made standard API. This is an > important feature for Chinese (maybe also Japanese and Korean) > users, as most Chinese fonts don't have a real bold style. Basically, I don't object, but this won't happen in the next release which is in pretest stage right now. Werner ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Fri, May 13, 2005 at 05:33:54PM +0900, [EMAIL PROTECTED] wrote: > >> * switch to enable/disable changing glyph metrics in embolding > >> * switch to enable/disable embolding of bitmap font > >I think glyph metrics should be changed automagically. > > Umm, yes, so, when fixed-width font is embolded, the result can be > proportional? I think there are many X applications (terminal emulators > and curses applications may be typical examples) which assumes/expects > the Hanzi glyphs are always fixed to full-width, regardless with > bold/oblique style. Therefore (if i'm not misunderstanding) switch > to enable/disable changing glyph metrics is required. > If we don't change glyph metrics accordingly, won't the script be rendered wrongly (e.g. two glyphs comes too close)? I think we should always keep glyph metrics correct, i.e. since "width", "height", "bearings" are changed, we should keep it up-to-date. Then there leaves some flexibility in "advance". I don't know how applications determine whether a font is monospace or not. Fontconfig uses "advance" to do so and I think it's reasonable. So maybe we can let user set whether they want fixed advance or not. > >Bitmap glyph should be emboldened automatically too. > >As we are synthesizing, you know you can't expect a high-quality result, > >thus it makes no difference which format the glyph is in. > > Yet I've not tested in detail, I have no strong objection at present. > One of my anxiety is: in some UCS collective fonts, bitmap data is > provided to partial glyphs. For example, TrueType font bundled in AIX > has bitmap data for Hanzi, but no bitmap data for Bopomofo. You are worrying about inconsistency? When one tries to embolden a mixed sequence of both outline and bitmap glyphs, yes, he gets inconsistency , since we use different algorithms for both kinds of glyphs. But if we embolden only outline glyphs, he still gets inconsistency. Furthermore, we are not forcing he to embolden every glyph. He can just skip bitmap glyphs. > > >> * choosing embolding algorithm > >> > >BTW, I have done some experiment to embolden a bitmap glyph, by printing > >the same glyph severial times (depending on strength), with starting > >point shift to the right by 1 pixel each time. The result is ok. > > How do you think of embolding procedure for high-resolution output > (like printing device) and vector device? Well, I don't know how that work. Does it make a big difference? (I am really asking :P) > > Regards, > mpsuzuki ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Fri, 13 May 2005 14:52:24 +0800 Chia I Wu <[EMAIL PROTECTED]> wrote: >On Fri, May 13, 2005 at 11:44:59AM +0900, [EMAIL PROTECTED] wrote: >> I'm unfamiliar with this API and never checked the bolden result in >> detail, could you show some demo program? >I've made a quick hack to ftview.c for demo. See applied patch. Great Thank you, soon I will test it. >> As you pointed out, most CJK font family does not provide "bold" style. >> I think "weight" (XXX-Light, XXX-Medium, XXX-Heavy etc) - may take >> similar role of it in the typographical viewpoint. >But no application take advantage of that to get better quality. >Also, the size of a Chinese font is very large, ranaging from 5MB to >25MB (the 25MB one includes glyphs of both traditional and simplicial >Chinese). I personally prefer synthesized bold than having all those >weights installed. Yes, I think your comment is exactly right in the viewpoint of desktop window systems and application on them. And, I suppose standardizing embolding API is not harmful against other FreeType functionalities. >> Considering there is such root of embolding request, I wonder whether >> FT_GlyphSlot_Embolden() API is already enough for the purpose. It does >> not receive much parameters to control embolding (am I misunderstanding?). >> I'm afraid several control parameters are requested in future, for example: >> >> * strength to embolding >I think this is important. >> * switch to enable/disable changing glyph metrics in embolding >> * switch to enable/disable embolding of bitmap font >I think glyph metrics should be changed automagically. Umm, yes, so, when fixed-width font is embolded, the result can be proportional? I think there are many X applications (terminal emulators and curses applications may be typical examples) which assumes/expects the Hanzi glyphs are always fixed to full-width, regardless with bold/oblique style. Therefore (if i'm not misunderstanding) switch to enable/disable changing glyph metrics is required. >Bitmap glyph should be emboldened automatically too. >As we are synthesizing, you know you can't expect a high-quality result, >thus it makes no difference which format the glyph is in. Yet I've not tested in detail, I have no strong objection at present. One of my anxiety is: in some UCS collective fonts, bitmap data is provided to partial glyphs. For example, TrueType font bundled in AIX has bitmap data for Hanzi, but no bitmap data for Bopomofo. >> * choosing embolding algorithm >> >BTW, I have done some experiment to embolden a bitmap glyph, by printing >the same glyph severial times (depending on strength), with starting >point shift to the right by 1 pixel each time. The result is ok. How do you think of embolding procedure for high-resolution output (like printing device) and vector device? Regards, mpsuzuki ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Fri, May 13, 2005 at 11:44:59AM +0900, [EMAIL PROTECTED] wrote:
> Hi
>
> On Thu, 12 May 2005 23:44:11 +0800
> Chia I Wu <[EMAIL PROTECTED]> wrote:
> >As fontconfig and xft already have the code to "embolden" and rely on
> >FT_GlyphSlot_Embolden to do the real job, I think FT_GlyphSlot_Embolden
> >should be made standard API. This is an important feature for Chinese
> >(maybe also Japanese and Korean) users, as most Chinese fonts don't have
> >a real bold style.
> >
> >What do you think?
>
> I'm unfamiliar with this API and never checked the bolden result in
> detail, could you show some demo program?
I've made a quick hack to ftview.c for demo. See applied patch.
>
> As you pointed out, most CJK font family does not provide "bold" style.
> I think "weight" (XXX-Light, XXX-Medium, XXX-Heavy etc) - may take
> similar role of it in the typographical viewpoint. But, most personal
> computers are shipped with only 1 or 2 fonts for each CJK scripts,
> and synthesized "bold" is often used in documents generated by PC.
The only commercial fonts I own are Dynaware's. They have severial
weights for each family, named by XXX-W3, XXX-W4, XXX-W5, etc. But no
application take advantage of that to get better quality.
Also, the size of a Chinese font is very large, ranaging from 5MB to
25MB (the 25MB one includes glyphs of both traditional and simplicial
Chinese). I personally prefer synthesized bold than having all those
weights installed.
>
> Considering there is such root of embolding request, I wonder whether
> FT_GlyphSlot_Embolden() API is already enough for the purpose. It does
> not receive much parameters to control embolding (am I misunderstanding?).
> I'm afraid several control parameters are requested in future, for example:
>
> * strength to embolding
I think this is important.
> * switch to enable/disable changing glyph metrics in embolding
> * switch to enable/disable embolding of bitmap font
I think glyph metrics should be changed automagically. Bitmap glyph
should be emboldened automatically too. As we are synthesizing, you know
you can't expect a high-quality result, thus it makes no difference
which format the glyph is in.
> * choosing embolding algorithm
>
BTW, I have done some experiment to embolden a bitmap glyph, by printing
the same glyph severial times (depending on strength), with starting
point shift to the right by 1 pixel each time. The result is ok.
> How do you think of?
>
> Regards,
> mpsuzuki
Index: src/ftview.c
===
RCS file: /cvsroot/freetype/ft2demos/src/ftview.c,v
retrieving revision 1.58
diff -u -r1.58 ftview.c
--- src/ftview.c4 Mar 2005 05:58:35 - 1.58
+++ src/ftview.c13 May 2005 06:06:25 -
@@ -131,20 +131,23 @@
gindex = get_glyph_index( gindex );
#endif
error = FT_Load_Glyph( size->face, i, FT_LOAD_NO_BITMAP );
- if ( !error && slot->format == FT_GLYPH_FORMAT_OUTLINE )
+ if ( !error )
{
FT_Glyph glyphb;
+FT_GlyphSlot_Embolden( slot);
error = FT_Get_Glyph( slot, &glyphp );
if ( error )
goto Next;
+ /*
error = FT_Glyph_Stroke( &glyphp, stroker, 1 );
if ( error )
{
FT_Done_Glyph( glyphp );
goto Next;
}
+ */
error = glyph_to_bitmap( glyphp, &bit3, &left, &top,
&x_advance, &y_advance, (FT_Pointer*)&glyphb
);
@@ -654,7 +657,8 @@
break;
case grKEY( ' ' ):
- render_mode = ( render_mode + 1 ) % 4;
+ //render_mode = ( render_mode + 1 ) % 4;
+ render_mode = (render_mode == 0) ? 2 : 0;
switch ( render_mode )
{
case 0:
@@ -664,9 +668,8 @@
new_header = (char*)"rendering test text string";
break;
case 2:
- new_header = (char*)"rendering stroked text";
+ new_header = (char*)"rendering emboldened text";
break;
-
default:
new_header = (char*)"rendering glyph waterfall";
}
___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
Hi On Thu, 12 May 2005 23:44:11 +0800 Chia I Wu <[EMAIL PROTECTED]> wrote: >As fontconfig and xft already have the code to "embolden" and rely on >FT_GlyphSlot_Embolden to do the real job, I think FT_GlyphSlot_Embolden >should be made standard API. This is an important feature for Chinese >(maybe also Japanese and Korean) users, as most Chinese fonts don't have >a real bold style. > >What do you think? I'm unfamiliar with this API and never checked the bolden result in detail, could you show some demo program? As you pointed out, most CJK font family does not provide "bold" style. I think "weight" (XXX-Light, XXX-Medium, XXX-Heavy etc) - may take similar role of it in the typographical viewpoint. But, most personal computers are shipped with only 1 or 2 fonts for each CJK scripts, and synthesized "bold" is often used in documents generated by PC. Considering there is such root of embolding request, I wonder whether FT_GlyphSlot_Embolden() API is already enough for the purpose. It does not receive much parameters to control embolding (am I misunderstanding?). I'm afraid several control parameters are requested in future, for example: * strength to embolding * switch to enable/disable changing glyph metrics in embolding * switch to enable/disable embolding of bitmap font * choosing embolding algorithm How do you think of? Regards, mpsuzuki ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Make FT_GlyphSlot_Embolden standard API?
Hi all, As fontconfig and xft already have the code to "embolden" and rely on FT_GlyphSlot_Embolden to do the real job, I think FT_GlyphSlot_Embolden should be made standard API. This is an important feature for Chinese (maybe also Japanese and Korean) users, as most Chinese fonts don't have a real bold style. What do you think? Regards, olv ___ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
