reencode fonts with fonts.trigger
Hello, Khaled had another idea to manipulate (reencode) fonts: He suggested to put a function in fonts.trigger. (Example below). I have some questions regarding this example: 1. Is there a basic flaw in the idea? 2. Is the interface more or less stable or will it probably change in the future? If not 3. which tables/values in tfmdata must be copied/reassigned beside the indices information? (There seem to be quite a lot informations more than once in tfmdata. E.g. I find the boundingbox in two places (descriptions and shared.otfdata.glyphs)). 4. Which tables/values must be created if I try to move a char to a place which is currently empty (like the "z" in the example)? 5. What is the recommanded lua-code to copy/reassign/remap the tables? Does a library or some helper functions exist which would make it easier to move the tables around? \directlua{ local function chess(tfmdata,value) if value then tfmdata.characters[122]={} tfmdata.indices[75],tfmdata.indices[81],tfmdata.indices[122]=tfmdata.indices[81],tfmdata.indices[75],tfmdata.indices[81] table.tofile("filechess.lua", tfmdata, true) %show table end end table.insert(fonts.triggers,"chess") fonts.initializers.base.otf.chess = chess fonts.initializers.node.otf.chess = chess } \font\test="file:SkakNew-Figurine.otf:chess=yes" \starttext \test KQzK \stoptext \bye -- Ulrike Fischer
On 22-2-2011 4:22, Ulrike Fischer wrote:
Hello,
Khaled had another idea to manipulate (reencode) fonts: He suggested to put a function in fonts.trigger. (Example below). I have some questions regarding this example:
1. Is there a basic flaw in the idea?
When triggers are done, there are only empty entries in the characters table so swapping them has no effect. You can add info to them but some entries in them will be added when scaling takes place.
2. Is the interface more or less stable or will it probably change in the future?
the triggers interface will stay
If not 3. which tables/values in tfmdata must be copied/reassigned beside the indices information? (There seem to be quite a lot informations more than once in tfmdata. E.g. I find the boundingbox in two places (descriptions and shared.otfdata.glyphs)).
they are the same (descriptions is the unicode ordering of glyphs but the subtables are shared, and best don't mess with those subtables as they can be shared as well) you probably don't have to change anything else as tex only works with the tfm data (in node mode otf data is used but chess is unlikely to be influenced by node mode)
4. Which tables/values must be created if I try to move a char to a place which is currently empty (like the "z" in the example)?
see above, for tex only the tfmdata counts so no other data has to be created (unless you have kerns in which case you need to adapt all character entries that kern with that glyph)
5. What is the recommanded lua-code to copy/reassign/remap the tables? Does a library or some helper functions exist which would make it easier to move the tables around?
For basemode reencoding you can use the changed subtable: \starttext \directlua{ local function chess(tfmdata,value) if value then tfmdata.changed[75] = 81 tfmdata.changed[81] = 75 end end table.insert(fonts.triggers,"chess") fonts.initializers.base.otf.chess = chess } \start \font\TestA="file:SkakNew-Figurine.otf:chess=yes" \TestA\char75 \char81 \par \font\TestB="file:SkakNew-Figurine.otf:chess=no" \TestB\char75 \char81 \par \stop \stoptext ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Am Tue, 22 Feb 2011 18:05:58 +0100 schrieb Hans Hagen:
Khaled had another idea to manipulate (reencode) fonts: He suggested to put a function in fonts.trigger. (Example below). I have some questions regarding this example:
1. Is there a basic flaw in the idea?
When triggers are done, there are only empty entries in the characters table so swapping them has no effect. You can add info to them but some entries in them will be added when scaling takes place.
For which entries can this be a problem?
5. What is the recommanded lua-code to copy/reassign/remap the tables? Does a library or some helper functions exist which would make it easier to move the tables around?
For basemode reencoding you can use the changed subtable:
\starttext
\directlua{ local function chess(tfmdata,value) if value then tfmdata.changed[75] = 81 tfmdata.changed[81] = 75 end end table.insert(fonts.triggers,"chess") fonts.initializers.base.otf.chess = chess }
\start \font\TestA="file:SkakNew-Figurine.otf:chess=yes" \TestA\char75 \char81 \par \font\TestB="file:SkakNew-Figurine.otf:chess=no" \TestB\char75 \char81 \par \stop
\stoptext
That works fine - even with luaotfload and latex (after I understood that "basemode" means that I must call the font with "mode=base"). But curiously the dimens of the char change a bit in latex. E.g. \showthe\fontcharwd reports without the reencoding 8.99998pt, and 9.0pt with the reencoding. In context I get in both cases 9.0pt. Is it possible to swap (or set) the "tounicode" value at his time so that copy&paste gives again a "K" for the king and a "Q" for the queen? -- Ulrike Fischer
On 22-2-2011 4:22, Ulrike Fischer wrote:
Hello,
Khaled had another idea to manipulate (reencode) fonts: He suggested to put a function in fonts.trigger. (Example below). I have some questions regarding this example:
I'll add the following to the luatex-fonts code. It demonstrates how to use postprocessing hooks. (It should work with the current code, unless you define multiple mapping of the same font, for which i've added a patch). \startluacode local reencodings = { } fonts.enc.reencodings = reencodings local function specialreencode(tfmdata,value) -- we forget about kerns as we assume symbols and we -- could issue a message if ther are kerns but it's -- a hack anyway so we odn't care too much here local encoding = value and reencodings[value] if encoding then local temp = { } local char = tfmdata.characters for k, v in next, encoding do temp[k] = char[v] end for k, v in next, temp do char[k] = temp[k] end -- if we use the font otherwise luatex gets confused so -- we return an additional hash value for fullname return string.format("reencoded:%s",value) end end local function reencode(tfmdata,value) tfmdata.postprocessors = tfmdata.postprocessors or { } table.insert(tfmdata.postprocessors, function(tfmdata) return specialreencode(tfmdata,value) end ) end table.insert(fonts.manipulators,"reencode") fonts.initializers.base.otf.reencode = reencode \stopluacode \startluacode fonts.enc.reencodings["mychess"] = { [75] = 81, [81] = 75, } \stopluacode \starttext {\font\test=file:SkakNew-Figurine.otf at 50pt \test QK \par} {\font\test=file:SkakNew-Figurine.otf:reencode=mychess at 50pt \test QK \par} \stoptext ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Am Tue, 22 Feb 2011 20:29:48 +0100 schrieb Hans Hagen:
I'll add the following to the luatex-fonts code. It demonstrates how to use postprocessing hooks. (It should work with the current code, unless you define multiple mapping of the same font, for which i've added a patch).
The code didn't work with the context in miktex and a context from a minimals about 3 month old (I got no errors but no reencoding either). It worked fine with a current context. In latex/luaotfload I got at first an error ("enc" is nil). After I added "if not fonts.enc then fonts.enc = { } end" it compiled but didn't reencode. So I guess I will have to wait until luaotfload gets updated before I can use this solution (which looks fine). But I wished they were some documentation about the general structure of the font loading and processing and all this fields (fonts.manipulators, fonts.triggers, tfmdata.postprocessors, ...). Is there someone (beside yourself) who still understand the overall picture? -- Ulrike Fischer
On 23-2-2011 6:05, Ulrike Fischer wrote:
But I wished they were some documentation about the general structure of the font loading and processing and all this fields (fonts.manipulators, fonts.triggers, tfmdata.postprocessors, ...).
There will be some documentation once it is stable enough. I also need to split off some code that is context specific in order to avoid confusion. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (2)
-
Hans Hagen -
Ulrike Fischer