Re: pdftex - Encoding for metafont PK fonts

Hello Pali, and Paul

On Jun 26, 2016, at 7:21 AM, Pali Rohár <[email protected]<mailto:[email protected]>> wrote:

Maybe PDF readers could think that font is not in Latin1, but in
Unicode as IIRC Unicode at positions 128-255 have same characters
as Latin1 encoding.

Unicode character U+00E8 is for sure 'è'. So I bet this is reason
why PDF reader thinks that I selected character 'è' and not 'č'.

For Type 1 PFB fonts (even in IL2 encoding) this is not a problem,
because for each characters there is stored unified glyph name and
there is standard conversion table from glyph name to unicode
character.

So probably in PK fonts is not any conversion table from 8bit
character to unicode character and so something (pdftex? PDF
reader?) assume either Latin1 or Unicode.

What you need is a CMAP resource, which gets associated
with the Font-Descriptor dictionary, not with the font itself.

This is what is done with PFA and PFB fonts, and others.
So I don’t see why you cannot also do this with PK fonts.

The question then becomes “who or what creates the CMAP?”.

pdfTeX has a primitive  \pdfgentounicode  which if set to 1 (or higher)
causes an attempt to create the CMAP internally, based upon glyph names
and using a standard list of font character names.
Extra info can be provided by the  \pdfglyphtounicode  primitive,
as you have encountered in an earlier posting.

But Metafont-produced pk-fonts tend to use lazy generic names for
characters, such as /a1, /a2, /a3, etc.
This can imply non-uniqueness across several fonts, so is likely to be
unsuitable if you need to provide CMAP resources for several fonts
using the same character names.

The alternative is to construct the full CMAP resource externally,
as a text file. Then the contents of this file is loaded into the PDF
using pdfTeX’s  \pdffontattr  primitive, which reads in the file as a stream,
and creates the correct dictionary entry.

For details on how this can be done in TeX coding, consult the package
   cmap.sty  .
Look at files such as  ot1.cmap, t1.cmap, t2.cmap etc. for the structure
of the kind of data file that is needed. These encode the unicode
mapping of the numbered character slots in a font.

Also it may be helpful to examine the coding that I’ve included below,
for attaching a CMAP resource to Xy-pic directional fonts,
e.g., for arrow-heads.
This assumes that LaTeX can find a private file called:  xyd.cmap .
Another primitive  \pdfnobuiltintounicode  disables the attempt to create
the CMAP internally.


Yes, I agree that this is likely the case.  I do know that in PK
fonts, there is only a character (or no character) for each of the
positions 0-255, with no character names or additional coding
information.

When specifying Type 1 PFB font, it needed to add it into pdftex font
map file (primitive \pdfmapfile). And map line allows to specify
encoding vector file. That file contains for each character 0-255
position glyph name. And pdftex primitive \pdfglyphtounicode then maps
glyph name to unicode character. So For PFB fonts it is possible to do
that 0-255 position to unicode mapping.

As outlined above.

But it is pity that it is not possible to specify that enc file also for
PK fonts generated by MetaFont. Or it is somehow possible?

I see no reason why not, but could easily be wrong.
But I must admit that I’ve not tried it with a PK font.

Font outlines have been the preferred technology for ~20 years
or more, so I’ve not had the need with bit-mapped fonts.


In detail my question is: How to tell pdftex encoding of PK font
(generated from MetaFont)?

For information on virtual fonts:  use Google.

With above detailed description, are you sure that virtual fonts
could do this unicode mapping?

Are not virtual fonts again only 8bit (as opposite of glyph names
and unicode)?

Yes, virtual fonts are only 8 bits.  There are things called "omega
virtual fonts" which I think allow for larger-numbered characters,
but I don't know whether pdftex supports them.  I think that luatex
does.

Luatex is unicoded and it is possible to create virtual font which remap
latin2 to unicode (yesterday I tried that). But my question is about
pdftex right now.

Try what I suggest above.



% Supply CMAP files for Xy-pic's arrowhead fonts
% otherwise an Accessibility check fails for encoding of arrow tips.
%
\def\TPDF@xyd@encoding{xyd}
\def\TPDF@support@xyarrows{%
  \IfFileExists{\TPDF@[email protected]<mailto:[email protected]>}%
   {\TPDF@load@xyd}%
   {\TPDF@inhibitload@xyd}%
}

\def\TPDF@load@xyd{%
    \immediate\pdfobj stream file {\TPDF@[email protected]<mailto:[email protected]>}\relax
    \xdef\TPDF@set@cmap@xyd##1{%
      \noexpand\expandafter\pdffontattr\noexpand##1 {/ToUnicode \the\pdflastobj\space 0 R}}%
  }
\def\TPDF@inhibitload@xyd{\gdef\TPDF@set@cmap@xyd##1{}}

% standard Xy tips
\def\TPDF@xyd@cmap@xy{%
 \pdfnobuiltintounicode\xyatipfont
 \TPDF@set@cmap@xyd{\xyatipfont}%
 \pdfnobuiltintounicode\xybtipfont
 \TPDF@set@cmap@xyd{\xybtipfont}%
}
% CM-style Xy tips
\def\TPDF@xyd@cmap@cm{%
 \pdfnobuiltintounicode\xy@@atfont
 \TPDF@set@cmap@xyd{\xy@@atfont}%
 \pdfnobuiltintounicode\xy@@btfont
 \TPDF@set@cmap@xyd{\xy@@btfont}%
}
% rebind the \UseTips  macro
\def\TPDF@UseTips{%
 \LTX@UseTips
 \TPDF@xyd@cmap@cm
}

\AtBeginDocument{%
 \@ifpackageloaded{xy}{% activate CMaps for Xy-pic arrows
  \TPDF@support@xyarrows
  \TPDF@xyd@cmap@xy
  \let\LTX@UseTips\UseTips
  \let\UseTips\TPDF@UseTips
 }{}%
 }



--
Pali Rohár
[email protected]<mailto:[email protected]>


Hope this helps,

Ross


Dr Ross Moore

Mathematics Dept | Level 2, S2.638 AHH
Macquarie University, NSW 2109, Australia

T: +61 2 9850 8955  |  F: +61 2 9850 8114<tel:%2B61%202%209850%209695>
M:+61 407 288 255<tel:%2B61%20409%20125%20670>  |  E: [email protected]<mailto:[email protected]>

http://www.maths.mq.edu.au<http://mq.edu.au/>

[cid:[email protected]]<http://mq.edu.au/>

CRICOS Provider Number 00002J. Think before you print.
Please consider the environment before printing this email.<http://mq.edu.au/>

This message is intended for the addressee named and may
contain confidential information. If you are not the intended
recipient, please delete it and notify the sender. Views expressed
in this message are those of the individual sender, and are not
necessarily the views of Macquarie University.<http://mq.edu.au/>