Re: [ft-devel] FT_Get_PS_Font_Private in CFF driver

2013-06-12 Thread Michael Toftdal
Hi Werner,

Okay, so in my specific case (CFF) the value is not used.

I have been busy with other things, and was about to start making the change in 
the FreeType code that we talked about. But it's a little demotivating that the 
(required!) value is not used anyway...

Thanks a lot for forwarding the Adobe communication though.

Regards,
Michael


On 01/06/2013, at 14.48, Werner LEMBERG wrote:

 
 BTW, I've already received a `This is a good question' answer from
 Adobe, waiting for more to come :-)
 
 And here it is.  The answer is far from trivial...
 
 Dave Arnold says that there are two cases where the StemV value is
 used (he wrote that from memory):
 
  . to select a font weight if a font substitution happens
 
  . to guide stem darkening for embedded TrueType fonts.
 
 Note that Adobe uses a special, self-made version of the TT
 interpreter which both handles stem darkening and artificial
 emboldening *before* hinting takes place.
 
 The StemV value is *not* used by the PDF engine if the embedded font
 is either a Type 1 or CFF font; in that case the value from the
 private dictionary gets used.  For a CID font, the value associated
 with the glyph's font DICT gets used.
 
 In case there is no StemV value in the PDF, the following algorithm
 applies:
 
  . use a heuristic method to measure a particular glyph outline for
