[ft-devel] PCF bitmap foundary patch

2011-06-27 Thread İsmail Dönmez 
Hi again;

in openSUSE we apply a patch called freetype2-bitmap-foundry.patch which
seems to add foundry support to PCF font files, likely to fix the problem
reported over at
http://lists.freedesktop.org/archives/fontconfig/2006-February/002072.html .
The patch is attached for your inspection, can anyone check if its useful
still?

Regards,
ismail
---
 src/pcf/pcfread.c |   30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

Index: freetype-2.4.2/src/pcf/pcfread.c
===
--- freetype-2.4.2.orig/src/pcf/pcfread.c
+++ freetype-2.4.2/src/pcf/pcfread.c
@@ -1175,8 +1175,34 @@ THE SOFTWARE.
   prop = pcf_find_property( face, FAMILY_NAME );
   if ( prop  prop-isString )
   {
-if ( FT_STRDUP( root-family_name, prop-value.atom ) )
-  goto Exit;
+ 	  int l = ft_strlen( prop-value.atom ) + 1;
+ 	  int wide = 0;
+ 	  PCF_Property foundry_prop = pcf_find_property( face, FOUNDRY );
+ 	  PCF_Property point_size_prop = pcf_find_property( face, POINT_SIZE );
+ 	  PCF_Property average_width_prop = pcf_find_property( face, AVERAGE_WIDTH );
+ 	  if ( point_size_prop != NULL  average_width_prop != NULL) {
+ 		  if ( average_width_prop-value.l = point_size_prop-value.l ) {
+ 			  /* This font is at least square shaped or even wider */
+ 			  wide = 1;
+ 			  l += ft_strlen(  Wide);
+ 		  }
+ 	  }
+ 	  if ( foundry_prop != NULL  foundry_prop-isString) {
+ 		  l += ft_strlen( foundry_prop-value.atom ) + 1;
+ 		  if ( FT_NEW_ARRAY( root-family_name, l ) )
+ 			  goto Exit;
+ 		  ft_strcpy( root-family_name, foundry_prop-value.atom );
+ 		  strcat( root-family_name,  );
+ 		  strcat( root-family_name, prop-value.atom );
+ 	  }
+ 	  else {
+ 		  if ( FT_NEW_ARRAY( root-family_name, l ) )
+ 			  goto Exit;
+ 		  ft_strcpy( root-family_name, prop-value.atom );
+ 	  }
+ 	  if ( wide != 0) {
+ 		  strcat( root-family_name,  Wide);
+ 	  }
   }
   else
 root-family_name = NULL;
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] stroker - bevel joins

2011-06-27 Thread Graham Asher 

I use the stroker - not in anger, but sometimes in sorrow ;-)

Actually it seems quite good, but it could do with some speed 
optimisation, which I have discussed before with Werner; I made some 
concrete suggestions based on a comparison with CartoType's stroker, 
which is somewhat faster. I also discovered that - for my purposes, 
which may be different from other people's, but I think this is a 
general bug - the direction of the outer and inner borders is swapped 
for envelopes of closed strokes, thus:


|   ft_stroke_border_close( stroker-borders + 0, TRUE );
  ft_stroke_border_close( stroker-borders + 1, FALSE );
|

should be

|   ft_stroke_border_close( stroker-borders + 0, FALSE );
  ft_stroke_border_close( stroker-borders + 1, TRUE );
|

The effect of the bug is to produce voids when filling envelopes of 
closed strokes that overlap other closed paths, because the outer border 
is clockwise and the inner is anti-clockwise; for correct filling, the 
outer should be anti-clockwise and the inner clockwise.


That's based on a slightly out-of-date version, so forgive me if it's 
been fixed.


Graham Asher
CartoType Ltd


On 27/06/2011 16:05, David Bevan wrote:


Hi!

While developing code to support stroked text, we encountered a number 
of significant issues with the FT stroker. I will be submitting 
various fixes later in the week.


However, one of the issues requires discussion (or at least agreement) 
beforehand.


The PostScript/PDF References specify that the form of a bevel join 
(whether specified explicitly, or created as a result of exceeding the 
miter limit) is /not/ dependent on the value of the miter limit. See 
the attached miter.pdf for an example.


The current FreeType code generates the bevel join using a different 
algorithm that /does/ depend on the miter limit. This actually accords 
with the way the miter limit is handled in /XPS/ (see attached extract 
from the spec).


NB: Be aware, if you look at the current code, that a miter join is 
called a bevel join and /vice versa/ (and hence explicit bevel joins 
are implemented incorrectly). This will be fixed.


What do we want to do?

1.Change the implementation to match the PS/PDF References, discarding 
the XPS-style approach.


2.Support both, with FT_STROKER_LINEJOIN_MITER matching the PS/PDF 
References, and a new FT_STROKER_LINEJOIN_VARIABLE_MITER for the 
XPS-style approach.


3.Support both, with FT_STROKER_LINEJOIN_MITER unchanged, and a new 
FT_STROKER_LINEJOIN_FIXED_MITER for the PS/PDF approach.


4.Support both, with FT_STROKER_LINEJOIN_FIXED_MITER and 
FT_STROKER_LINEJOIN_VARIABLE_MITER, and FT_STROKER_LINEJOIN_MITER an 
alias for FT_STROKER_LINEJOIN_VARIABLE_MITER (the existing behaviour).


5.Something else.

1  2 introduce a backwards incompatibility, but is anyone actually 
using the stroker in anger?


As long as FT supports the PS/PDF approach, any of these is acceptable 
for us.


What do others think?

Thanks.

David %^

David Bevan

Development Manager

Pitney Bowes Emtex Software

Tel: +44 (0)1923 279300

david.be...@pb.com mailto:david.be...@pb.com


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel