Using TrueType fonts in (La)TeX is not as good as it could be: True Type
-fonts must be converted to Type 1 -format and in that process some of
its quality may be lost. First example that comes to my mind is
Bitstream Vera -fonts in CTAN (they are under name bera).

It is possible to use True Type-fonts in pdf(La)TeX, of course, but what
I want is a possibility to use those font under normal (La)TeX, too. And
in normal (La)TeX it must be done via dvips. I do not want to use
proprietary software, like TrueTeX, for that.

Maybe dvips could do it internally like this: Convert that True Type
-font to Type 42 -format and then embed it it PostScript-file. IIRC Type
42 -formatted fonts are just wrapped True Type -fonts.

On 21.05.04 Juhapekka Tolvanen (juhtolv@cc.jyu.fi) wrote:

Hi,
Does http://www.radamir.com/tex/ttf-tex.htm not contain what you
want?

H.

On Fri, 21 May 2004, +17:57:26 EEST (UTC +0300),
Hilmar Preusse <hille42@web.de> pressed some keys:

"This is sufficient for generating DVI file, but to view or print it,
there should be a raster (pk) font. MiKTeX will attempt to generate it
automatically with new utility: ttf2pk. For successful generation ttf2pk
should find both TrueType font and encoding file. It happens that ttf2pk
can find ttf files, if they are installed and are in a system fonts
directory, and it looks for encoding files in a directory
c:\texmf\pdftex\base\ (among others)."

In the other words: In that process True Type-fonts are embedded as
bitmaps to final PostScript-file. Am I right?

Hi all,

From: Juhapekka Tolvanen <juhtolv@cc.jyu.fi>
Subject: Bug#250216: dvips do not support True Type -fonts
Date: Fri, 21 May 2004 18:43:02 +0300

Hmm, I'm very confused.  I found the statement;

As you can see, this time pdftex has found winfonts.map and
embeded encodingg file T1-WGL4.enc and TrueType fonts times.ttf
and timesbd.ttf into resulting PDF document.

Is this not what you want?  Anyway,

I have an impression that the above your request is a bit
ambiguous...

To use TrueType fonts under (La)TeX should be fairy easy
as the above URL showed and it is a quite another (or different)
issue to use TrueType font for printing or previewing.

Please elaborate your request if possible.

Basically it is possible to use TrueType font for printing
and we Japanese users in fact use TrueType fonts to print
Japanese characters in DVI files.

In a sprit, it would be same strategy as of the above URL but
in short we tell dvips that TrueType font "bar" is a printer
resident font "foo" and dvips generates PS file, then we print
generated PS through gs and gs replaces "foo" with TrueType
font "bar" (this might be not so precise however).

Regards,		      2004-5-23(Sun)

On Sat, 22 May 2004, +18:27:43 EEST (UTC +0300),
Atsuhito Kohda <kohda@pm.tokushima-u.ac.jp> pressed some keys:

Hmm... looks a little bit confusing. It seems in MikTeX dvips uses
encoding files of pdfTeX. BTW I use teTeX under Debian GNU/Linux.

That is not what I want. pdfTeX already knows, how to embed TrueType
fonts to resulting PDF-file. You just need to create TeX font metrics
and font map. There is no need to convert that font to Type 1 at all.

To be exact, I want those TrueType fonts embedded to PostScript file
that dvips created. And when embedding, I do not want them converted to
some bitmap-format. I want that they are embedded in scalable outline
format. They must be embedded as such or as wrapped to Type 42 -format.
Plain conversion from TrueType to Type 1 would lose some of that font's
quality.
not have fonts "bar" or "foo" installed? How (s)he can print or view them?

That's what it's all about: You must embed those fonts to that
PostScript-file. If you embed them as bitmaps, they will look really
ugly when viewed with gv or other PostScript-viewer. I do not want
that.

I found these WWW-pages about Type42-fonts and conversion from TrueType
to Type42:

http://cgm.cs.mcgill.ca/~luc/type42.html
http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/printing.html

I knew it: Type 42 is really a PostScript-wrapper over True Type-format.
Hence, conversion from TrueType to Type 42 can be really losless. And
maybe those Type 42-fonts can be embedded to PostScript-files.

