Re: [ft-devel] FT_Get_PS_Font_Private in CFF driver
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
Okay, so in my specific case (CFF) the value is not used. Yes, it seems that you can just add a dummy value. 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. Ah, this reminds me to rectify one remark: 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. This was faulty memory of mine: They actually use a special version of TT interpreter (it's a patched version of the MS interpreter), but stem darkening and embolding takes place *after* hinting. The darkening amount, however, needs to be fractional. The Adobe people implement this by disabling hints in the x-direction (which is disabled for the LCD mode anyway), applying darkening only in the x-direction. 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
Werner LEMBERG w...@gnu.org writes: Behdad Esfahbod (on behalf of Google) contributed support for color embedded bitmaps (eg. color emoji). https://color-emoji.googlecode.com/git/specification/v1.html Only bitmaps? The blog entry doesn't mention any limitation to embedded bitmaps, and I was thinking that meant full vector fonts, only with color layers... [Hopefully this will increase the breadth of emoji support out there, with some real designers giving it a go, and we won't have to put up with the painfully twee emoji on many platforms (e.g., the horrible ipad/iphone emoji... ugh..urg..urgh)] Thanks, -miles -- Politeness, n. The most acceptable hypocrisy. ___ 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
Behdad Esfahbod (on behalf of Google) contributed support for color embedded bitmaps (eg. color emoji). https://color-emoji.googlecode.com/git/specification/v1.html Only bitmaps? Yes, since extending the available embedded bitmap tables in the OpenType specification is rather trivial. However, for proper SVG support (which large companies are already working on) it will still take a lot of time until the various parties can agree on a common standard. What Behdad has contributed was born out of an urgent need of Google. However, it should be straightforward to support a `great unified' embedded bitmap format, too, in case we will have one in the future. 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
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
Hello Michael! I need to lookup the StdVW value that is in the Type1 private dict of an OpenType font (with CFF outlines). Why? 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. 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. This doesn't help in the general case: Which subfont's StdVW value do you want to return? Fonts like `ShinGo' have zillions of subfonts, and most of them have different StdVW values. 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? I need more information to give a qualified answer. 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
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
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). OK. 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 structure of a CIDFont is as follows: Top DICT: version Notice Copyright FontName ... FDArray FDArray: Font DICT 0 Font DICT 1 ... Font DICT 0: Font Dict data Private Dict data Font DICT 1: Font Dict data Private Dict data ... For example, the `FontName' entry is present in the Top DICT and in all Font DICT entries indexed in the FDArray. 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. Well, FT_Get_PS_Font_Info isn't bad at all, since it correctly returns the Top DICT data of a CIDFont which represents the `public' dictionary data. 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. I'll ask someone from Adobe which value is used for StemV if the particular font is a CIDFont. 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
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
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? 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? 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?). Yes. Subfonts in TrueType or OpenType Collections (or WinFNT files) can be selected with `face_index', while subfonts in CIDFonts are internal. I'll ask someone from Adobe which value is used for StemV if the particular font is a CIDFont. Thanks! BTW, I've already received a `This is a good question' answer from Adobe, waiting for more to come :-) 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
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
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
