[luatex] luatex - font encoding for type 1 fonts

[Pali Rohár]

On Sunday 26 June 2016 12:37:35 Hans Hagen wrote:
> On 6/25/2016 11:32 PM, Pali Rohár wrote:
> > On Saturday 25 June 2016 14:47:43 Hans Hagen wrote:
> >> Anyway, in the next context distribution upload (context also
> >> ships with a plain variant) I have added a loader script. If you
> >> use luaotfload you probably have to wait for an update at their
> >> end. The luatex-plain format that ships with context can do this
> >> then:
> >> 
> >> \font\foo=file:luatex-plain-tfm.lua:tfm=csr10;enc=csr;pfb=csr10 at
> >> 12pt
> >> 
> >> \foo áäčďěíĺľňóôŕřšťúýž fiets ff ffi
> >> 
> >> \bye
> > 
> > Great, that looks really good!
> > 
> > What I still do not understand is why it is needed to specify
> > enc=csr. Encoding vector is present in PFB file.
> 
> because the order in a pfb can be different and there can be more
> than 256 glyphs in a pfb ... the glyphname is what links them
> 
> index in tfm -> name -> index in pfb

Yes, this is how it works.

But I'm trying to point something else, that csr.enc file does not have 
to be specified.

File csr.enc contains:

  /il2Encoding [
  /Gamma /Delta /Theta /Lambda /Xi /Pi /Sigma /Upsilon
  ...
  /quotedblbase /csquotedblright
  ] def

File csr10.pfb contains:

  /FontName /csr10 def
  /Encoding 256 array
  0 1 255 {1 index exch /.notdef put} for
  dup 0 /Gamma put
  dup 1 /Delta put
  dup 2 /Theta put
  dup 3 /Lambda put
  dup 4 /Xi put
  dup 5 /Pi put
  dup 6 /Sigma put
  dup 7 /Upsilon put
  ...
  dup 254 /quotedblbase put
  dup 255 /csquotedblright put
  readonly def
  ...
  2 index /CharStrings 183 dict dup begin
  /Xi {
  ...
  }
  /dotlessi {
  ...
  }
  /oslash {
  ...
  }
  ...

So glyphs are really in random order in csr10.pfb file (first is /Xi, 
second /dotlessi, ...) but at beginning of csr10.pfb file is /Encoding 
table where is that mapping from index to glyph name. Same what is in 
csr.enc file.

And I'm trying to tell you that in this case (when /Encoding array in 
pfb file is available), external *.enc is not needed to specify. Looks 
like that pdftex uses this /Encoding array.

Do you know now, what I means?

> > Also, I have another question, is there ability to load PK font
> > file (generated from MetaFont)? Specifying metric file (tfm) and
> > encoding vector (enc) should work similarly (or maybe same?) as
> > for Type 1 PFB font.
> 
> sure, i can do that (omitting the pfb entry will then revert to
> bitmaps plus a bit of safeguarding against inconsistent names and
> so) but keep in mind that a mixture in one document will then always
> use the outline (as the map entry wins)

When I'm preparing document for printer (at resolution 600dpi), I think 
it does not matter if font is Type 1 or bitmap PK (generated by MetaFont 
for 600dpi). There are no problems with bitmap fonts as it is not needed 
scale it.

I think it could be useful if that your loader was able to understand 
command also when pfb file is not specified. It could try to load either 
pfb file (preferred) or fallback to PK/metafont.

For example, in CSFonts are fonts csb10 and csb12. Both are written in 
MetaFont (one for 10pt, second prepared for 12pt), but only first one 
has Type 1 variant. Second only MetaFont. So when I need to specify font 
in TeX (with your loader), it would be easier to use same "font command" 
syntax to load font as need to distinguish if there is available Type 1 
variant or not. For pdftex I do not need to tell if I want Type 1 or PK, 
it has (internal/system pdftex.map) database of Type 1 fonts and 
automatically choose Type 1 if is available. If not but PK is available, 
then it is used. And even PK font file is not available, it starts 
MetaPost and generate metric file TFM and PK font. 

> >> (It uses a few helpers from the existing font code, like cached
> >> loading and glyph names to unicode mapping using the enc file
> >> which saves resources and is also more generic than hard coded
> >> font vectors. It's still a pitty that these csr fonts don't come
> >> as a full package like plr which has afm files too; in which case
> >> the regular afm/pfb loader could be used instead. I only tested
> >> csr10.tfm / csr10.pfb / css.enc as I don't want to install the
> >> whole lot.
> > 
> > If one is working, others must too.
> > 
> > Where I can find your changes, so I could test it? Ideally if I
> > could download tex/lua files into working directory and use system
> > luatex instead building whole texlive and luatex from some
> > sources...
> 
> you have to wait till i update context and then fetch it from the
> context garden (i'll update later today)

Ok, let me know when you publish it (and where) and I would be happy to 
test your changes!

-- 
Pali Rohár
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://tug.org/pipermail/luatex/attachments/20160626/bb116c95/attachment-0001.bin>