/* /*
//Microsoft Calibri has embed bitmaps, but they don't appear to be //used, ever, at all.  Instead, GDI uses its broken hinting.  I've //heard Microsoft Windows has to detect for several Japanese //characters in the font before using embed bitmaps. I will ask a Microsoft guy about the details. */ And here they are!  I asked What are the preliminaries to make Windows use embedded bitmaps of a font?  And what about embedded graymaps? and I got the following response: This is specific behavior for our DWrite engine, not GDI or TrueType.  DWrite is oriented around subpixel positioned text, so there is a tradeoff on using embedded 1 bpp bitmaps that can be important for legibility at smaller sizes.  (I don't know the answer to embedded graymaps, but I'll see if I can get an answer to that as well). For your specific question, I talked to Nick on the DWrite team, and he said:   First, there has to be an EBLC table.   Second, we define a set of representative code points for four   East Asian scripts as follows:     Hiragana: U+3044, U+3046, U+3093, U+3057, U+306E, U+304B     Hangul:   U+C774, U+B2E4, U+B294, U+C758, U+C5D0, U+D558     CHS:      U+6C49, U+5B57, U+4E2D, U+7684, U+4E2A, U+4EEC     CHT:      U+6F22, U+5011, U+4E09, U+4E86, U+5B78, U+7232   The font is considered a legacy East Asian font if the following   is true for at least one of the four scripts above:   * The cmap table specifies glyph indices for all six of the     representative code points, and   * The EBLC table has bitmaps for all six of those glyph indices.   Werner */ Uhh I do NOT care about DirectWrite rendering and I never intend to optimize my fonts for it because there are so many flavors of DirectWrite and each applica- tion chooses its own, so it's entirely meaningless to do this. Embed bitmaps are obviously not the hinting solution. Even if the autohinter managed to take bit- maps as an input and hint the outlines to become the bitmap, it wouldn't be a general solution and the non-optimized sizes would look suboptimal because the autohinter doesn't know how to hint diagonals, etc. . Ok so this is a genuine text file generated by Microsoft Notepad. Each newline is 0x0D, 0x0A. The file starts with 0xEF, 0xBB, 0xBF to mark the UTF-8 encoding. The other file formats native to Microsoft Windows are an 8-bit codepage (same newlines, but no indicator at the start) and UTF-16LE (newlines are 0x0D00, 0x 0A00, indicator is 0xFFFE) and UTF-16BE (newlines are 0x000D, 0x000A, indicator is 0xFEFF). I'm only focusing on classic GDI rendering. Classic GDI is what a Windows user gets when ClearType is disabled but smooth edges is left on. Classic GDI has been known to me as the most reliable and best way to display truly hinted fonts as it properly utilizes the TrueType instructions, uses a standard 4Ã4 oversamp- ling, uses correct gamma (deal-breaker with most rendering engines) and automa- tically switches anti-aliasing modes between 4Ã4 and 1Ã1 depending on the 'gasp' table. Can you simulate ALL of the above with FreeType? I don't have a testing environment that I'm sure uses ALL the possible FreeType parameters. The ttfautohint project might give rise to additional side projects: ttfautothin/ttfautoextralight/ttfautolight/ttfautomedium/ttfautosemibold/ ttfautobold/ttfautoextrabold/ttfautoblack â turns the font into a given weight utilizing blue zones. This is NOT a vertical only weight transform. The user can choose parameters for the weight transform. x ttfautoextracondensed/ttfautoovercondensed/ttfautocondensed/ ttfautoundercondensed/ttfautosemicondensed/ttfautofaintcondensed â makes the font narrower, using the method of blue zones. The user can choose parameters. ttfautosmallcapital/ttfautosuperscript/ttfautosubscript/ ttfautosuperscriptsuperscript/ttfautosuperscriptsubscript/ ttfautosubscriptsuperscript/ttfautosubscriptsubscript â adds an OpenType feature, again with blue zones. The user can choose the parameters; for a general-purpose font a good rule of thumb is the cap-height of a superscript or subscript is the x-height of the regular form. Note the correspondence with ttfauto<weight>: a superscript can be thought of as a fixed linear transformation on the x and y coordinates and the width (the transformations are chosen by the user), followed by a weight transform. The above might as well have options to preserve point numbering, making them usable for interpolation, variable fonts (which utilize interpolation) and variable font hinting. ttfautobitmaphint â a fake bitmap font snaps to integer size. We've discussed this before. ttfautooblique â a user-defined linear transformation to slant the font and add the 'italic' parameters to the font. May preserve the vertical hinting created by ttfautohint. ttfautoreference â automatically decomposes glyphs and tries to match them to references. The entire purpose of references is to aid in hinting, and ttfautohint can utilize the font references. Characters like ç and Ä andâÄ will also get references if possible, as well as i. May warn users if the character is not referencable even though it is in the database. May include Control Instructions where users input what glyphs they use, and ttfautoreference will attempt to match them. The match need not be exact, in case of digitized fonts, see ttfautoclone next. ttfautoclone â copies the design of the input font, but does not infringe the copyrights. The way it works, rather than utilizing blue zones, it notes that bitmap fonts are not affected by copyright because they store pure design information. So, the font is first converted to a public domain bitmap font by rasterizing at a large enough size, for example 2048. This can then be autotraced to produce a clone font in the public domain. The extrema are implied by the design, while all the other points are likely to be completely different from the original. ttfautoname â generates random font names. This can be used by font designers to then change the name of the font generated by ttfautoclone to avoid trademark infringement. ttfautoset â Warns the user of missing characters in an input character set. Recommended character sets: Subset1 â https://unicodesubsets.miraheze.org/wiki/Subset1 â contains the very essential 678 characters. Subset2 â https://unicodesubsets.miraheze.org/wiki/Subset2 â an expanded set of 1193 characters. Subset3 â https://unicodesubsets.miraheze.org/wiki/Subset3 â a professional set of 2823 characters. Subset3+ â that's the character set of DMCA Sans Serif 9.0 and has 3309 characters. But also the user can input their own character sets, for example the Japanese characters as in https://japanese2.netlify.com/ . ttfautorenderer â a font renderer that rivals FreeType, uh... itself within the FreeType project. Tries to match the classic GDI quality. Default parameters are like the classic GDI: gamma of 2.3 â correct utilizes full hinting, when gasp hinting is on no anti-aliasing, no symmetric smoothing â 1Ã1 oversampling no anti-aliasing, symmetric smoothing â 1Ã1 oversampling anti-aliasing, no symmetric smoothing â 4Ã4 oversampling anti-aliasing, symmetric smoothing â 4Ã4 oversampling ttfautoedit â This is only for the far future. A set of commands can collectively expand a single font into a fully referenced and hinted public domain font family with OpenType features, but this is also a font editor with advanced features that beat even the artificial intelligence of FontForge.
