Re: [ft-devel] some doubts about the CFF parsing code
FreeType2 support these operators: # 0x010f: -Reserved- # XXX force_bold_threshold for FreeType2 # 0x0110: -Reserved- # XXX lenIV for FreeType2, Type 1 fonts # 0x0118: -Reserved- # XXX multiple_master for FreeType2 # 0x0119: -Reserved- # XXX blend_axis_types for FreeType2 However these opcodes are reserved in CFF version 1.0. A lenIV operator exists in Type 1 font format. Where can I find documentation for these operators? the multiple master operators are defined in an obsolete version of the Adobe Technical Notes 5177 and 5176, and they may be found here: http://ftp.ktug.or.kr/obsolete/info/adobe/devtechnotes/pdffiles/5177.Type2.pdf http://ftp.ktug.or.kr/obsolete/info/adobe/devtechnotes/pdffiles/5176.CFF.pdf ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] sfnt version 0x00020000UL
- Werner LEMBERG w...@gnu.org wrote: I noted in the FreeType sources (src/sfnt/sfobjs.c) this check on the version parameter: if ( tag != 0x0001UL tag != TTAG_ttcf tag != TTAG_OTTO tag != TTAG_true tag != TTAG_typ1 tag != 0x0002UL ) You can also find sfnts with tag: 'CID ' Hmm. Does this work with FreeType? Do you have a sample font? Apologies. I misremembered. the version tag is 'typ1', but there is a 'CID ' table rather than a 'typ1' table. I do have a sample font. 2.8Meg. If you still want it, I'll send it to you off list. It didn't work with freetype (doesn't work with fontforge either). ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] sfnt version 0x00020000UL
- Manlio Perillo manlio.peri...@gmail.com wrote: I noted in the FreeType sources (src/sfnt/sfobjs.c) this check on the version parameter: if ( tag != 0x0001UL tag != TTAG_ttcf tag != TTAG_OTTO tag != TTAG_true tag != TTAG_typ1 tag != 0x0002UL ) You can also find sfnts with tag: 'CID ' ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] questions about OpenType fonts with CFF data
- Werner LEMBERG w...@gnu.org wrote: So, does this means that you have seen OpenType fonts with CFF data having multiple font? This is not possible. According to people from both Adobe and Microsoft (as discussed on the OpenType mailing list, IIRC), a CFF font in an SFNT wrapper can only have a single font. This is undocumented, however. Both the mac (10.6) and freetype support ttc files with CFF data in them... ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] plan to support sfnt-wrapped CID-keyed font
On Fri, 2008-08-29 at 04:23, [EMAIL PROTECTED] wrote: Also, I introduced a boolean is_sfnt_ps to avoid the installation of bytecode interpreter for sfnt-wrapped CID-keyed fonts. Maybe it is NOT essential. Note that there are also sfnt wrapped type1 fonts which also use the typ1 version. They have a TYP1 table rather than a CID table and that table contains a bare type1 font. Thus, I added 2 booleans to check if table directory has CID or typ1 table. If one of them is found, I believe it is TYP1 and not typ1 If CID or TYP1 is found, the stream is seeked to the table and binary header is parsed (sorry, at present, sfnt-wrapped Type1 is not supported because I don't have the documents nor sample fonts). I'll send you the two examples I've got, off list. Q3) Does anybody have a documentation on Apple's GX Type1 font? Adobe TN#5180 tells that it was included in Apple Developers CD-ROM. I'd be interested in this too. I just parse the TYP1 table as a standard type1 font, and it seems to work (in the two test cases I've got). This format seems to permit a 'kern' table. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Suggested patch for the opentype validator
On Sun, 2008-06-15 at 12:01, Werner LEMBERG wrote: I believe you that this fix is necessary -- you certainly have a font which exhibits this behaviour. However, the fact that it is possible to have NULL values in the `BaseRecord' table (similar to the `ComponentRecord' table as used in GPOS Lookup Type 6) is not documented in the OpenType specification 1.5. Well it is implied by the second paragraph of Lookup Type 4: In the MarkBasePos subtable, every mark glyph has an anchor point and is associated with a class of marks. Each base glyph then defines an anchor point for each class of marks it uses. The it uses implies that it doesn't need to use all of them. Please report this to the OpenType list -- since the MS people are working on the OpenType 1.6 specification it would be good to fix the description of the `BaseRecord' table. OK. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Suggested patch for the opentype validator
I believe there is a bug in the opentype validator.
If I have a MarkToBase table with multiple mark classes and multiple
bases, and where at least one base is missing an attachment site
(anchor) for at least one mark class, then the validator will still
attempt to validate the missing anchor. (and often fail if the bass
array table doesn't look like an anchor.)
I believe that valid-extra2 should be set to 1 in
otv_MarkBasePos_validate. This will allow for a NULL anchor.
--- otvgpos.c~ 2008-06-15 07:33:42.0 -0700
+++ otvgpos.c 2008-06-15 07:45:32.0 -0700
@@ -664,7 +664,7 @@
switch ( PosFormat )
{
case 1:
- valid-extra2 = 0;
+ valid-extra2 = 1;
OTV_NEST2( MarkBasePosFormat1, BaseArray );
OTV_RUN( table, valid );
break;
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] CFF subfont matrix problem
On Thu, 2008-05-08 at 14:52, Werner LEMBERG wrote: the PS language reference manual the following for CID-keyed PS fonts: At glyph rendering time, the glyph coordinate system is defined by the concatenation of the FontMatrix entry in the selected FDArray dictionary with the FontMatrix entry in the CIDFont dictionary. Is this true for (pure) CFF also? Technical note #5176 (The Compact Font Format Specification) doesn't say a word. When I was playing with this I never got anything to work but having all sub-fonts have the same [ 0.001 0 0 0.001 0 0 ] FontMatrix and omitting the FontMatrix at the top level. Everything else seemed to yield unexpected results on my printer. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem sniffing font weight/width
On Sat, 2008-05-03 at 10:14, Deron Kazmaier wrote: This is probably not a freetype problem, but maybe someone here can point me in a direction that helps. I have a couple of fonts in which the OS2 structure contains bogus weights. For example, a (Mac) Helvetica.dfont that the Helvetica Bold font weight is the same as the Regular weight, but the Bold Italic weight is (correctly) larger. The Helvetica font with 10.4 is correct, but the 10.5 is version is hosed. The LinotypeUnivers font I have is even worse. It has a couple dozen weights, widths, plus italics and probably 2/3 report wrong widths and weights. I am assuming that there must be some Mac resource or?? that is correctly identifying the weights, or Mac apps would not work with these fonts. Sadly, I expect this from free fonts, but these are anything but! The mac probably never looks at the OS/2 table. That's a MicroSoft extension and in the old days mac fonts did not even have it. I would guess that the mac is simply reading strings out of the 'name' table (probably SubFamily string ID). ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Difference between mono and grey-scale rasterizers.
This is a far cry from a minimal case with a small bit of code to display the problem, so feel free to ignore it. A user reported to me that fontforge would crash when rasterizing a certain glyph in a font. He provided a patch which caused fontforge to use the grey-scale rasterizer. Same glyph. Same font. Same pixelsize. The black and white rasterizer returns the error code Invalid_Outline from line 3000 of ftraster.c. The grey-scale rasterizer succeeds and returns the correct greymap. I have worked around this in the current cvs of fontforge (so I'm not concerned if no one looks into it). But if anyone has an interest + time to pursue the matter: Start fontforge $ fontforge http://fontforge.sf.net/sfds/ExtragantCapitals.sfd.bz2 Then open the M (or W) glyph. Turn on the background fill (View-Show-Fill) Yesterday's fontforge would crash on this, today's will try to generate a monochrome bitmap, and if that fails try to generate a graymap. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: Report a bug.
On Sun, 2008-03-30 at 10:22, Werner LEMBERG wrote:
FT_Get_{First,Next}_Char are walking over cmaps, not over glyph
indices. Except for subsetted CID-keyed CFFs (which use CIDs instead
of glyph indices), the range for glyph indices is *always* contiguous.
Er... and sort of ttc files where glyph indeces are contiguous but may
be in different fonts.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Understanding Type1 fonts
On Wed, 2008-01-09 at 00:24, Donn wrote: .PFA files These are a new twist, just found one today. I do not know if they also get matched with some metric file. I see many .AFM files around and in one folder: PFA files contain exactly the same data as a PFB, they are a hex (ASCII) dump rather than a binary one. Essentially: Is an AFM or a PFM file needed *at all*? AFM files contain: bounding box and advance width data These can be regenerated from what's in the PF[AB] kerning data These are not stored in the PF[AB] ligature data These are not stored in the PF[AB] potentially data on glyph composites. This is rare Not stored in the PF[AB] So AFM files contain useful info not in the PF[AB], but their presence is not required. I can't remember what goes in PFM files. Ok +1 vote for AFM and PFM as non-essential to a Gnu/Linux system. If you throw them out you lose all your kerning. How important do you thing that extra data is on a modern Gnu/Linux system. Without going into C code, to what extent does Freetype work around when it does not find a metric file for a given font file? It simply won't provide any kerning information. So potentially your quality degrades. So, I take it you would advise that the corresponding metric files should be in the same folder as the glyph files? Yes. Am I right to assume the links are: PFB -- PFM and PFA -- AFM No. PFM is a microsoft binary representation of the same kind of data stored in an AFM file (which is an adobe ascii representation). Either type of file can be associated with either type of font. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] language ID on MacOS is used? (Re: Dynalab SJIS cmap)
On Tue, 2008-01-08 at 23:38, [EMAIL PROTECTED] wrote: There is a scenario that I don't want to think: TrueType font has multiple cmap subtables with same platform ID and platform-specific encoding ID but different language IDs. This is indeed possible. Apple made a mistake when they assigned encodings (scripts they call them). They only allowed for 31 of them. This means that there aren't enough. So there are at least five encodings for latin letters and they are distinguished by language id icelandic turkish croatian romanian (everything else for the standard macroman) Understanding the name of entries literally, same encoding ID means that such subtables must share same encoding, but the coverage may not be guaranteed to be same. For example, for Roman script, there is only one MacOS-specific encoding ID (=0). But there are various language IDs for Roman script: English, French, German, Italian, Dutch, Swedish, Spanish... Those would all use the standard macroman encoding Anybdoy had ever seen a TrueType font that has non-zero language ID? I have not. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] About the Cmap format 14
On Fri, 2007-10-19 at 04:04, David Turner wrote: By the way, where can I find the spec for cmap format 14 and the variant selector things ?, I could not find anything on the Internet.(yes, I've seen the description in src/sfnt/ttcmap.c) This was posted on the opentype list: http://blogs.adobe.com/typblography/UVS_in_OT.htm It's not official yet. - documentation: the API documentation doesn't make the purpose of these functions very clear. An explanation of what a variant selector charmap is would be welcomed Unicode decided that some characters had variant forms. They are a sort of grey area somewhere between being totally irrelevant and semantically distinct. I don't pretend to understand it exactly. So a character may be followed by a variant selector in unicode input to specify exactly which variant is intended. In the past this has been handled by GSUB ligatures. Adobe felt this was not good enough because it was too hard to see what variants were supported. So first they added a new table (called VASE) but MS didn't like that. Then they put the same data into a cmap subtable. It's an odd subtable because it is not a mapping of input code points to glyphs, instead it is a list of all variants supported by the font. A variant may be either default or non-default. A default variant is the one you will get for that codepoint if you look it up in the standard unicode cmap. A non-default variant is a different glyph. So the subtable consists first of a count of possible variants, then a list of those variants with pointer to a block of codepoints for which this is the default variant, and another block of codepoints for which this is the non-default variant. (Either pointer may be NULL. My assumption is that in a well designed font, one variant will be default for all glyphs, and the other variants will be non-default, but the spec does not require that. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] About the Cmap format 14
On Tue, 2007-10-09 at 23:56, Werner LEMBERG wrote: if called on a format 14 charmap (which shouldn't be possible in the first place). Instead a new routine FT_Get_Char_Variant_Index I believe the following patch will add cmap14 support to freetype. (based on the cvs tree as it stood a couple of days ago) New entry points: FT_Get_Char_Variant_Index( FT_Face face, FT_ULong charcode, FT_ULong variantSelector ) (returns the GID of the desired variant, or 0) FT_Get_Char_Variant_IsDefault( FT_Face face, FT_ULong charcode, FT_ULong variantSelector ) (returns 1 if this variant is the one that lives in unicode cmap returns 0 if this variant doesn't live in the unicode cmap returns -1 if this variant does not exist in the table) FT_Get_Variant_Selectors( FT_Face face ) (returns a list of all variant selectors in the subtable. the end of the list is marked by a 0 entry. returns NULL if there is no variant cmap subtable (or other error) FT_Get_Variants_Of_Char( FT_Face face, FT_ULong charcode) (returns a 0-terminated list of all variant selectors which apply to this unicode character) FT_Get_Chars_Of_Variant( FT_Face face, FT_ULong variantSelector ) (returns a 0-terminated list of all unicode code points which have a variant glyph for this selector) The only test font I've got is one I created myself with ff, so it is questionable. I include it and a tiny little test program at: http://fontforge.sf.net/private/cmap14-test.tar.bz2 cmap14.patch.bz2 Description: application/bzip ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] About the Cmap format 14
On Tue, 2007-10-09 at 23:56, Werner LEMBERG wrote: I have no opinion here. If you think this is the route to go, let's do this. However, I could imagine to have FT_Get_Chars_Of_Variant FT_Get_Variants_Of_Char FT_Get_Variant_Selectors I like this much better (I was just trying to be consistent with the old interface), but this is certainly easier to use. instead which return an array of all chars or variants, respectively. Whether this makes sense, I don't know. Hmm. Your suggested functions are probably better in the sense of memory consumption; my suggestions can cause big allocations... I don't think it will be too bad. Currently only ~260 variant selectors are reserved and less than 10 are actually defined. The only questionable one is FT_Get_Chars_Of_Variant, but even here I don't think there will be any huge arrays -- my understanding is that even Adobe-Japan-1 has only 1222 characters with multiple variants. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] About the Cmap format 12
Out of curiosity... are there any plans afoot to support 'cmap' format 14 (the variant selector table)? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] About the Cmap format 12
On Mon, 2007-10-08 at 07:46, Werner LEMBERG wrote: I've skimmed the specs but didn't look more closely. Do you volunteer? It seems that we need a special interface for that, right? I would think so... I haven't paid attention to freetype's 'cmap' code. I'll look at it and see what I can do. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Incomplete cmap table for platform 0 (Apple Unicode)
On Sun, 2007-09-30 at 20:16, [EMAIL PROTECTED] wrote: As I've shown in previous post, Apple Unicode cmap in the sample font is NOT broken from the viewpoint of data structure, I think. To detect broken cmap as you say, it's required to investigate cmap, loca, glyf subtables content semantically. After checking the all cmap, loca, glyf subtables, the best cmap subtable would be chosen. I'm not against the fact that such feature is convenient, but I'm questionable if it should be built-in feature of FreeType and should be enabled by default. I'm not sure how you could even do it. It is perfectly valid to have unencoded glyphs, desirable even. How on earth could you determine that one subtable was better? In ttc files many glyphs won't be encoded for a given font, nor with they be the result of GSUB transformations. I can't think of an algorithm that could produce reasonable results. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] otvalid modules
On Fri, 2007-08-17 at 08:56, Werner LEMBERG wrote: Applied. However, I think there is a mistake for the SingleSubstFormat1 case: idx = otv_Coverage_get_first( Coverage ) + DeltaGlyphID; if ( idx 0 || idx + DeltaGlyphID 0|| (FT_UInt)idx + DeltaGlyphID = valid-glyph_count ) FT_INVALID_GLYPH_ID; The code adds DeltaGlyphID to idx, and then you are checking whether `idx + DeltaGlyphID 0'... This looks wrong to me. I don't have time currently to verify this. Please post a patch if necessary. DeltaGlyphID can be a negative value, so I think it's a reasonable check. Well, yes, but I would expect this code: I beg your pardon, you are quite right. That entire patch chunk was wrong (and unneeded in the first place). This should back it out. --- otvgsub.c~ 2007-08-10 16:27:31.0 -0700 +++ otvgsub.c 2007-08-10 16:27:31.0 -0700 @@ -71,16 +71,12 @@ otv_Coverage_validate( Coverage, valid, -1 ); idx = otv_Coverage_get_first( Coverage ) + DeltaGlyphID; -if ( idx 0 || - idx + DeltaGlyphID 0 || - (FT_UInt)idx + DeltaGlyphID = valid-glyph_count ) - FT_INVALID_GLYPH_ID; +if ( idx 0 ) + FT_INVALID_DATA; idx = otv_Coverage_get_last( Coverage ) + DeltaGlyphID; -if ( (FT_UInt)idx = valid-glyph_count || - idx + DeltaGlyphID 0 || - (FT_UInt)idx + DeltaGlyphID = valid-glyph_count ) - FT_INVALID_GLYPH_ID; +if ( (FT_UInt)idx = valid-glyph_count ) + FT_INVALID_DATA; } break; ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] otvalid modules
I blush to admit that I miscounted the number of constants in one of the tables (there are 56 not 57). Please apply the otvmathconstant patch On Wed, 2007-08-08 at 11:24, Werner LEMBERG wrote: Suzuki-san, what do you think and/or suggest? I have a couple of general questions. Probably for Suzuki-san: 1) In many cases in OpenType there will be an offset to a coverage table and a count of glyphs. The number of glyphs in the coverage table should be the same as the glyphCount in the table that points to it. The patch coverageCount passes an extra argument to otv_Coverage_validate (the expected number of glyphs, or -1 if this is not known -- it isn't always) and then checks that these counts match. 2) I don't see any validation of Glyph ID in the coverage table -- rather a comment saying not to do this. I fear this may be my fault. Under GX I don't believe Glyph IDs should be validated -- but this is only true under GX because of the way apple's state machines behave. I remember telling Suzuki-san not to validate the GIDs and I fear I did not make it clear that the statement only applied to GX. Under OpenType I think the GIDs should be validated -- in coverage tables and elsewhere. I may be wrong, and perhaps the authors had something else in mind and my patch may be inappropriate. So please examine the invalidGID patch and only apply it if appropriate. otvalid2.tar.bz2 Description: application/bzip ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] otvalid modules
On Tue, 2007-08-07 at 15:35, Behdad Esfahbod wrote: On Tue, 2007-08-07 at 18:06 -0400, George Williams wrote: I am working on a validator for the MATH table to slot it in to otvalid. Hi George, Any spec on the MATH table available online? Thanks No, MS hasn't made it public yet. However if anyone is interested I can probably send you a copy privately. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] discrepancy in underline offset
On Wed, 2007-06-20 at 08:31, Graham Asher wrote: However, the definition of postscript.underlinePosition is (according to http://www.microsoft.com/OpenType/OTSpec/post.htm): This is the suggested distance of the top of the underline from the baseline (negative values indicate below baseline). The PostScript definition of this FontInfo dictionary key (the y coordinate of the center of the stroke) is not used for historical reasons. The value of the PostScript key may be calculated by subtracting half the underlineThickness from the value of this field. Thank you for pointing this out. FontForge had this bug too. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Bug in SHZ instruction?
I believe there is a bug in the SHZ instruction. I believe SHZ should not move the phantom points in the zone. The attached font contains one interesting glyph ~ and lots of glyphs which are vertical bars and are included to show spacing. The interesting glyph moves the zone by 4 pixels. In freetype this increases the advance width of the glyph. On the mac (with it's native rasterizer) the advance width is not increased. The example images were taken with a 9ppem rasterization. ftstring -m A~A 9 Untitled1.ttf The attached patch fixes the problem I see... Untitled1.ttf Description: application/font-ttf Untitled1-mac.png Description: PNG image Untitled1-freetype.png Description: PNG image --- ttinterp.c~ 2007-01-19 16:44:07.0 -0800 +++ ttinterp.c 2007-01-19 17:14:22.0 -0800 @@ -5466,8 +5466,14 @@ if ( COMPUTE_Point_Displacement( dx, dy, zp, refp ) ) return; -if ( CUR.zp2.n_points 0 ) +/* XXX: UNDOCUMENTED! SHZ doesn't move the phantom points */ +/* Twilight zone has no contours, so use n_points.*/ +/* Normal zone n_points includes phantoms, so must use end*/ +/* of last contour*/ +if ( CUR.GS.gep2 == 0 CUR.zp2.n_points 0 ) last_point = (FT_UShort)(CUR.zp2.n_points - 1); +else if ( CUR.GS.gep2 == 1 CUR.zp2.n_contours 0 ) + last_point = (FT_UShort)(CUR.zp2.contours[ CUR.zp2.n_contours-1 ]); else last_point = 0; ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] `gasp' table version 1 and update to `head'
On Fri, 2006-12-08 at 00:06, Werner LEMBERG wrote: Greg Hitchcock from MS provided some information regarding the gasp table format, version 1. I'm only listing the differences. field description version 1 rangeGaspBehaviorbit 3: GASP_SYMMETRIC_SMOOTHING Use smoothing along multiple axis with ClearType. bit 4: GASP_SYMMETRIC_SMOOTHING Use gridfitting with ClearType symmetric smoothing. Er... Do these two bits really have the same name? Did he provide any indication of what the default behavior was if there was no gasp table (is it still the same as the default for a version 0 gasp table) Additionally, bit 13 in the `flags' field of the `head' table got a meaning: Font optimized for ClearType. If this flag is cleared, East Asian fonts in the Windows Presentation Framework (formerly known as `Avalon') will not be hinted. Setting this flag will enable hinting. Is that all it means? Or does it also disable the new gasp table bits? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] `gasp' table version 1 and update to `head'
On Fri, 2006-12-08 at 00:06, Werner LEMBERG wrote: Greg Hitchcock from MS provided some information regarding the gasp table format, version 1. I'm only listing the differences. field description version 1 rangeGaspBehaviorbit 3: GASP_SYMMETRIC_SMOOTHING Use smoothing along multiple axis with ClearType. bit 4: GASP_SYMMETRIC_SMOOTHING Use gridfitting with ClearType symmetric smoothing. Is anything defined for bit 2? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Problems with FT_Outline_Get_Bitmap
I am trying to rasterize a rectangle which is centered around y==0.
I get a bitmap half as high as I expect.
More complicated tests suggest that everything below y==0 is clipped.
Test file included.
(Note: I do not have a Face open. I'm going directly from an FT_Outline
to an FT_Bitmap).
#include string.h
#include stdlib.h
#include math.h
#include ft2build.h
#include FT_FREETYPE_H
#include FT_OUTLINE_H
static FT_Library context;
int main(int argc, char **argv) {
FT_Outline outline;
FT_Bitmap bitmap;
char tags[4];
short contours[1];
FT_Vector points[4];
int k,j,rowcnt,err;
if ( FT_Init_FreeType( context )) {
fprintf( stderr, Init failed.\n );
return( 2 );
}
memset(outline,0,sizeof(outline));
outline.n_contours = 1;
outline.tags = tags;
outline.contours = contours;
outline.n_points = 4;
outline.points = points;
outline.flags = FT_OUTLINE_NONE;
points[0].x = 73 ; points[0].y = 899;
points[1].x = 427; points[1].y = 899;
points[2].x = 427; points[2].y = -899;
points[3].x = 73 ; points[3].y = -899;
contours[0] = 3;
tags[0] = tags[1] = tags[2] = tags[4] = 0x1; /* On-curve */
memset(bitmap,0,sizeof(bitmap));
bitmap.rows = (((int) (ceil(899.0/(16))-floor(-899.0/(16) +1;
bitmap.width = (((int) (ceil(427./(16))-floor( 73.0/(16) +1;
bitmap.pitch = (bitmap.width+7)3;
bitmap.num_grays = 0;
bitmap.pixel_mode = ft_pixel_mode_mono;
bitmap.buffer = calloc(bitmap.pitch*bitmap.rows,sizeof(char));
err = (FT_Outline_Get_Bitmap)(context,outline,bitmap);
if ( err ) {
fprintf( stderr, Rasterize failed. %d\n, err );
return( 2 );
}
rowcnt = 0;
for ( k=0; kbitmap.rows; ++k ) {
for ( j=bitmap.pitch-1; j=0 bitmap.buffer[k*bitmap.pitch+j]==0; --j );
if ( j!=-1 )
++rowcnt;
}
fprintf( stderr, I expect to have a bitmap with about %d rows. Instead I get one with %d rows\n,
bitmap.rows-1, rowcnt );
fprintf( stderr, It looks as though the bitmap is clipped at y==0\n );
return( 1 );
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] What and where are the fonts that require the unpatented hinter ?
On Fri, 2006-08-25 at 23:48, David Turner wrote: Could anyone remind me what these fonts are, and where I could find them for analysis and testing ? I believe that nearly all of them were designed by DynaLabs, but I'm a bit unsure about that. David, Here's another one: htst3.ttf http://fontforge.sf.net/hidden/htst3.tar.bz2 (Just to make sure an earlier message didn't get lost) I've posted kaiu.ttf mingliu.ttc to http://fontforge.sf.net/hidden/mk.tar.bz2 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Apple's bitmap only sfnt format
Apple sort of documents a bitmap only sfnt format in its truetype documentation. There is a 'bhed' table which should be used instead of the 'head' table in a bitmap only sfnt. Apple's ftxvalidator insists that there should be no 'hhea' nor 'hmtx' tables either. This is not stated in Apple's documentation. Does anyone have a bitmap only sfnt produced by Apple (not one made by fontforge) so I can see what Apple actually does in this case? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
On Fri, 2006-06-16 at 13:32, Masatake YAMATO wrote: Thank you for you suggestion. I revised ftvalid.c to show messages and exit if validate modules is not present. I also improved help message. Now it shows each validate module is implemented or not. Excellent! Thank you very much. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ftvalid
I tried ftvalid for the first time today. At first it just told me that every font I fed it was invalid. I discovered this was because the default freetype does not include the validation modules. After changing modules.cfg everything passed. I wonder... would it be possible to have FT_OpenType_Validate return something other than FT_Err_Invalid_Argument if the validation service is not present, and have ftvalid check for the service missing error and generate an error saying that the service isn't present rather than that the font is invalid? I found it a little confusing to have the default build tell me everything was invalid. It would be nicer to know that the font might be ok, but I need to rebuild the library... ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Outline dumper for windows
On Wed, 2006-02-22 at 13:29, Tom Kacvinsky wrote: Werner is good at that kind of stuff. :-) And I did not know that FontForge now had TT byte code stepping. Sweet! It has had it since 2003. It is simply a front-end to freetype's interpreter and shows you all of David's hard work. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Relevance of new API FT_Get_Module_Flags ?
On Mon, 2006-02-20 at 01:56, david turner wrote: If this function's purpose is to determine wether the bytecode interpreter is activated in a given FreeType build, I'd rather like to see a specific API that returns a boolean, or an enum, instead Can't you avoid even that by using dlopen(NULL) to give you a handle to the current image and then use dlsym to see if TT_Run_Ins exists? Or does that not port to other systems? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] On the impact of installing the next FreeType release on a typical Unix distribution
On Wed, 2006-02-15 at 17:31, Werner LEMBERG wrote: - do the required modifications, encapsulating each of the old internals in a configuration macro (e.g. FT_CONFIG_OPTION_OLD_INTERNALS) Sounds good. We should mention in the docs that these steps are performed only *once*, and that we are not going to maintain those hacks. As the author of a rogue client for which no patch is contemplated (and for which we decided last year that there was no good way to provide a patch) I must beg that TT_RunIns remain reachable. FontForge will work without it, but the debugger will be gone... ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] On the impact of installing the next FreeType release on a typical Unix distribution
On Thu, 2006-02-16 at 06:15, Werner LEMBERG wrote: As the author of a rogue client for which no patch is contemplated (and for which we decided last year that there was no good way to provide a patch) I must beg that TT_RunIns remain reachable. We add `TT_RunIns' manually to the list of exported symbols. This should be sufficient, shouldn't it? That's all I want. Please, please, please. Or a configuration option that does this if you'd prefer that it not be default. That would be fine too, since default builds don't include bytecode anyway people already have to reconfigure to use this in ff. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] On the impact of installing the next FreeType release on a typical Unix distribution
On Thu, 2006-02-16 at 07:08, david turner wrote: I still don't understand why you absolutely want the ability to dynamically peek into the internals of the libfreetype installed on the system, especially since it will not have the bytecode interpreter on most distros anyway... I want FontForge to run on any system whether it has freetype installed or not. If freetype is not installed then I use ff's built in (poor) rasterizer. I want FontForge to run on any system with freetype whether it has the bytecode interpreter enabled or not. If freetype has no bytecode interpreter then fontforge doesn't do truetype debugging. I don't want to have to provide three different fontforge builds for each system. I don't want fontforge to crash on startup if there is the wrong kind of freetype on the system. So I do dynamic linking. That way I can customize fontforge's behavior depending on what is available. I want one executable that can adapt itself to all situations and do the best it can with what is available. I want to impose as few required dependencies on the user as possible. Nobody else seems to think this way, but to me it's the obvious solution to a problem. Take advantage of what's there but require as little as possible. I need TT_RunIns because I install a DebugHook, and (as I understand it) a DebugHook is pretty useless if it doesn't call TT_RunIns. I need the internal headers so I can display the state of the interpreter to the user. I'm not entirely sure what improvements I'd see if I extracted the truetype code into a library all by itself. It would be smaller, yes, and I suppose easier to distribute with fontforge, but it would still become divorced from the true freetype code and subject to divergence (just as pango's incorporation of some of the old ft1 code gained bug fixes in some places but not others). And I don't just use the truetype code in freetype. I am also a normal freetype user and rasterize glyphs in the normal way, so I need the full library for some things. Having my own private copy for tt debugging while using the installed freetype for rasterization sounds like exactly the can of worms you are seeking to avoid with the new version of the library. I would worry about shipping a fontforge with a statically linked freetype (or part of freetype) with the bytecode interpreter enabled for patent reasons. I would worry equally about shipping a plug-in with the bytecode interpreter enabled. Isn't that exactly what a library is? And hasn't Apple said that's a bad idea? For users to access the debugger I'd still require them to do their own builds and change the default configuration setting of my embedded freetype. To me, including the freetype sources with mine own sounds a) unethical b) not something that solves any of the problems I worry about. Your concern is (I think) that the internals of freetype will change and fontforge will break. That's ok. I'll fix it and there will be a version of ff which works with old freetypes and one that works with new freetypes. This happens occasionally. The author of autotrace changed the command line arguments for autotrace some time ago. Old fontforges only work with old autotraces. New fontforges only work with new autotraces. After someone reported that autotrace had changed its arguments and I posted a build that worked with the new version (and documented the fact) no one complained. It's essentially the same problem, and not one that worries me. Now, if ff ever were to become a commercial product that would be completely different. Then I'd have to insure that the install process installed everything it could possibly need: all image libraries, libxml, libfreetype (with bytecode), etc.. I'd have to talk to you and Apple about licensing. That's a lot of hassle and probably some expense, but it isn't worth it for something I'm giving away. That's not what I find fun. So I'm happy with things as they are, just so long you don't remove the entry point I need... And Werner says you haven't. You can change the internals and I can work around that, but if you remove the entry point I'm stuck. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] testing freetype
Once upon a time, about last October, the thought of a freetype testsuite appeared yet again on the list. I've been working on a function in fontforge to make fontforge's testsuite (such as it is) more capable, and I realized that this same thing could be used to test freetype. If anyone cares to. The idea is essentially what Ulrich was suggesting: you create a set of bitmaps for a font with a good version of the library, and then with later versions you generate new bitmaps and compare against the originals. I've written two fontforge scripts which I'm attaching. One builds up an sfd file of a font and inserts bitmaps, the other loads that in, builds up new bitmaps, and tests that they are similar. $ fontforge -script SetupBitmapTest.pe ARIAL.TTF 12 13 14 15 16 17 18 19 Created: ArialMTBitmaps.sfd install a new version of freetype to be tested $ fontforge -script TestBitmaps.pe ArialMTBitmaps.sfd Ok The first can take as arguments: * An integer (= a bitmap strike at that pixelsize with depth 1) * int'@'int (= a strike at first int pixelsize, depth of second) * a filename (containing a bitmap strike) In the first two cases fontforge will use freetype to rasterize the font to produce a strike of a given pixelsize/depth. In the third case it will load a pregenerated strike (somehow obtained from another rasterizer?) The test script just takes one argument: the name of an sfd file containing bitmaps to be tested. Bitmaps of depth 1 are tested for exact pixel matches. Bitmaps of depth 8 are tested to make sure that pixels are with in 2 (out of 256) of the corresponding pixel in the original strike -- this can be adjusted by editing the script, I don't know what a good value is here). This method has a potential drawback: fontforge never rasterizes the original font. Instead it regenerates the font from its internal copy of the splines and metadata. Currently I don't have any way to pass rasterization flags to freetype, but if there is any interest in this approach I could easily add this ability. Is this worth pursuing? (these scripts only work with the fontforge currently in the cvs tree, none of the released versions support this yet) #/usr/local/bin/fontforge # First argument should be an sfd file containing an outline font and a # set of good bitmap strikes. # This checks that rasterizing using the current rasterizer will produce the # same (or very similar) results. Open($1) sizes = $bitmaps Reencode(Original)/* Make sure no holes in encoding */ SelectAll() Copy() BitmapsRegen(sizes) CompareGlyphs(-1,-1,.01) Print(Ok) /* Otherwise we will die in CompareGlyphs with an error */ #/usr/local/bin/fontforge # First argument is the filename of an outline font to be tested. May be in # any format fontforge supports. # Subsequent arguments should be either: # * A number (indicates a pixelsize of depth 1) # * Two numbers with an @ between them (pixelsize at depth) # * File name containing a bitmap/greymap strike # Output will be an sfd file named fontnameBitmaps.sfd if ( $argc3 ) Error(Too few arguments) endif Open($1) i = 2; cnt = 0 while ( i$argc ) if ( Strskipint($argv[i])!=0 ) ++cnt; endif ++i endloop if ( cnt!=0 ) bitmaps = Array(cnt) cnt = 0 i = 2; while ( i$argc ) if ( Strskipint($argv[i])!=0 ) pixelsize = Strtol($argv[i]); end_pos = Strskipint($argv[i]) if ( Strsub($argv[i],end_pos,end_pos+1)==@ ) depth = Strtol(Strsub($argv[i],end_pos+1)) else depth = 1 endif bitmaps[cnt++] = (depth * 65536) | pixelsize endif ++i endloop BitmapsAvail(bitmaps); endif i = 2; while ( i$argc ) if ( Strskipint($argv[i])==0 ) Import($argv[i]) endif ++i endloop Save($fontname+Bitmaps.sfd) Print( Created: + $fontname + Bitmaps.sfd) ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] web page for the forthcoming 2.2.0 release
On Mon, 2006-01-23 at 01:53, david turner wrote: Perhaps we shall *rename* the library to, say, `libft2', instead of `libfreetype', Um this will break everybody's builds and will mean we can't have something that builds with either 1.10 or 2.0 without fancy configure scripting. I'm not sure what it gains you that changing the so number doesn't... together with a new API prefix `FT2_' instead of `FT_'. This would avoid the whole mess. Please don't change the API. It makes some sense to change internal names, I suppose. I'd prefer you didn't (since fontforge is a rogue), but don't change the external ones. Another option is to have ./configure refuse to install freetype 2.2.0 if a previous release of the library is detected on the system; that is, unless you use a super-duper parameter like --please-destroy-my-desktop that only the cautious will care to use. That seems like a good starting point to me. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: [ft] Creating an [OT]TF font from BDF font
On Sun, 2005-12-18 at 18:20, Chia-I Wu wrote: FT_Get_BDF_Fontname(face) FT_Get_BDF_Comments(face) Couldn't they just be treated like normal properties? Well they aren't in the bdf file format, they are handled quite differently, so the bdf parser handles them differently. The pcf file format does not contain the comments but does treat the fontname as a normal property. I thought bundling them into the property list might offend some purists. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: [ft] Creating an [OT]TF font from BDF font
On Sun, 2005-12-18 at 18:20, Chia-I Wu wrote: FT_Get_BDF_Fontname(face) FT_Get_BDF_Comments(face) Couldn't they just be treated like normal properties? Ok, I have removed those entry points and made them behave like normal properties. This is incompatible with previous behavior. But since the previous behavior was inconsistent between BDF PCF that may not matter. iterate_bdf3.patch.bz2 Description: application/bzip iterate_sfnt3.patch.bz2 Description: application/bzip ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: [ft] Creating an [OT]TF font from BDF font
On Sat, 2005-12-17 at 18:42, Chia-I Wu wrote:
I suggest the following APIs, making iterator merely an iterator:
/* to iterate... */
FT_Get_BDF_Iterator( face, iter );
while ( FT_Iterare_BDF_Property( face, iter, name, aprop ) )
{
/* do something; */
}
/* to get property count... */
FT_Get_BDF_Property_Count( face );
Is that really an improvement? It means adding three function calls
instead of one, and it isn't compatible with the List_Iterator either.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: [ft] Creating an [OT]TF font from BDF font
Drat. PCF fonts include the FONT keyword and value in the list of properties. Strictly speaking FONT is not a bdf property (it comes outside of the STARTPROPERTIES list) -- however to do round trip conversion it is necessary. The value is available internally as face-bdffont-name, but I don't see any API to get this. I see three possibilities: * Add an API to retrieve face-bdffont-name * Add this to the property list on parsing Will make the BDF properties match the PCF ones, but would be incompatible with existing code * Change my new iterator so that it manufactures a fake entry for FONT ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FT_Outline_Get_Bitmap
Werner I stumbled on a case where I'd like to get a black white image out of FT_Outline_Get_Bitmap rather than the grey scale output that is currently returned. == Justification == When FF is in debug mode it displays a raster showing what pixels would be turned on with the current position of the splines. When doing AA debugging I can use FT_Outline_Get_Bitmap with the information in the execution context and get a grey scale image for the current outline. All is happy and nice. But when doing BW debugging I ended up writing my own (simple) routine which turned a pixel on if the center of the pixel was within the outline. It didn't do dropout prevention. In 10pixel BW debugging of K from Vera.ttf this routine gave different results from those from freetype. Which made Werner unhappy. So it might be nice to give consistent results to those from freetype. = Two thoughts enter my head: Adding a bw version of FT_OGB to the API Changing the API so that FT_OGB looks at num_grays or pixel_mode field of the bitmap argument. (I think this is a bad idea, I merely suggest it because it was what I tried) I'm not volunteering to write this myself at the moment. I'm sort of hoping someone can tell me that all I need to do is call FT_Outline_Get_Foobar. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] PFM Specifications.
On Wed, 2005-11-02 at 10:11, Rajeev Pahuja wrote: Does some one has Type1 PFM file specifications other than one available for CJK at Last time I looked I could find no PFM spec on the web aside from Adobe's CJK info. There used to be one on MicroSoft's site, but they removed it about the time NFM files appeared (which also don't seem to have a spec). ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Revisiting LSB [2]
On Fri, 2005-10-28 at 03:54, Ulrich wrote: This is correct but I still think that this fact doesn't imply that it isn't possible to set up a test suite. As far as I understand FreeType will generate a certain rasterisation result depending on the parameter settings and the environment it detects. There might be and probably will be other rasterisation results which are good or even better but they aren't generated by FreeType because the algorithms chosen simply don't generate them. The algorithms used by FreeType change over time. Perhaps with truetype, with the bytecode interpreter turned on there is a deterministic process which should always produce the same answer. But with the autohinter (or postscript hints) I do not believe this is the case. Requiring such leaves no room for improvement of hinting. It seems that we're still talking about slightly different things. So far I don't see why some bits of the rasterisation result are randomly set. Which part of FreeType does introduce random? Sorry. I mean that using the bytecode interpreter it might be possible to define a correct result for a glyph. Using the autohinter it is not possible because today's autohinter is different from last year's. If the autohinter chooses to move a spline a little bit more to the left because we think it looks better today that will invalidate all test suites based on the previous behavior. Of course, after improving the rasterisation algorithm checking the result by a human being is required and the data of the test suite which are used while comparing the results when the test suite is executed have to be replaced by the new samples. That's why I believe the testsuite is useless. I think this will happen far too frequently, that the overhead involved in checking minor changes will not be worth the results gained. It is not like a compiler testsuite where there is only one right answer (except possibly in the case above). So any change to the autohinter will probably introduce irrelevant changes in the results which will require much checking and correction. But even in that case a test suite might well be helpful as not necessarily all generated glyphs get a new shape. It's more than just shape. It's the difference between a pixel having 0xfe and 0xfd. Work can then be focussed upon the ones that have changed. I would appreciate it if one of the experts shed some light on that. Anyway that remains my opinion. Your view keeps being repeated, so obviously I am not convincing. Perhaps if you write the testsuite and show that it is useful you can confound me. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Revisiting LSB [4]
On Fri, 2005-10-28 at 14:38, Ulrich wrote: It's more than just shape. It's the difference between a pixel having 0xfe and 0xfd. Sorry for using the wrong term shape. It should have been result. I assume that every single change in the result has to be checked as one pixel being on or off might have a servere impact on the result's quality. It's not a black white bitmap any more. It's a grey scale image. So it's not just a pixel changing from black to white, it's a pixel changing from 0xfd to 0xfe or whatever. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] comp is reserved word in Apple SC compiler?
On Thu, 2005-10-27 at 10:38, Steven Johnson wrote: I think that compiler also had extended as a reserved word (as a 96-bit floating point type, to match Motorola hardware of the time). I worked on an early version of the MPW compiler (when the work was outsourced from Apple). There was indeed an extended datatype, but it was an 80bit type. Apple required its use to hold intermediate results (a = 3.0*f+4.0) got evaluated with 80 bit temporaries and then converted back to double. This had the nifty side effect that a compiler which conformed to Apple's requirements failed ANSI-C's requirements (which required 64 bit temporaries). ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Revisiting LSB
On Mon, 2005-10-10 at 16:37, Fujinaka, Todd wrote: I may have done something wrong, but those tests take an incredibly long time. Oh, they never end. It keeps churning out random tests and saving the few that cause problems. I think the tests we need are just something to test to see that all of the interfaces for freetype that are specified in the LSB spec are present and functioning. The degree of functioning is something I'm not clear on, but I think the first pass will be just to find the presence of the interface and basic operation. I don't suppose there's any existing tests for that. Not that I'm aware of. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Revisiting LSB [1]
On Sat, 2005-10-08 at 01:49, Ulrich wrote: Sure, but as long as FreeType deterministically produces its results depending on certain parameter settings (including the automatically detected environment) testing is still a matter of deciding whether these results are still the same compared to previously generated results. And like testing other software there has to be a decision by the implementor of the test suite which will be the correct results to use in the comparisions. Testing FreeType's rasterisation would require a set of rasterisation results probably stored in files that have been proven to be correct by human inspection. My claim is that there is no single correct answer. There may be many good solutions. Perhaps with truetype, with the bytecode interpreter turned on there is a deterministic process which should always produce the same answer. But with the autohinter (or postscript hints) I do not believe this is the case. Requiring such leaves no room for improvement of hinting. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ft-2.1.10 and SING
On Sun, 2005-09-18 at 13:23, David Somers wrote: Please find attached a patch against freetype-2.1.10, which allows SING glyphlet font files to be opened by Freetype. Can you provide an example fontlet file for testing? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
RE: [ft-devel] Freetype on Mac uses deprecated functions
On Fri, 2005-09-02 at 01:28, Turner, David wrote: As far as I understand, this warning only applies to code that reads the resource fork directly and doesn't try to read fields in cpu-independent order. Yes... It uses mac specific calls to handle the resource fork. But it also adds some calls, for example one which takes a mac font name, and returns you the filename of a resource file containing that font. And I can't figure that out with the 10.4 API. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype on Mac uses deprecated functions
On Thu, 2005-09-01 at 14:39, Werner LEMBERG wrote: Any volunteers? Neither David nor I use a Mac... I looked into it and was able to fix a few issues, but I've never bothered to learn the new mac calls and got stuck (it used to be possible to get a filename from an open file descriptor but I can't work out how to do that now). So I gave up. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] TT_MAX_COMPOSITE_RECURSE
src/truetype/ttgload.c: says
/* Maximum recursion depth we allow for composite glyphs.
* The TrueType spec doesn't say anything about recursion,
* so it isn't clear that recursion is allowed at all. But
* we'll be generous.
*/
#define TT_MAX_COMPOSITE_RECURSE 5
This value is used to specify the maximum depth allowed to which
composite glyphs may be nested.
But the truetype spec does talk about this, it's a field in maxp
maxComponentDepth. So I suggest the following patch:
(True, there aren't many fonts with composites nested 5 deep, but
someone gave me one)
*** ttgload.c~ 2005-08-28 20:58:37.0 -0700
--- ttgload.c 2005-08-28 20:58:37.0 -0700
***
*** 63,76
#define UNSCALED_COMPONENT_OFFSET 0x1000
- /* Maximum recursion depth we allow for composite glyphs.
- * The TrueType spec doesn't say anything about recursion,
- * so it isn't clear that recursion is allowed at all. But
- * we'll be generous.
- */
- #define TT_MAX_COMPOSITE_RECURSE 5
-
-
/*/
/* */
--- 63,68
***
*** 984,990
#endif
! if ( recurse_count = TT_MAX_COMPOSITE_RECURSE )
{
error = TT_Err_Invalid_Composite;
goto Exit;
--- 976,982
#endif
! if ( recurse_count face-max_profile.maxComponentDepth )
{
error = TT_Err_Invalid_Composite;
goto Exit;
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] randomly corrupting tests
On Fri, 2005-08-26 at 05:44, Werner LEMBERG wrote: I seem to remember talk about testing FreeType on randomly corrupted fonts; has any work on this been done? AFAIK, George has started with some work. For my part, I've done nothing, alas. I have a little program which makes a copy of a font file changes a random byte to a random value (optionally more than 1) passes the result to fontforge and makes sure ff can handle it without crashing. I believe I modified the program to pass the font to the freetype font loader, and posted it to this list. I never ran any significant tests on freetype. (I have used it on fontforge and found a number of flaws in it) Ah yes, I sent my message on 10 Feb 2005 with subject: Re: [ft-devel] tests. I can resend it if anyone likes. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Digital signatures
There has been an argument running on the OpenType list about Digital signatures. I must confess I fail to understand the need for them on a linux/unix platform. Perhaps someone can illuminate me, or perhaps linux/unix is different enough from Windows/Mac that font validation isn't as important. As I understand it, the Digital signature says that someone (who has at one time been in some sense verified to exist) says the font is ok. But it does not say the font has been validated or anything useful, just that someone thought it was ok. (It doesn't even say that the someone wasn't a virus-writer ten years ago when the certificate was obtained who has since moved on from the original location) First of all that seems a very weak form of protection. Secondly I don't really understand what damage a font can do to my system. The worst I can think of is a) crash the X server b) send pango into an infinite loop. To me neither of these seems all that worrying. I don't see how a bad font can have any real effect on the integrity of my system. Perhaps this is more of an issue on a system like the Mac where the system can't come up in a non-windowing mode. So if the font used for the menu is corrupt you are screwed. Am I missing something? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype on Mac uses deprecated functions
On Wed, 2005-08-24 at 09:41, Sean McBride wrote: I am writing here to report a 'bug' of sorts. Basically, it seems the freetype implementation on the Mac is somewhat antiquated. I receive the following warnings about the use of deprecated functions: - FSSpecs should be replaced with FSRefs I started looking at this. Unfortunately the FSSpec type has wormed its way into the API for the mac: FT_EXPORT_DEF( FT_Error ) FT_New_Face_From_FSSpec( FT_Librarylibrary, const FSSpec *spec, FT_Long face_index, FT_Face *aface ) FT_EXPORT_DEF( FT_Error ) FT_GetFile_From_Mac_Name( const char* fontName, FSSpec* pathSpec, FT_Long*face_index ) David, how do you want to handle this? It looks as though the API will have to change to avoid this depreciated type. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype on Mac uses deprecated functions
On Thu, 2005-08-25 at 06:59, Sean McBride wrote: Well, from the look of FMCreateFontFamilyIterator's docs, FreeType already needs Mac OS 9. The mac code contains #ifdefs and there is an #ifdef enabling MAC_OS8. Whether it works any more I haven't the faintest idea (probably not because the FMCreateFontFamilyIterator is not #ifdefed) I presume the proper approach is to add a MAC_OS9 #ifdef. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype on Mac uses deprecated functions
On Thu, 2005-08-25 at 09:25, Sean McBride wrote: Or you could deprecate FT_New_Face_From_FSSpec() and add a new analogous API FT_New_Face_From_FSRef(). Obviously. But that changes freetype's API too. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] TrueType GX/AAT validator
On Mon, 2005-08-22 at 23:17, [EMAIL PROTECTED] wrote: As written in README, some of TrueType GX tables (mort, feat, prop) are widely used, others (lcar, opbd) are very rare, and there are a few tables (kern format1) we cannot find samples. I have one example font containing a kern format 1 table (which David Opstad, formerly at Apple, made for me). He did not say I should not distribute it so I shall pass it on to you (off list). The table specifies kerning for the three glyphs F, . and quotedouble. Given the string 'F.' then the F. pair is kerned by -382 the '.' pair is kerned by 0 Otherwise given '.' the pair is kerned by -526 Otherwise given F. the pair is kerned by -382 (the final bit of a kerning offset in the ValueTable marks the end of the value list, so the kerning offset has a resolution of 2 FUnits rather than 1, thus the -382 above actually appears as -381) As with the ligature state machine, the offsets are applied as the glyphs are popped off the stack (which appears backwards). So in the F. case, first the glyph is popped (with an offset of 0) and then the . glyph is popped (with an offset of -381). ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] TrueType GX/AAT validator
On Tue, 2005-08-23 at 08:18, [EMAIL PROTECTED] wrote: Based on your detailed analysis (thanks again), I removed the line - state transition diagram uses undefined glyph ID from the essential error list, and add following paragraph into the section. If I'm misunderstanding, please let me know. I think your summary matches what I said. In addition, gxvalid doesn't check temporal glyph ID used in the chained State Machines (in mort and morx tables). I've never seen it in a 'mort' table, it is much less likely to occur there. A 'morx' table allows a compact representation of substitution tables associated with a state machine, while a 'mort' table requires a per-glyph lookup. So using a glyph ID like 32000 (Zapfino does) would require a huge lookup. I would leave the check in but flag it as a warning myself of the glyph renderer. To validate such temporal glyph ID, gxvalid must stack all undefined glyph IDs which is possible in the output of previous State Machine and search them in ClassTable of current State Machine. Checking that they occur in the class table isn't a requirement since a substitution can occur on a glyph in class 1 (the class of unspecified glyphs). So a state machine could be built which made such GIDs vanish even if they didn't get named in the class table. I think quick hack is not enough to solve this issue, so I want to put it to TODO of gxvalid. Um... I think this is equivalent to the halting problem -- at least I think you'd want to run all secondary state machines and make sure they made the GIDs vanish in all possible contexts. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] TrueType GX/AAT validator
On Tue, 2005-08-23 at 14:50, George Williams wrote: a) 14 fonts uses too-large feature number (out of defined range). b) 67 fonts uses feature number which should not be used. c) 117 fonts set wrong feature range (nSetting). this infraction is found in mort/morx. The 'feat' (and 'mort') documentation says: Apple has defined a standard set of text features. You may include one or more of these or create your own text features. Font features that will be supported by your font must be part of the Font Feature Registry maintained by Apple Computer, Inc. Sorry I didn't finish... I think the real reason feature/settings must be extensible (use numbers not defined in Apple's Registry) is that there would be no need for the 'feat' table otherwise -- it conveys no information that is not already in the registry. So: a) 14 fonts uses too-large feature number (out of defined range). I can't find anything that says the range is a byte, but there may be something I've missed. b) 67 fonts uses feature number which should not be used. I'm assuming this means features not defined in Apple's Registry. I think this should be ok. Or did you mean that 'morx' referred to a feature not defined in 'feat'? That one should be illegal. c) 117 fonts set wrong feature range (nSetting). do you mean that more settings are defined for a feature than are present for that feature in the 'feat' table? If so, I agree this should be an error. Or do you mean more settings are defined than are present in the registry? I think that should be ok. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] discussion of truetype glyph loading code
On Mon, 2005-08-08 at 22:50, Werner LEMBERG wrote: This snippet is in deciding the mac scale of component offsets. It is commented out because the result is bad. But in this page http://developer.apple.com/fonts/TTRefMan/RM06/Chap6glyf.html, the algorithm described is slightly different (typo?) from what we use here. I have no idea whether this makes any difference. George? The algorithm in the freetype code is one I determined empirically after watching what apple's rasterizer actually did. I performed my tests some years ago so the memory has somewhat faded. If you look at what Apple documents you will note that at angles very close to 45° the scale factor should suddenly double. I never observed this to happen. - if ( a - b = 33 a - b = -33 ) + if ( a - c = 33 a - c = -33 ) This is another case where I believed the apple docs to be in error. What is documented does not make sense and is not congruent to the code around it. m is defined in terms of a and b. n is defined in terms of c and d. n is scaled in terms of c and d. It seems unlikely to me that m should be scaled in terms of a and c. But since I never observed the doubling of the scale factor at any orientation I gave up on the whole concept. If anyone wants to play with this again I've included a patch (to fontforge) which will make ff generate composite glyphs with the scaled bit set (it only sets the bit, it does not recalculate the offsets to match the bit). Create a glyph containing a rotated and offset reference to some other glyph and see how it is rasterized. *** tottf.c~ 2005-08-09 07:17:16.0 -0700 --- tottf.c 2005-08-09 07:17:29.0 -0700 *** *** 1096,1103 --- 1096,1107 /*if ( sc-layers[ly_fore].refs-next==NULL || any )*/ continue; } + #if 0 flags = (11)|(12)|(112); /* Args are always values for me */ /* Always round args to grid */ + #else + flags = (11)|(12)|(111); /* Test version to play with scaled components */ + #endif /* There is some very strange stuff wrongly-documented on the apple*/ /* site about how these should be interpretted when there are */ /* scale factors, or rotations */ ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] looking for truetype fonts for testing
On Mon, 2005-08-01 at 21:56, Chia I Wu wrote: I'm looking for truetype fonts with apple's variation tables The standard example I use is Skia, a font that ships with the mac. I've seen others mentioned but don't know where to find them. or with composite glyph constructed with various different flags, especially with ARGS_ARE_XY_VALUES and UNSCALED_COMPONENT_OFFSET set to false. I believe Chicago (also ships with the mac) uses this. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
