"PV" == Paul Vojta writes: >> above you wrote "I have looked into supporting TrueType in xdvi", >> which as far as i understand shall mean ability to render (using >> freetype library) glyphs directly from TrueType fonts,
PV> Correct (so far) >> and of course also selecting the needed glyphs of the TrueType >> fonts according to the ReEncodeFont instructions from the MAP >> files. PV> AFAIK there is only one .map file, ttfonts.map, which plays a PV> role similar to that played by psfonts.map used by dvips. hey, forget about ttf2pk and it's ttfonts.map. :-) e.g. pdftex natively supports TrueType fonts and it doesn't care what ttf2pk has in it's ttfonts.map (and this map is only needed for re-mapping the glyphs in the TrueType fonts, and not for rendering). pdftex just understands the same syntax for re-mapping the TrueType fonts as for Type 1 fonts (via ReEncodeFont), and also understands other dvips-like syntax like ExtendFont, SlantFont, etc. so does xdvi with it's ps2pk.map: why re-invent the wheel and care about syntax of ttfonts.map? just continue to use your ps2pk.map's syntax for truetype fonts as well. >> yet, later you write about ttf2tfm and ttf2pk and how they are >> using old freetype library etc. >> >> i do not see any relation between "support of TrueType in xdvi" >> and those two programs - ttf2tfm and ttf2pk. there is no relation >> whatsoever. ttf2tfm is one of the many ways to create TFM metrics >> from the TrueType fonts, and ttf2pk is, as you know, just a >> converter from TrueType to PK for those programs which DO NOT >> support TrueType, and thus need to fall back to use PK fonts. >> >> could you please explain what do you mean? PV> AFAIK ttf2tfm is the only (or at least the most commonly used) PV> way to create tfm files from ttf fonts. not so. other ways are: ttf2afm + either afm2tfm or fontinst or whatever else. TrueType font contains a set of glyphs (usually bigger than 256) and for TeX to access them we use the ReEncodeFont mechanism - which is not something new: the same is valid for Type 1 fonts. and the ReEncodeFont (with some encoding vector), when applied to TrueType font, shall get access to the 256 arbitrary glyphs present in TrueType font (wither by their names as specified in the POST table or by their unicode indexes). that's it: forget about ttf2pk, ttf2tfm and ttfonts.map - you have freetype API to access any glyph in the font, and don't have to mimick ttf2tfm's map file syntax. PV> The problem is that I need to be able to mimic ttf2tfm's way of PV> assigning character codes. It messes them up, and I don't fully PV> understand its algorithm due to its use of features present in PV> freetype1 but not freetype2. For example, do the following: PV> % cp /xp/WINDOWS/Fonts/comic.ttf . PV> % ttf2tfm comic.ttf -P 1 -E 0 PV> % echo 'comic comic.ttf Pid=1 Eid=0' > ttfonts.map PV> % ttf2pk comic 300 PV> % tex testfont PV> This is TeX, Version 3.141592 (Web2C 7.5.4) PV> (/usr/local/texmf/tex/plain/base/testfont.tex PV> Name of the font to test = comic PV> Now type a test command (\help for help):) PV> *\table\bye PV> [1] PV> Output written on testfont.dvi (1 page, 11184 bytes). PV> Transcript written on testfont.log. PV> % xdvi testfont PV> Notice that 'A' (ascii '101) appears instead in position '041. PV> And so on. that's because your example is such - you did not ask to re-encode to some useful encoding. use the following instead: cp .../comic.ttf . cp .../cork.enc . ttf2tfm comic.ttf -p cork.enc # some glyphs will not be found which is OK echo 'comic comic.ttf Encoding=cork.enc' > ttfonts.map ttf2pk comic 300 ... PV> If a user's document was TeXxed using tfm files created by PV> ttf2tfm, then xdvi needs to use that same encoding. yes, - just use the *.enc file which selects the same glyphs or unicode indices from the TrueType fonts and ReEncodeFont. Best, v. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