getting a proper value
 
  . if that fails, use a default value (Dave believes it's 75 units)
 
 Similarly, this default value is used for CFFs which miss a StdVW
 operator.
 
 
Werner


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


Re: [ft-devel] FT_Get_PS_Font_Private in CFF driver

2013-05-28 Thread Michael Toftdal

On 28/05/2013, at 15.05, Werner LEMBERG wrote:

Hi,
and thanks for looking into this, Werner.

 I need to lookup the StdVW value that is in the Type1 private dict
 of an OpenType font (with CFF outlines).
 
 Why?

I need it for filling out a font descriptor in a PDF (it's the StemV value of 
the dictionary).
By requiring that my CFF font files contain exactly one font, they can be 
embedded directly in the PDF (the PDF spec has this requirement, p 468 in the 
1.7 version).


 And since I already have the font loaded in FreeType, I was looking
 for a way to get the value from there.  But the
 FT_Get_PS_Font_Private service is not available in the CFF driver,
 it appears (-- the comment says unsupported with CFF fonts).  One
 problem with CFF fonts is the fact that the font may have several
 sub fonts, I guess.
 
 Exactly.  Additionally, in case of subfonts, the private dictionary of
 the top-level font is empty.
 
 But on the other hand, the FT_Get_PS_Font_Info service _is_
 implemented by the CFF driver (by ignoring the sub fonts).
 
 Yes, sub-fonts are ignored.  However, they aren't needed since only
 the information of the top-level font info dictionary is returned.

Okay, I must have misread the CFF spec then. I thought the font info dict was 
per font as well (and eg UnderlineThickness sounds parallel to StdVW in this 
regard, doesn't it?). The implementation I suggest would then only be as bad as 
the current implementation of FT_Get_PS_Font_Info.
To do better, the api needs to have the sub-font index as a parameter.

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


Re: [ft-devel] FT_Get_PS_Font_Private in CFF driver

2013-05-28 Thread Michael Toftdal
On 28/05/2013, at 20.28, Werner LEMBERG wrote:
 The structure of a CIDFont is as follows:
 ...

Ahh, CIDFonts. I'm sorry. I had the FontSet notion in the CFF specification 
mixed up with the sub-font notion for CIDFonts in the FreeType code.


 However, the FDArray data is *completely internal*
 to FreeType and not publicly visible.  It is *not* possible to
 directly access a CIDFont's subfont.  In other words, your suggestion
 of using a subfont index doesn't work.

OK. So for CIDFonts I see the problem.
But for non-CID, CFF Fonts where the CFF FontSet notion is mapped to the 
FreeType face notion, wouldn't it still make sense to be able to access the 
private dict of a face, as it is possible for the plain Type1 fonts? This was 
actually what I was trying -- the sub-font index parameter I suggested is in 
fact the face_index parameter in FT_New_Face (right?).


 I'll ask someone from Adobe which value is used for StemV if the
 particular font is a CIDFont.

Thanks!


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


Re: [ft-devel] FT_Get_PS_Font_Private in CFF driver

2013-05-28 Thread Michael Toftdal
 Yes.  The new code for the CFF version of `FT_Get_PS_Font_Private' had
 just to call the function `cff_make_private_dict' and return the
 result.  Do you want to give it a try?

Yes, I'll try sometime soon. We'll have to upgrade to the latest FreeType 
version first though, but that's usually pretty straight-forward.


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


[ft-devel] FT_Get_PS_Font_Private in CFF driver

2013-05-27 Thread Michael Toftdal
I need to lookup the StdVW value that is in the Type1 private dict of an 
OpenType font (with CFF outlines). And since I already have the font loaded in 
FreeType, I was looking for a way to get the value from there. But the 
FT_Get_PS_Font_Private service is not available in the CFF driver, it appears 
(-- the comment says unsupported with CFF fonts). One problem with CFF fonts 
is the fact that the font may have several sub fonts, I guess. But on the other 
hand, the FT_Get_PS_Font_Info service _is_ implemented by the CFF driver (by 
ignoring the sub fonts).
I do not know enough about the font specs to tell if it is okay to ignore 
subfonts for the Type1 font dict but not for the Type1 private dict, but I 
consider implementing the private dict service along the lines of the available 
font dict implementation in cffdrivr.c. The private dict has already been 
parsed, and is in the private_dict member of the CFF_SubFont struct, as far as 
I can tell.
Do you have any comments on this? -- or do you have a suggestion for other ways 
of finding the StdVW value of a CFF font?

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


Re: [ft-devel] CID keyed fonts in sfnt wrappers in 2.3.8

2009-03-11 Thread Michael Toftdal
On Wed, Mar 11, 2009 at 7:40 AM, Werner LEMBERG w...@gnu.org wrote:

 [...]  Another would be the one that I have ended up implementing by
 adding two methods to the cid service interface (pardon my FT
 vocabular -- I haven't spent more that one or two days in the source
 by now). One method to tell me whether a given font really is a CID
 keyed font, in the sense that we've agreed upon in the above.  And
 one method to map unicodes to cids for a given font.  The mapping
 information is already present in the charset.sids array on the
 internal cff font class, as far as I can tell.  So I just had to
 make sure that the sids array wasn't free'd too early and make
 export the mapping via my the cid service.

 This sounds like the right solution to me.  Can you post patches?

I've included the diff below.

One technical detail that I have been struggling with: It seems that
the CID API functions (until my change there was only one function in
the API) are not exported when using the Visual project on Windows.
Besides from having to include ftcid.c in the project, it seems I have
to add #include FT_CID_H to ftcid.c to have effect of the
__declspec(dllexport) that I have in my ftoption.h file.

Another remark. Since the two new functions are in the CID service,
they will return a non-zero error value if the driver doesn't support
the CID service. This is a bit clumsy if one just wants to know
whether a given font in internally CID keyed or not...


diff -ruN freetype-2.3.8/include/freetype/ftcid.h
freetype-2.3.8.new/include/freetype/ftcid.h
--- freetype-2.3.8/include/freetype/ftcid.h 2008-06-26 11:50:03.0 
+0200
+++ freetype-2.3.8.new/include/freetype/ftcid.h 2009-03-09
16:06:05.956707000 +0100
@@ -88,6 +88,72 @@
const char*  *ordering,
FT_Int   *supplement);

+  /**
+   *
+   * @function:
+   *FT_Get_CID_Is_Internally_CID_Keyed
+   *
+   * @description:
+   *Retrieve the type of the input face, CID keyed or not. In
+   *constrast to the FT_IS_CID_KEYED macro this function will return
+   *also for CID keyed fonts in an snft wrapper.
+   *
+   * @input:
+   *face ::
+   *   A handle to the input face.
+   *
+   * @output:
+   *is_cid ::
+   *   The type of the face as an FT_Bool
+   *
+   * @return:
+   *FreeType error code.  0~means success.
+   *
+   * @note:
+   *This function only works with CID faces and OpenType fonts,
+   *returning an error otherwise.
+   *
+   * @since:
+   *2.3.8-cci
+   */
+  FT_EXPORT( FT_Error )
+  FT_Get_CID_Is_Internally_CID_Keyed( FT_Face   face,
+  FT_Bool   *is_cid);
+
+  /**
+   *
+   * @function:
+   *FT_Get_CID_From_Glyph_Index
+   *
+   * @description:
+   *Retrieve the CID of the input glyph index.
+   *
+   * @input:
+   *face ::
+   *   A handle to the input face.
+   *
+   *glyph_index ::
+   *   The input glyph index.
+   *
+   * @output:
+   *cid ::
+   *   The CID as an FT_UInt.
+   *
+   * @return:
+   *FreeType error code.  0~means success.
+   *
+   * @note:
+   *This function only works with CID faces and OpenType fonts,
+   *returning an error otherwise.
+   *
+   * @since:
+   *2.3.8-cci
+   */
+  FT_EXPORT( FT_Error )
+  FT_Get_CID_From_Glyph_Index( FT_Face   face,
+   FT_UInt   glyph_index,
+   FT_UInt   *cid);
+
  /* */

 FT_END_HEADER
diff -ruN freetype-2.3.8/include/freetype/internal/services/svcid.h
freetype-2.3.8.new/include/freetype/internal/services/svcid.h
--- freetype-2.3.8/include/freetype/internal/services/svcid.h   2007-07-16
22:25:34.0 +0200
+++ freetype-2.3.8.new/include/freetype/internal/services/svcid.h   
2009-03-10
15:27:45.232459000 +0100
@@ -31,10 +31,19 @@
const char*  *registry,
const char*  *ordering,
FT_Int   *supplement );
+  typedef FT_Error
+  (*FT_CID_GetIsInternallyCIDKeyedFunc)( FT_Face   face,
+ FT_Bool  *is_cid);
+  typedef FT_Error
+  (*FT_CID_GetCIDFromGlyphIndexFunc)( FT_Face   face,
+  FT_UInt   glyph_index,
+  FT_UInt  *cid);

   FT_DEFINE_SERVICE( CID )
   {
 FT_CID_GetRegistryOrderingSupplementFunc  get_ros;
+FT_CID_GetIsInternallyCIDKeyedFuncget_is_cid;
+FT_CID_GetCIDFromGlyphIndexFunc   get_cid_from_glyph_index;
   };

   /* */