But how is Type 42-support in dvips? If fonts are already converted from
True Type to Type 42 and those fonts and all their fontmaps and font
metrics are in right places, can dvips use them?

Or should it be done like this: Keep original True Type-files in right
place in TDS-compatible directory tree and convert them to Type42 on
the fly only when needed. Save converted files in same directory tree,
where compiled METAFONT-fonts are kept, too.

Well, what are you going to do?

From: Juhapekka Tolvanen <juhtolv@cc.jyu.fi>
Subject: Bug#250216: More about TrueType support of dvips
Date: Sun, 23 May 2004 01:57:25 +0300

Before investigating the above, I'd like to know why
you need PS output rather than PDF.  In case PDF I believe
you can embed TrueType font with dvipdfm if you don't want
to use PDFTeX/LaTeX.

Regards,			2004-5-23(Sun)

From: Juhapekka Tolvanen <juhtolv@cc.jyu.fi>
Subject: Bug#250216: dvips do not support True Type -fonts
Date: Sat, 22 May 2004 19:07:54 +0300

I'm afraid that, only with tfm and font map, ligature
might be lost.

Okay so your real request is dvips should be able to embed
TrueType fonts.  I'm not sure but is it standard that one
embed TrueType fonts in PS file?  I know many documents
on how to embed (or not embed) TrueType fonts in PDF but
in case PS file...?

Off-topic but anyway, in short, Japanese printer (i.e. printer
with Japanes support) is equivalent to have "bar" (in real
name Ryumin-Light) so at least within Japan there is no problem
to assume he/she has Ryumin-Light.  But a real TypeFace(?) in
a final output could be different from one user to another user.

Regards,			  2004-5-23(Sun)

On Sun, 23 May 2004, +17:37:00 EEST (UTC +0300),
Atsuhito Kohda <kohda@pm.tokushima-u.ac.jp> pressed some keys:

1) Having alternative ways of doing things is generally a good thing.

2) pdfTeX is not as bulletproof than normal TeX. Even me myself have
been able to create LaTeX-code that causes warnings or even errors in
pdflatex but works just fine when run through normal latex. What if
somebody wants to use such LaTeX code and same time embed some
TrueType-fonts to his/her LaTeX-code? (S)he is stuck!

3) What if somebody wants to use some TeX- or LaTeX-macro or -package
that for some reason does work at all in pdfTeX or pdfLaTeX? A package
called pstricks comes to my mind: Pages 28-29 of file
/usr/share/doc/texmf/pdftex/base/pdftexman.pdf.gz say:

        "The inclusion of raw PostScript commands --a technique utilized
        by for instance the pstricks package-- cannot be supported.
        Although pdf is a direct descendant of PostScript, it lacks any
        programming language commands, and cannot deal with arbitrary
        PostScript."

Hence, having True Type-fonts and pstricks-package in same document is
awful situation as long dvips don't have good support for True Type
fons.

4) If dvips do not have good support for True Type-fonts, it won't do
well in competition with pdfTeX; People will consider it inferior and
obsolete.

5) Some papers are not meant to be released as PDF. Sometimes people
want just good PostScript-file that can be printed. If they later change
they mind, they can use ps2pdf of GhostScript.
its documentation says. Aha! Page 20 of
/usr/share/doc/texmf/programs/dvipdfm.pdf.gz say:

        "The raw PostScript "ps:" special supported by dvips and other
        drivers. Only a few PostScript operators are supported; dvipdfm
        does not include a complete PostScript interpreter. Complex
        PostScript code, such as that embedded by the PSTricks package,
        is not supported."

Hence, argument 3 still apply.

In the other words: pdfTeX and dvipdfm is not always an option.

From: Juhapekka Tolvanen <juhtolv@cc.jyu.fi>
Subject: Bug#250216: More about TrueType support of dvips
Date: Sun, 23 May 2004 19:12:18 +0300

From the very sentence you cited, I've an impression that
it might be impossible to embed TrueType fonts in PS files
directly and, form the sentence at the bottom, one need to
convert TrueType fonts to, for example, Type42 fonts to embed
them in PS files.  Am I right or not?

