Re: [ft-devel] Force PMingLiU like font do HINTING
. Add `FT_FACE_FLAG_TRICKY'. If set, the font is tricky. To access it, add a macro `FT_IS_TRICKY'. [This is a read-only flag.] . Change the meaning of `FT_LOAD_NO_HINTING' so that fonts which always need TrueType instructions (these are fonts which have FT_FACE_FLAG_TRICKY set) ignore it. . Instead of adding a new `FT_LOAD_RAW' flag which would do what `FT_LOAD_NO_HINTING' currently does, I propose that we get the behaviour of `raw' loading if both `FT_LOAD_NO_HINTING' and FT_LOAD_NO_AUTOHINT are set. This is now implemented in the CVS. Please test! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: table_info service and ftpatent module
Dear Turner, Sorry for the late reply, and I'm only Werner, not David :-) During the checking for Atari port, I find a strange call of table_info service in ftpatent module. [...] Definitely a bug. Yet I've not checked whether ftpatent works correctly (and if so, why it can works), but I guess the implementation of ftpatent should be improved. Hehe, nice words for a for faulty implementation. There might be 3 directions: A) extend table_info service in sfnt driver to return offset. it is most easiest, but it introduces an asymmetry between table_info service and public API FT_Sfnt_Table_Info(): FT_EXPORT( FT_Error ) FT_Sfnt_Table_Info( FT_Faceface, FT_UInttable_index, FT_ULong *tag, FT_ULong *length ); B) introduce new service to obtain an offset (and others, if required) to the table in sfnt stream. C) move some part of ftpatent to sfnt driver to use sfnt-specific internal data structures and internal functions. Which is the best direction? I suggest (A), with a proper comment. In case more than this single function needs the offset it is still easy to revert (A) and implement (B). Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Accessing FSType (Type 1 or CID)?
Does FreeType currently provide any way of accessing the /FSType entry in a Type 1 or CID font (cf. p19 of http://www.adobe.com/devnet/acrobat/pdfs/FontPolicies.pdf http://www.adobe.com/devnet/acrobat/pdfs/FontPolicies.pdf )? ( can't see anything, but I might have overlooked something.) Thanks. David %^ David Bevan Senior Software Engineer Pitney Bowes Emtex Software Tel: +44 (0)1923 270882 [EMAIL PROTECTED] ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Accessing FSType (Type 1 or CID)?
I'm happy to try to do this and have just been looking in to what might be required. If I understand correctly, a field needs adding to PS_FontInfoRec (which is part of the public interface; presumably this is OK) and FSType processed just like other fields, simply by defining in t1tokens.h. That should be very easy. In theory, it's a bit more complex than that because FSType can occur in either the FontInfo dictionary or the base font dictionary, and theoretically, if it occurs in both, the one in the FontInfo takes precedence. But FT2 code doesn't actually distinguish between fields in the FontInfo dictionary and the base font dictionary, which means that new code would be required to recognise whether we're within the FontInfo dictionary or not. However, I think it will be satisfactory to ignore the situation where FSType is present in both places and with different values. David %^ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 11 December 2008 13:43 To: Bevan, David Cc: freetype-devel@nongnu.org; Ghoshal, Ronen; Tu, Houjie Subject: Re: [ft-devel] Accessing FSType (Type 1 or CID)? Hi, On Thu, 11 Dec 2008 09:16:50 - Bevan, David [EMAIL PROTECTED] wrote: Does FreeType currently provide any way of accessing the /FSType entry in a Type 1 or CID font (cf. p19 of http://www.adobe.com/devnet/acrobat/pdfs/FontPolicies.pdf http://www.adobe.com/devnet/acrobat/pdfs/FontPolicies.pdf )? ( can't see anything, but I might have overlooked something.) At present, FT2 provides no public API to access /FSType entries in PostScript fonts, they are not loaded at all, I think. # the list of known entries can be checked by grep # T1_FIELD_xxx in source files. I don't think the lack of the feature is designed, maybe it is just not yet, because the original CID-keyed font and PS Type1 font specification didn't have FSType. I don't have sufficient sparetime to provide the patch to add the feature, is it urgent issue? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Accessing FSType (Type 1 or CID)?
Bevan, David wrote: I’m happy to try to do this and have just been looking in to what might be required. It would be very nice if the same API to get access to FSType would also give the fsType entry in the OS/2 table of TrueType sfnt datablob. John. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Accessing FSType (Type 1 or CID)?
-Original Message- From: John Tytgat [mailto:[EMAIL PROTECTED] Sent: 11 December 2008 16:08 To: Bevan, David Cc: [EMAIL PROTECTED]; Ghoshal, Ronen; Tu, Houjie; freetype- [EMAIL PROTECTED] Subject: Re: [ft-devel] Accessing FSType (Type 1 or CID)? Bevan, David wrote: I'm happy to try to do this and have just been looking in to what might be required. It would be very nice if the same API to get access to FSType would also give the fsType entry in the OS/2 table of TrueType sfnt datablob. Seems a reasonable idea - access to fsType is already available through FT_Get_Sfnt_Table(face, ft_sfnt_os2). I'll add an FT_Get_fsType() to wrap this and the new /FSType code. David %^ ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Accessing FSType (Type 1 or CID)?
If I understand correctly, a field needs adding to PS_FontInfoRec (which is part of the public interface; presumably this is OK) and FSType processed just like other fields, simply by defining in t1tokens.h. Yes, I think this should work without breaking backwards binary compatibility of the library. In any case, the new field should be at the end of the structure. However, I think it will be satisfactory to ignore the situation where FSType is present in both places and with different values. Hmm, I can't say whether this approach is sufficient. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