diff -ruN freetype-2.3.8/src/base/ftcid.c freetype-2.3.8.new/src/base/ftcid.c
--- freetype-2.3.8/src/base/ftcid.c 

[ft-devel] CID keyed fonts in sfnt wrappers in 2.3.8

2009-03-10 Thread Michael Toftdal
I am working on a piece of software that is (/was) dependent on the
FT_FACE_FLAG_CID_KEYED flag and the 2.3.7 fact, that glyph index ==
CID for CID keyed fonts (also those in sfnt wrappers). After upgrading
to 2.3.8, I obviously got a small problem.
I need the CIDs for outputting PostScript, where I unwrap OpenType
(CFF) CID keyed fonts and refer to glyphs via the Identity CMaps.
After the upgrade to 2.3.8, I could of course look up the CID flag and
the Unicode to CID mapping in the font file itself (eg. as part of the
unwrapping where I have the information anyway). But I would like to
keep the unwrapping out of output process, as it happens another place
in the software and in principle, unwrapping could just be extraction
of the CFF table of the otf file.
For my own purpose, I solved the problem by implementing two new
functions in the CID service in FreeType. One to get the internal
CID flag of the font (result is equal to asking for the CID flag in
2.3.7 -- can by the way be mimicked for (most?) practical purposes by
asking for the ROS and checking the return value). The other function
gives me access to the glyph index to CID mapping that is stored in
the cff-charset.sids array (which I have to suspend the free'ing
of...).

It would of course ease my future FreeType upgrades if corresponding
functionality could be included in new FT versions, or if someone
could help me to a way of getting my information in an easier way in
FT... :-)
Any comments appreciated.

Kind regards,
-Michael


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