My understanding is simple; dvips is a DVI to PS converter
and its counter part is dvipdfm which is a DVI to PDF converter.
in its nature so "The raw PostScript "ps:" special" is
supported by dvips but not supported by dvipdfm is not
so surprising.

From: Juhapekka Tolvanen <juhtolv@cc.jyu.fi>
Subject: Bug#250216: More about TrueType support of dvips
Date: Sun, 23 May 2004 01:57:25 +0300

Then your request is dvips should be able to embed Type42
fonts?

I'm not sure and have not enough time to test Type42 fonts
at present so if someone has confirmed that dvips didn't
support Type42 fonts then I suspect it might be good to report
this to the upstream.

Regards,			2004-5-24(Mon)

Atsuhito Kohda <kohda@pm.tokushima-u.ac.jp> wrote:

a "grep -i type.*42" over the dvipsk sources in tetex-beta_2.96.1 gives
only (probably false positive) hits in testdata/*pdb.

So it seems this is not yet possible.

Regards, Frank

From: Frank Küster <frank@debian.org>
Subject: Bug#250216: More about TrueType support of dvips
Date: Mon, 24 May 2004 11:29:09 +0200

Might be so but there is a statement as follows in
http://cgm.cs.mcgill.ca/~luc/type42.html

	A Type 42 font is a postscript font that wraps
	around a TrueType font.

so I have a little hope that dvips could handle it as
normal postscript font yet.  But it might be time to
forward this to the upstream.

				2004-5-24(Mon)

Atsuhito Kohda <kohda@pm.tokushima-u.ac.jp> schrieb:

Yes, I implied that they cannot be used as normal postscript fonts - but
any support for the type 42 wrapper should turn up somewhere in the
sources. This is what I wanted to check. Will you submit it to upstream?

Regards, Frank

From: Frank Küster <frank@debian.org>
Subject: Bug#250216: More about TrueType support of dvips
Date: Mon, 24 May 2004 14:34:08 +0200

I'm very glad if you submit it to upstream.  My English
might be so poor and ...

Regards,			2004-5-24(Mon)

dvips cannot convert from ttf to type 42 but ttftot42 can. Once that is
done the type 42 can be treated like a type 1 font with one exeption:
dvips does not support subsetting of type 42 fonts, so you will have
to tell dvips to include the complete font.
If you are looking for a ttftot42 debian package, than let me know.

  Uwe

dvips cannot convert from ttf to type 42 but ttftot42 can. Once that is
done the type 42 can be treated like a type 1 font with one exeption:
dvips does not support subsetting of type 42 fonts, so you will have
to tell dvips to include the complete font.
If you are looking for a ttftot42 debian package, than let me know.

  Uwe

dvips can handle type 42 fonts. It just cannot subset the font.
I've written a program to install type 1 and tt fonts for TeX/LaTeX/pdftex.
It uses ttftot42 to convert ttf to type 42 and then just proceeds as
with type 1 fonts.

  Uwe

uwe@steinmann.cx (Uwe Steinmann) wrote:

Yes, I couldn't find any.

Regards, Frank

uwe@steinmann.cx (Uwe Steinmann) wrote:

Ah, that means that dvips can handle them, but it cannot convert ttf to
type42 on-the fly, right? The name "wrapper font for ttf" that was
attributed to the type42 fonts previously in this bug made me think that
no conversion is necessary.

Since you have experience in this, you can probably tell us whether it
would be, in principle, possible, and sensible and in accord with dvips'
design, to include the conversion into dvips proper?

Anyway, I remember faintly that you announced your program. Did you
upload it to CTAN, and do you know of any users? Is it possible to
integrate it into teTeX's mechanism of generating necessary font files
on-the-fly, so that the type42 fonts could be generated just as pk fonts
are?

Thanks in advance, Frank

Adding

deb http://www.steinmann.cx/debian/dists sid/powerpc/
deb-src http://www.steinmann.cx/debian/dists sid/source/

to your sources.list should do it. There is currently
no i386 version, but it can be easily compiled from the source.

  Uwe

Hi,
As you seem to be an official Debian developer. Is it possible to
upload these package to Debian?
I can build your package, but not install it:

drachi:[~] #mc
drachi:[/home/hille] #dpkg -i ttftot42_0.3.1-2_i386.deb
Selecting previously deselected package ttftot42.
(Reading database ... 117019 files and directories currently installed.)
Unpacking ttftot42 (from ttftot42_0.3.1-2_i386.deb) ...
Setting up ttftot42 (0.3.1-2) ...
cannot open dhelp file '/usr/share/doc/ttftot42/html/.dhelp': at /usr/sbin/install-docs line 559.
dpkg: error processing ttftot42 (--install):
 subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
 ttftot42

You're leaving a file /usr/share/doc-base/ttftot42, but the
documentation mentioned there does not exist.

H.

I'll have look at it. If there are more people seeing a need for
it in official debian, I wouldn't mind to upload it.

  Uwe

Hi all,

are there any plans to enable dvips to include TrueType fonts in a
Postscript file, by wrapping them up as Type42 fonts?  We had this
request as a Debian bug report (http://bugs.debian.org/250216).  It
seems there are solutions only with external programs that create the
type42 fonts, and those solutions aren't well integrated.

Thanks for considering,
Frank

    are there any plans to enable dvips to include TrueType fonts in a
    Postscript file, by wrapping them up as Type42 fonts?

I am not aware of anything along these lines.  Tom?

If there is some TrueType+TeX volunteer interested in working on it,
patches would be welcome, I'm sure.  I also feel sure there are a lot of
subsidiary issues.  It would be good to be compatible with pdftex's
truetype support, if that makes sense.  (I'm not too familiar with what
pdftex can and can't do with truetype.)

Support for OpenType would probably be even more useful going forward.
Do you know if they be handled via Type42?  Or some other way?

Best,
Karl

I have looked into supporting TrueType in xdvi.  A key subsidiary issue
that came up (and stopped it for me) was compatibility with ttf2tfm and
ttf2pk.  They come up with their own character encoding that basically
(as I recall) chooses the lowest-numbered 255 or 256 available
characters into the encoding vector.  Adding to the difficulties is
the fact that ttf2tfm/ttf2pk use the old (version 1) freetype library.
I tried porting these programs to freetype2, but the latter lacks some
features of the original freetype, and is never likely to have them
(Werner Lemberg said that programs should use pango instead for these
features).

Karl> Support for OpenType would probably be even more useful going
Karl> forward.  Do you know if they be handled via Type42?  Or some
Karl> other way?

[Pre Scriptum:  written for the archives and the CCed bugreport;
 not just for the people on the CC list.... -JimC]

If by OpenType you mean sfnt/CFF fonts, you just embed the (optionally
subsetted) CFF table mostly just like a type1.  (The CFF table is in
type2 format; you may need to convert the outlines to type1 depending
on which version of postscript is targeted.  It may also be CID keyed;
that may also require a conversion.)  The rest of the tables are only
relevant for deciding which glyphs to set for a given string and what
if any kerning is required.

Type42 works for all sfnt/glyf fonts, no matter what additional tables
they have.  (OpenType, AAT, Graphite, et al.)

"PV" == Paul Vojta writes:

 PV> I have looked into supporting TrueType in xdvi.  A key subsidiary
 PV> issue that came up (and stopped it for me) was compatibility with
 PV> ttf2tfm and ttf2pk.  They come up with their own character
 PV> encoding that basically (as I recall) chooses the lowest-numbered
 PV> 255 or 256 available characters into the encoding vector.  Adding
 PV> to the difficulties is the fact that ttf2tfm/ttf2pk use the old
 PV> (version 1) freetype library.  I tried porting these programs to
 PV> freetype2, but the latter lacks some features of the original
 PV> freetype, and is never likely to have them (Werner Lemberg said
 PV> that programs should use pango instead for these features).

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, and of course
also selecting the needed glyphs of the TrueType fonts according to
the ReEncodeFont instructions from the MAP files.

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?

Best,
v.

Correct (so far)

AFAIK there is only one .map file, ttfonts.map, which plays a role similar
to that played by psfonts.map used by dvips.

AFAIK ttf2tfm is the only (or at least the most commonly used) way to
create tfm files from ttf fonts.  The problem is that I need to be able
to mimic ttf2tfm's way of assigning character codes.  It messes them up,
and I don't fully understand its algorithm due to its use of features
present in freetype1 but not freetype2.  For example, do the following:

	% cp /xp/WINDOWS/Fonts/comic.ttf .
	% ttf2tfm comic.ttf -P 1 -E 0
	% echo 'comic comic.ttf Pid=1 Eid=0' > ttfonts.map
	% ttf2pk comic 300
	% tex testfont
	This is TeX, Version 3.141592 (Web2C 7.5.4)
	(/usr/local/texmf/tex/plain/base/testfont.tex
	Name of the font to test = comic
	Now type a test command (\help for help):)
	*\table\bye
	[1]
	Output written on testfont.dvi (1 page, 11184 bytes).
	Transcript written on testfont.log.
	% xdvi testfont

Notice that 'A' (ascii '101) appears instead in position '041.  And so on.

If a user's document was TeXxed using tfm files created by ttf2tfm, then
xdvi needs to use that same encoding.

"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.

reassign 250216 texlive-binaries
tags 250216 + wontfix
stop

On 21.05.04 Juhapekka Tolvanen (juhtolv@cc.jyu.fi) wrote:

Hi,
Unfortunately this situation did not change in the last 5 years and
probably never will. For now I reassign the bug to the correct
package and tag it wontfix.

H.

Wir grüßen Sie,

wir sind eine Arbeitsvermittlungsagentur und freuen uns Ihnen einige für Sie passende Jobs vorschlagen zu können.

Sind Sie nicht zu 100 Prozent ausgelastet und wollen nebenbei etwas dazu verdienen?
Sind Sie in Rente oder ohne Arbeit?
Sind Sie am liebsten Ihr eigener Vorgesetzter?
Möchten Sie Ihre Beschäftigungszeit und Ihren Arbeitsplatz selbst bestimmen?

Dann haben wir garantiert etwas dass zu Ihnen passt.

Wir vermitteln Jobs EU weit und haben auch etwas für Sie in Ihrer Umgebung, und die Bezahlung beträgt durchschnittlich ab 20 Euro die Stunde

Sollten Sie an dieser Arbeit interessiert sein, so schicken Sie uns ein kurzes Bewerbungsschreiben an SuzySammlandgy@alumnidirector.com und erhalten Sie weitere Einzelheiten.

Mit freundlichen Grüßen

 GmbH

Sehr geehrte Damen und Herren,
umgehend sind folgende Jobs zu besetzen:
Stelle: Prüfer / Qualitätskontrolleur (m/w)
Bezeichnung BKH/01114504
Eine Inventur der Schilderqualität ist in  Deutschland angeordnet.
In wenigen Tagen aktivieren wir unsere Schilder-Check-Tour quer  durch Deutschland, dazu suchen wir voller Energie  Mitarbeiter zur Verstärkung unsere Gruppe.
Ihre Aufgabe wird sich auf das Aufnehmen von zerstörten Straßenschildern, Verkehrsschildern und sonstigen öffentlichen Anlagen beschränken  und kann direkt in Ihrem Region und Ort erledigt werden.
Der Mitarbeiter hat keine Ausgaben zu tragen und muss keine besonderen Kenntnisse mitbringen. Die notwendige  Apparatur wird von uns  kostenlos zur Verfügung gestellt. Auch Rentner sind für diese Arbeitstätigkeit geeignet.  Ihr Lohn beträgt monatlich ca 800 Euro.
Sie sind zielstrebig und sorgfältig, dann sind das sehr gute Voraussetzungen Ihre
Bewerbungsinformationen an uns zu schicken.
Sollten Sie an diesen Arbeitsstellen Interesse haben, dann  wenden Sie an uns ein knappes Bewerbungsschreiben an gpmwfields@seznam.cz und Sie erhalten weitere Einzelheiten zugeschickt.