Hey, LuaTeX currently supports only a very special kind of Type 3 fonts: They are generated for traditional TeX bitmap fonts. While this used to be the most common use case for Type3 fonts, the fully general concept of these fonts has recently been reinvented under the name of SVG fonts (and friends). While they can be implemented in LuaTeX to some degree through virtual fonts/node processing etc., converting them into "real" Type 3 fonts in the PDF file would give some important advantages: Such fonts are called like other fonts and can get tounicode vectors, allowing better accessibillity and better Copy&Paste behaviour. Also viewers generally treat them as text instead of graphics, allowing proper interaction with features of PDF viewers. Beside from supporting SVG fonts, it also allows to use general MetaPost fonts which might not be easily convertable into normal formats for vector fonts. As far as I can tell there used to be an implementation of general Type 3 fonts for pdfTeX which was dropped in LuaTeX, mostly because it was never actually used. My suggested new implementation is a bit more flexible by not requiring external files defining the font but instead generating each font character based on individual node lists for every glyph. One way to make this work would be to add a special `format` named e.g. `node` (given that `type3` is already used to imply bitmap fonts) and add a field `node`/`list`/`head` to the character table referencing a node list which should become the font glyph. The detaily like bounding box calculations etc. would be the responsibility of the Lua code loading the font. The intended usage would be e.g. \directlua{ local l = token.scan_list() local wi = node.new('whatsit', 'pdf_literal') wi.mode = 3 wi.data = math.floor(l.width / tex.sp'1bp') .. ' 0 d0' wi.next = l.head l.head = wi font.current(font.define{ name = "exp-nodefont", format = "node", designsize = tex.sp("10pt"), size = tex.sp("10pt"), characters = { [42] = { width = l.width, height = l.height, depth = l.depth, node = node.direct.todirect(l), } } })}\hbox{ABC} \char42 \char42 \bye What do you think? (I'll attach a patch I used for experiments (mostly with MetaPost fonts) which implements this in a slightly hacky way.) -- Marcel
Marcel Fabian Krüger schrieb am 30.10.2019 um 18:02:
Hey,
LuaTeX currently supports only a very special kind of Type 3 fonts: They are generated for traditional TeX bitmap fonts. While this used to be the most common use case for Type3 fonts, the fully general concept of these fonts has recently been reinvented under the name of SVG fonts (and friends). While they can be implemented in LuaTeX to some degree through virtual fonts/node processing etc., converting them into "real" Type 3 fonts in the PDF file would give some important advantages: Such fonts are called like other fonts and can get tounicode vectors, allowing better accessibillity and better Copy&Paste behaviour. Also viewers generally treat them as text instead of graphics, allowing proper interaction with features of PDF viewers. Beside from supporting SVG fonts, it also allows to use general MetaPost fonts which might not be easily convertable into normal formats for vector fonts.
As far as I can tell there used to be an implementation of general Type 3 fonts for pdfTeX which was dropped in LuaTeX, mostly because it was never actually used. My suggested new implementation is a bit more flexible by not requiring external files defining the font but instead generating each font character based on individual node lists for every glyph. One way to make this work would be to add a special `format` named e.g. `node` (given that `type3` is already used to imply bitmap fonts) and add a field `node`/`list`/`head` to the character table referencing a node list which should become the font glyph. The detaily like bounding box calculations etc. would be the responsibility of the Lua code loading the font. Take a look at chapter 14: http://www.pragma-ade.nl/general/manuals/luametafun.pdf
Wolfgang
On 30 October 2019 19:00:05 CET, Wolfgang Schuster
Marcel Fabian Krüger schrieb am 30.10.2019 um 18:02:
Hey,
LuaTeX currently supports only a very special kind of Type 3 fonts: They are generated for traditional TeX bitmap fonts. While this used to be the most common use case for Type3 fonts, the fully general concept of these fonts has recently been reinvented under the name of SVG fonts (and friends). While they can be implemented in LuaTeX to some degree through virtual fonts/node processing etc., converting them into "real" Type 3 fonts in the PDF file would give some important advantages: Such fonts are called like other fonts and can get tounicode vectors, allowing better accessibillity and better Copy&Paste behaviour. Also viewers generally treat them as text instead of graphics, allowing proper interaction with features of PDF viewers. Beside from supporting SVG fonts, it also allows to use general MetaPost fonts which might not be easily convertable into normal formats for vector fonts.
As far as I can tell there used to be an implementation of general Type 3 fonts for pdfTeX which was dropped in LuaTeX, mostly because it was never actually used. My suggested new implementation is a bit more flexible by not requiring external files defining the font but instead generating each font character based on individual node lists for every glyph. One way to make this work would be to add a special `format` named e.g. `node` (given that `type3` is already used to imply bitmap fonts) and add a field `node`/`list`/`head` to the character table referencing a node list which should become the font glyph. The detaily like bounding box calculations etc. would be the responsibility of the Lua code loading the font. Take a look at chapter 14: http://www.pragma-ade.nl/general/manuals/luametafun.pdf
I am aware that this can easily be implemented in luametatex, but I think that this functionality is important enough that it also should be supported in LuaTeX. -- Marcel
Wolfgang
I am aware that this can easily be implemented in luametatex, but I think that this functionality is important enough that it also should be supported in LuaTeX. I did consider something for luatex but not for now (and if so it will basically be an extra callback, maybe something 'add your own font id to
On 10/30/2019 7:09 PM, Marcel Krüger wrote: the font dict could do). Actually, in the past pdftex had so called glyph containers that pushed pdf stuff into the type3 (some traces can still be seen in the code i think). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On Wed, Oct 30, 2019 at 6:02 PM Marcel Fabian Krüger
What do you think?
(I'll attach a patch I used for experiments (mostly with MetaPost fonts) which implements this in a slightly hacky way.)
Thank you for the patch. It's a feature request, it has less priority than bugs fixing (and other emails sent by you). In some way context already does something with svg, so the matter is at least partially covered, and type3 fonts are, well, hm hm for the viewers (and unusual type3 fonts can embarrassing RIP too). -- luigi
On Wed, Oct 30, 2019 at 08:32:45PM +0100, luigi scarso wrote:
Thank you for the patch. It's a feature request, it has less priority than bugs fixing (and other emails sent by you).
Right, I already guessed as much but I thought I just send it anyway in case you find it useful :) -- Marcel
Noticed two bugs. 1. Mised case for user defined whatsit node type 108 (‘l’ Lua value) in function check_node_wrapup_core (texnodes.c:2482). Possible fix: just add the same as cases for types ’s’ and ‘d’. Insert line at texnodes.c:2500 case ‘l': 2. In function flush_node_wrapup_core (texnodes.c:2201) for user defined whatsit node type ‘l’ we have: free_user_lua(user_node_value(p)). But in luanode.c:409 free_user_lua is defined as: void free_user_lua(pointer p) { if (user_node_value(p) != 0) { luaL_unref(Luas, LUA_REGISTRYINDEX, user_node_value(p)); } } So we have two times user_node_value and it generates segmentation fault. Possible fix: free_user_lua(p); // (texnodes.c:2223) Regards, Sigitas
On Fri, Nov 15, 2019 at 12:35 PM Sigitas Tolusis
Noticed two bugs.
1. Mised case for user defined whatsit node type 108 (‘l’ Lua value) in function check_node_wrapup_core (texnodes.c:2482). Possible fix: just add the same as cases for types ’s’ and ‘d’. Insert line at texnodes.c:2500 case ‘l':
2. In function flush_node_wrapup_core (texnodes.c:2201) for user defined whatsit node type ‘l’ we have: free_user_lua(user_node_value(p)). But in luanode.c:409 free_user_lua is defined as:
void free_user_lua(pointer p) { if (user_node_value(p) != 0) { luaL_unref(Luas, LUA_REGISTRYINDEX, user_node_value(p)); } }
So we have two times user_node_value and it generates segmentation fault. Possible fix: free_user_lua(p); // (texnodes.c:2223)
Regards, Sigitas
Thank you for the report, we will see it asap. -- luigi
participants (6)
-
Hans Hagen -
luigi scarso -
Marcel Fabian Krüger -
Marcel Krüger
-
Sigitas Tolusis -
Wolfgang Schuster