[NTG-pdftex] [PATCH v3] pdftex - Add support for encfile and \pdfgentounicode for PK fonts

Pali Rohár pali.rohar at gmail.com
Mon Mar 27 09:59:34 CEST 2017


On Sunday 26 March 2017 23:01:20 Karl Berry wrote:
>     %\pdfmapline{cmr10 <8r.enc}
>     \font\ff=cmr10
>     \font\fg=cmr10 at 60pt
> 
> As Akira described: without the \pdfmapline, there are two different
> Type3 fonts. I presume that one is constructed from cmr10.600pk and one
> from cmr10.3600pk.

Yes, something which I found too.

> With the \pdfmapline, the PDF output has only one Type3 font. I surmise
> it is cmr10.600pk geometrically scaled by a factor of 6, hence the
> extremely visible jaggies. (By the way, you can see the usual bitmap
> jaggies in all cases if you sufficiently increase the magnification in
> your PDF viewer, so at least it's clear that bitmaps are correctly being
> used in all cases.)

Yes, scaling bitmap fonts does not work, but if it is generated for
correct DPI, then printed (at paper) looks nice...

> In other words, something in your patch is causing pdftex to reuse the
> first (normal) instance of cmr10 for the second (at 60pt) instance,
> instead of creating a new instance. However, I'm afraid I have no
> immediate clue about where to find the problem in the code. It was your
> patch :), so maybe you'll have a better idea of how to debug? I hope so,
> because it's not a project I can undertake.

Now I did some investigation, and basically it is not in my patch...

It is even documented in pdftex-t.tex

  Lines containing nothing apart from {\em tfmname} stand for scalable
  Type~3 fonts. For scalable fonts as Type~1, TrueType and scalable Type~3
  font, all the fonts loaded from a \TFM\ at various sizes will be included
  only once in the \PDF\ output. Thus if a font, let's say \type{csr10}, is
  described in one of the map files, then it will be treated as scalable. As
  a result the font source for csr10 will be included only once for
  \type{csr10}, \type{csr10 at 12pt} etc. So \PDFTEX\ tries to do its best
  to avoid multiple embedding of identical font sources. Thus vector \PGC\
  fonts should be specified as scalable Type~3 in map files like:

  \starttyping
  csr10
  \stoptyping

  It doesn't hurt much if a scalable Type~3 font is not given in map files,
  except that the font source will be embedded into the \PDF\ file multiple
  times for various sizes, which causes a much larger \PDF\ output. On
  the other hand if a font in the map files is defined as scalable Type~3
  font and its \PGC\ source is not scalable or not available, \PDFTEX\
  will use \PK\ fonts instead; the \PDF\ output is still valid but some
  fonts may look ugly because of the scaled bitmap.

But what surprised me is that it is not possible to use this
construction, specifying only name of metric file in map line. pdftex in
this case show error

$ pdftex '\pdfmapline{csr10}\bye'
This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian)
(preloaded format=pdftex)
 restricted \write18 enabled.
entering extended mode

pdfTeX warning: pdftex: invalid entry for `csr10': both ps_name and font file missing
No pages of output.
Transcript written on texput.log.

Side effect of my patch is that it allowed to use this construction in
case enc file is specified.

So I suggest to either update documentation or allow such construction
(even without enc file). IIRC just check for that error message "both
ps_name and font file missing" needs to be updated, similarly like I did
it in my patch for enc file.

====

Anyway, I did deeper investigation and find something. Probably function
hasfmentry(f) is used for checking if font f is scalable or not.
Specially in function pdf_init_font() in file pdftex.web.

So to allow using enc file for PK font which is not scalable we need
another syntax in map line which say that particular font is not
scalable.

Or maybe... another option. Currently pdftex first search for pgc font
and then fallback to pk font. It is implemented in function writet3()
around t3_open() in file writet3.c. Also documented in pdftex-t.tex

  If a used font is not present in the map files, first \PDFTEX\ will
  look for a source with suffix \type{.pgc}, which is a so||called \PGC\
  source (\PDF\ Glyph Container) \footnote {This is a text file containing
  a \PDF\ Type~3 font, created by \METAPOST\ using some utilities by Hans
  Hagen. In general \PGC\ files can contain whatever is allowed in a \PDF\ page
  description, which may be used to support fonts that are not available
  in \METAFONT. \PGC\ fonts are not widely useful, as vector Type~3 fonts
  are not displayed very well in older versions of Acrobat Reader, but may
  be more useful when better Type~3 font handling is more common.}. If no
  \PGC\ source is available, \PDFTEX\ will try to use \PK~fonts as \DVI\
  drivers do, creating \PK~fonts on||the||fly if needed.

What about splitting specification for PK fonts and PGC fonts in map
file and probably make all PK fonts automatically not scalable? As I
think bitmap fonts generated for specific DPI is really not scalable.

Anyway, is there some script or program which can generate any PGC
files? Quick look at google does not find anything, even not any
specification for that file. I could probably decode it from pdftex
source code...

-- 
Pali Rohár
pali.rohar at gmail.com


More information about the ntg-pdftex mailing list