>>> 1. Are there fonts designed for the purpose of debuging >>> interpreters? > >> Not really, AFAIK. You can however compare the results of >> FreeType's `ttdebug' program with your stuff. Additionally, >> Microsoft's VTT is also available. > > Great. This will help me.
You have seen yesterday's announcement of http://blog.typekit.com/2016/12/04/annotated-opentype-specification-software-now-open-source I suppose. I haven't had a look yet, but maybe bytecode issues are covered also. > using "pointsize", and give intended sampling through MPPEM. > >>> 3. CVT-table (from font-file): >>> spec unclear (apple says 4 bytes per elem), > >> Unclear? 4 bytes per element is correct. > > According to > > https://www.microsoft.com/typography/otspec/cvt.htm > > it's an array of FWORDS, wich in turn are 16 Bit FUnits: > > https://www.microsoft.com/typography/otspec/otff.htm Ah, ok. Never trust the memory :-) And Apple is wrong! https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6cvt.html It's obviously a typo: You get the size by dividing the length in the `table directory' by 2, not by 4. >> The basic unit for bytecode is 1/64th pixel, and you *always* scale >> by PPEM, not pointsize – while the latter is absolute, it has no >> connection to the output device resolution. > > But the CVT-entries don't have their own direction-vector. Right. You have to maintain an array of scaled CVT entries that must be updated after `prep' is run. > For example. assume the prep program has left the projection vector > at a non-default value when it finished. Should subsequent glyph > programs all start up with that projection vector, or should they > start up with the default? You should start with the default. >>> What about zone0 init? > >> Missing in the spec, but it is always reset and re-initialized in >> the MS implementation before a glyph gets rendered, IIRC. > > Hmn, ok, but there are fragments of memo in my brain that I might > have read exactly the opposite somewhere, something like: let the > prep govern the storage AND CVT values for the glyph progs. Buut I > can't find it back, maybe the memo-fragment is wrong. ??? What has zone 0 to do with storage and CVT? > I have already implemented most bytecode commands, and none of wich > makes use of this state, even those that according to some specs > would use it (without mention how). > > For example, the GC[a] command as described here: > https://developer.apple.com/fonts/TrueType-Reference-Manual/RM05/Chap5.html#GC > > In the OpenType specs, the dual projection vector doesn't appear in > the list of used states for GC[a]. Bad documentation, alas. > So does it probably have to anything to do with these old > angle-related commands that are already obsolete? No, they *are* used in those commands. I recommend to check the FreeType implementation. For example, there is the following comment for GC and MD: XXX: UNDOCUMENTED: Measures from the original glyph must be taken along the dual projection vector! Werner _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
