MediaWiki API result

{
    "batchcomplete": "",
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "20": {
                "pageid": 20,
                "ns": 0,
                "title": "Using TrueType fonts with pdfTeX",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "=== A closer look at TrueType fonts and pdfTeX ===\nThe most common outline format for TeX is Type&nbsp;1. The TrueType\nformat is slightly different from Type&nbsp;1, and getting it right\nrequires some extra work. In particular, it is important to understand\nhow TrueType handles encoding and glyph names (or more precisely,\nglyph identity).\n\nWe start with Type&nbsp;1, since most TeX users are more familiar with\nit. In the Type&nbsp;1 format glyphs are referred to by names (such as\n''/A'', ''/comma'', and so on). Each glyph is identified by its name; so,\ngiven a glyph name, it is easy to tell whether or not a Type&nbsp;1 font\ncontains that glyph. Encoding with Type&nbsp;1 is therefore simple: for\neach number $n$ in the range 0 to 255, an encoding tells us the name\nof the glyph that should be used to render (or display) the charcode\n$n$. \n\nWith TrueType the situation is not that simple, since TrueType does\nnot use names to refer to glyphs, but uses indices instead. This means\nthat each glyph is identified by its index, not its name. The indices\nare numbers that differ from font to font. The TrueType format handles\nencodings by a mechanism called ''cmap'', which (roughly) consists of\ntables mapping from character codes to glyph indices. A TrueType font\ncan contain one or more such tables (each corresponding to an\nencoding).\n\nSince glyph names are not strictly necessary for TrueType, they are\nnot always available inside a TrueType font. Given a TrueType font,\none of the following cases may arise.\n\n* The font contains correct names for all its glyphs. This is the ideal situation and is often the case for high-quality latin fonts.\n\n* The font contains wrong name for all or most of its glyphs. This is the worst situation that often happens with poor-quality fonts, or fonts converted from other formats.\n\n* The font contains no glyph names at all. Newer versions of Palatino fonts by Linotype (v1.40, coming with Windows XP) are examples of this.\n\n* the font contains correct names for most glyphs, and no names or wrong names for a few glyphs. This happens from time to time.\n\nOne may wonder why things can be so complex with glyph names in\nTrueType. The reason is that Type&nbsp;1 fonts rely on correct names to\nwork properly. If a glyph has a wrong name, it gets noticed\nimmediately. As mentioned before, TrueType does not use names for\nencoding. So, if glyph names in a TrueType font are wrong or missing,\nit is usually not a big deal and often goes unnoticed.\n\nThe potential problem with using TrueType in pdfTeX is that we are\nso used to the Type&nbsp;1 encoding convention, which relies on correct\nglyph names. Furthermore, most font tools rely on this convention and\nall encoding files (.enc files) use glyph names. But, as explained\nabove, glyph names in TrueType are not very reliable. If we encounter\na font that does not have correct names for its glyphs, we need to do\nsome more work.\n\nIf glyph names are not correct, we need a better way to refer to a\nglyph in TrueType fonts, rather than using names. The most reliable\nway seems to be via Unicode: most TrueType fonts provide a correct\nmapping from Unicode value to glyph index. This is something we can\ncount on, since it is required for a TrueType font to be usable.\n\nFrom version 1.21a pdfTeX supports the naming convention ''uniXXXX''\nin encoding (.enc) files. This only makes sense with TrueType fonts,\nof course. When pdfTeX sees for example ''/uni12AB'', it will\n* read the table <unicode> -> <glyph-index> from the font,\n\n* look up the value '12AB' in the table, and if found then pick the relevant glyph index.\n\nttf2afm also does the same lookup when it sees names like ''uni12AB''.\n\nNow let us review the minimal steps to get a TrueType font working\nwith pdfTeX:\n* generate an afm from TrueType using ttf2afm. Example:\n<pre>\nttf2afm -e 8r.enc -o times.afm times.ttf\n</pre>\n\n* convert afm to tfm using whatever tool suitable: afm2tfm, fontinst, afm2pl, etc. Example:\n<pre>\nafm2tfm times.afm -T 8r.enc\n</pre>\n\n* create the needed map entry for the font. Example:\n<pre>\n\\pdfmapline{+times TimesNewRomanPSMT <8r.enc <times.ttf}\n\\font\\f=times \\f Hello this is Times.\n</pre>\n\nThe above deals with the easiest case: when glyph names are correct.\nNow let us consider a font where we cannot rely on glyph names:\nPalatino by Linotype version 1.40, for example. Let us assume that we\nwant to use the T1 encoding with this font. So we put pala.ttf and\nec.enc in the current directory before proceeding further.\n\nThe first attempt would be:\n<pre>\nttf2afm -e ec.enc -o pala.afm pala.ttf\n</pre>\n\nHowever, since the names in ec.enc are not available in pala.ttf (in\nfact there are no names inside the font), we get a bunch of warnings:\n<pre>\nWarning: ttf2afm (file pala.ttf): no names available in ''post'' table, print\nglyph names as indices\nWarning: ttf2afm (file pala.ttf): glyph ''grave'' not found\n...\n</pre>\n\nand the output pala.afm will contain no names at all. Instead of glyph\nnames in ec.enc, we get weird things like ''index123''. And glyphs are\nnot encoded:\n<pre>\nC -1 ; WX 832 ; N index10 ; B 24 -3 807 689 ;\n...\n</pre>\n\nWe try again, this time without giving an encoding:\n<pre>\nttf2afm -o pala.afm pala.ttf\n</pre>\n\nSince this time we did not ask ttf2afm to re-encode the output afm, we get\nfewer warnings:\n<pre>\nWarning: ttf2afm (file pala.ttf): no names available in ''post'' table, print\nglyph names as indices\n</pre>\n\nand the afm output is the same as in the previous attempt. This is not\nvery useful, since there is little we can do with names like\n''index123''.\n\nSo we try to go with Unicode:\n\n<pre>\nttf2afm -u -o pala.afm pala.ttf\n</pre>\n\nThis time we get a different bunch of warnings, for instance:\n<pre>\nWarning: ttf2afm (file pala.ttf): glyph 108 have multiple encodings (the\nfirst one being used): uni0162 uni021A\n</pre>\n\nAt first sight it is hard to understand what tfm2afm is telling us with\nthis message. So let us recap the connection between glyph name, glyph index\nand Unicode value:\n* TrueType glyphs are identified internally by index.\n\n* <glyph-name> -> <glyph-index> is optional, and not always reliable. Likewise <glyph-index> -> <glyph-name>.\n\n* <unicode> -> <glyph-index> is (almost) always present and reliable.\n\n* <glyph-index> -> <unicode> is not always reliable, and need not even be a mapping, since there can be more than one Unicode value mapping to a given glyph index. Given a glyph index, there may be no corresponding Unicode value, or there may be more than one. If there is none, the glyph index will be used (''index123'', for example). Now suppose that there are more than one, as in the case above (where 0162 and 021A are both mapped to glyph index 108). We have asked ttf2afm to print glyphs by Unicode, and ttf2afm cannot know for sure which value to print in this case. Hence it outputs the first Unicode value and issues the warning.\n\nNow if all we want is to use pala.ttf with T1 encoding, probably the\neasiest way is to create a new enc file ec-uni.enc from ec.enc, with\nall glyph names replaced by Unicode values. (This simple approach\nwon't handle ligatures; see below.) This can be done easily for\nexample by a script that reads the AGL (Adobe Glyph List, available at\nhttp://www.adobe.com/devnet/opentype/archives/glyphlist.txt) and\nconverts all glyph names to Unicode. Assuming that we have ec-uni.enc,\nthe steps needed to create the tfm are as follows.\n<pre>\nttf2afm -u -e ec-uni.enc -o pala-t1.afm pala.ttf\nafm2pl pala-t1.afm\npltotf pala-t1.pl\n</pre>\n\nWe could then use the font as follows.\n<pre>\n\\pdfmapline{+pala-t1 <ec-uni.enc <pala.ttf}\n\\font\\f=pala-t1\\f\nThis is a test of font Palatino Regular in T1 encoding.\n</pre>\n\nIf we want to do more than just using pala.ttf with T1 encoding, for\nexample processing the afm output with fontinst for a more complex\nfont setup, then we must proceed slightly differently. Having an afm\nfile where all glyph names are converted to ''uniXXXX'' form is not very\nuseful for fontinst. Instead, we need an afm file with AGL names to\nuse with fontinst. We can do this as follows.\n\n* Generate an afm  with glyph names in form ''uniXXXX''.\n<pre>\nttf2afm -u -o pala.afm pala.ttf\n</pre>\n\n* Convert pala.afm to pala-agl.afm, so that pala-agl.afm contains AGL names only. Again, a simple script can do that.\n\n* Process pala-agl.afm by fontinst as needed.\n\n* In the final stage, when we already have the tfm's from fontinst and friends, plus the map entries (generated by fontinst, or created manually), we need to replace the encoding by its counterpart with ''uniXXXX'' names. For example, if fontinst tell us to add a line saying\n<pre>\npala-agl-8r <8r.enc <pala.ttf\n</pre>\nto our map file, then we need to change that line to\n<pre>\npala-agl-8r <8r-uni.enc <pala.ttf\n</pre>\nwhere 8r-uni.enc is derived from 8r.enc by converting all glyph\nnames to the ''uniXXXX'' form.\n\nThe encoding files coming with TeX Gyre fonts cover almost everything a\ntypical TeX user might need. Those encodings have been converted to the\n''uniXXXX'' form for your convenience and are available at\nhttp:/\\!/tug.org/fontname and are named like ''q-ec-uni.enc'' etc.\n\nAnother problem that happens from time to time is the case when we are\ntotally sure that a glyph exists inside a font but we don't get that\nglyph in the output of pdfTeX. The likely reason of this problem is\nthat the glyph is referenced by different names at various places\nduring the process of creating support for the font, like tfm, vf, enc\nor map files. For example the names ''dcroat'', ''dbar'', ''dslash'' and\n''dmacron'' can all refer to the same glyph in a TrueType font. The\norigin of a glyph name can come from several sources:\n\n* the name comes from the font itself.\n\n* the name comes from a predefined scheme called ''the standard Macintosh ordering of glyphs''. Unfortunately the TrueType specifications by various companies (Apple, Microsoft and Adobe) are not consistent in this scheme and there are small differences; one example is ''dmacron'' vs ''dslash''.\n\n* the name comes out after conversion <unicode> -> <glyph-name> according to AGL.\n\nIn such situation, probably the easiest and safest way to get the\nglyph we want is to use a font editor like FontForge, look into the\nfont to find out the Unicode for the glyph and then use the ''uniXXXX''\nform to instruct ttf2afm and pdfTeX to pick up that glyph.\n\nAnother way to get a problematic TrueType font to work with pdfTeX\nis simply to convert the font to Type&nbsp;1 format using FontForge. While\nit sounds like a quick hack, it can be a simple and effective\nworkaround."
                    }
                ]
            },
            "88": {
                "pageid": 88,
                "ns": 0,
                "title": "XML coversheet",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": ""
                    }
                ]
            }
        }
    }
}