Odd font embedding

[zauguin]

There seems to be a regression in the font embedding. Wide (encodingbytes=2) Type 1 fonts are embedded correctly by LuaTeX, while HarfTeX does something odd with them. (They seem to be inserted as CID fonts, but still embedded as Type 1 instead of CFF fonts) At least for PDF 1.7 (I don't know about PDF 2.0, but I would be very surprised if this was added) this is not allowed by the PDF specification and except by Acrobat also not supported by viewers.

[khaledhosny]

Right, probably the "experimental" code that I activated in commit https://github.com/khaledhosny/harftex/commit/be04d116049acd66f74b496e9e385b4172ffc326 is broken. I didn't actually know how to test that code path (not knowing what "wide" Type 1 fonts actually is.

Since the old FontForge-based code was dropped in commit https://github.com/khaledhosny/harftex/commit/c4cb8d5acc916c2f19978db23917dc18db5dfffb, I'll need to fix this code then. Do you have a sample to reproduce, and how relevant such use of Type 1 fonts?

I think you can use pdf.settypeonewidemode = 1 in LuaTeX to activate the same code path, in case you wanted to report the issue to LuaTeX developers as well.

[zauguin]

A minimal example (just set encodingbytes=2 in a Type 1 font):

\directlua{
  local f = {
    name = "cmr",
    format = "type1",
    filename = "cmr10.pfb",
    encodingbytes = 2,
    characters = {
      [0] = {
        width=1000, height=1000,depth=1000,index=1
      }
    }
  }
  font.current(font.define(f))
}
\char0
\bye

I'm currently not sure if this is used by the fontloader if you load a Type 1 font but I can look it up later. I think I always loaded them manually. Anyway they are quite useful if you still have Type 1 fonts (which you are often not allowed to convert to OpenType). The wide fonts not only allow to use more than 256 characters, they also make the input character to font character mapping more flexible without needing virtual fonts.

Anyway it probably is more of a corner case, so if you do not want to implement this directly I should have a Lua Type1 to CFF converter lying around somewhere. That would make it quite easy to emulate this functionality through Lua if required.

[u-fischer]

I guess that this is related to the failure in harftex of one of our testfiles which tried to print fontdata.encodingbyte to the log

texio.write_nl("patch_font" .. fontdata.name .. fontdata.encodingbytes)

(the field isn't used, that's only for testing some patch code).

[zauguin]

@u-fischer Which test is that? I think it's not caused by this (this shouldn't change how encodingbytes are reported to Lua, only how they are treated in the backend) but harf generally doesn't set encodingbytes, so that might cause the error.

[u-fischer]

@zauguin The test patch-safe-unsafe.lvt broke with harflatex with an lua error because of the undefined encodingbytes.

[khaledhosny]

I'm wondering how other tools, say dvipdfmx, handle embedding Type 1 fonts.