I have been playing around with lua fonts and investigating where to store and how to load them. The best with luaotfload and latex seems to be currently to get (with a kpse call) the absolute path and then load with the "xetex" syntax: \font\duckchessfont = [\directlua{tex.sprint(kpse.find_file("luafont-duckchess.lua", "misc fonts"))}]:mode=node;+liga;+tlig;original=latinmodernsans This worked but I also saw in the log curious messages luaotfload | load : font option "/Users/XXXX/Documents/Git/lua-font- pond/texmf/fonts/misc/luafont/luafont-duckchess.lua]:mode=node" unknown. I investigated a bit. I'm on windows and imho this looks as if the syntax parser is splitting after the C: of the drive and putting the rest in the specification.detail field. As far as I can see the code which does the splitting is in font-def.lua and so part of the generic code. Is there anything that can be done to correct his? Or can one somehow protect the colon after c: to be interpretated as file-detail separator? -- Ulrike Fischer http://www.troubleshooting-tex.de/
On 6/8/2018 11:51 PM, Ulrike Fischer wrote:
I have been playing around with lua fonts and investigating where to store and how to load them.
The best with luaotfload and latex seems to be currently to get (with a kpse call) the absolute path and then load with the "xetex" syntax:
\font\duckchessfont = [\directlua{tex.sprint(kpse.find_file("luafont-duckchess.lua", "misc fonts"))}]:mode=node;+liga;+tlig;original=latinmodernsans
This worked but I also saw in the log curious messages
luaotfload | load : font option "/Users/XXXX/Documents/Git/lua-font- pond/texmf/fonts/misc/luafont/luafont-duckchess.lua]:mode=node" unknown.
I investigated a bit. I'm on windows and imho this looks as if the syntax parser is splitting after the C: of the drive and putting the rest in the specification.detail field.
As far as I can see the code which does the splitting is in font-def.lua and so part of the generic code. Is there anything that can be done to correct his? Or can one somehow protect the colon after c: to be interpretated as file-detail separator? i can support {weird name} but need to check first if it will not interfere with context (or luatex-plain)
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 -----------------------------------------------------------------
Am Sat, 9 Jun 2018 11:52:43 +0200 schrieb Hans Hagen:
As far as I can see the code which does the splitting is in font-def.lua and so part of the generic code. Is there anything that can be done to correct his? Or can one somehow protect the colon after c: to be interpretated as file-detail separator?
i can support {weird name} but need to check first if it will not interfere with context (or luatex-plain)
Thanks. But if protection is possible, why doesn't [...] already does it? I thought that in the brackets is always only a path anyway. -- Ulrike Fischer http://www.troubleshooting-tex.de/
On 6/9/2018 11:34 PM, Ulrike Fischer wrote:
Am Sat, 9 Jun 2018 11:52:43 +0200 schrieb Hans Hagen:
As far as I can see the code which does the splitting is in font-def.lua and so part of the generic code. Is there anything that can be done to correct his? Or can one somehow protect the colon after c: to be interpretated as file-detail separator?
i can support {weird name} but need to check first if it will not interfere with context (or luatex-plain)
Thanks. But if protection is possible, why doesn't [...] already does it? I thought that in the brackets is always only a path anyway. because we share soem code with context and i don't want to support this [] syntax there (conflicts too much)
i'll see if i can make a dedicated variant (after all latex doesn't need some of the trickery present) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Am Sun, 10 Jun 2018 12:42:25 +0200 schrieb Hans Hagen:
Thanks. But if protection is possible, why doesn't [...] already does it? I thought that in the brackets is always only a path anyway. because we share soem code with context and i don't want to support this [] syntax there (conflicts too much)
Ah ok. I'm not really bound to a specific syntax as long as luaotfload at the end gets the correct data. The problem is that luaotfload is not really maintained currently, so it is difficult to improve its handling of lua-fonts. The current setup has some problems with them: I tried at first the {file:luafont.lua} syntax, but luaotfload doesn't look in fonts/misc in this case (which imho is a more logical place then tex/luatex), and also it constantly triggered the rebuilding of the database. Absolute pathes found with kpathsea looked like the way out -- apart from the problem with the colon. -- Ulrike Fischer http://www.troubleshooting-tex.de/
On 6/10/2018 12:58 PM, Ulrike Fischer wrote:
Am Sun, 10 Jun 2018 12:42:25 +0200 schrieb Hans Hagen:
Thanks. But if protection is possible, why doesn't [...] already does it? I thought that in the brackets is always only a path anyway. because we share soem code with context and i don't want to support this [] syntax there (conflicts too much)
Ah ok. I'm not really bound to a specific syntax as long as luaotfload at the end gets the correct data.
The problem is that luaotfload is not really maintained currently, so it is difficult to improve its handling of lua-fonts. The current setup has some problems with them:
I tried at first the {file:luafont.lua} syntax, but luaotfload doesn't look in fonts/misc in this case (which imho is a more logical place then tex/luatex), and also it constantly triggered the rebuilding of the database. Absolute pathes found with kpathsea looked like the way out -- apart from the problem with the colon. i changed the parser for generic a bit so you need to check careful next beta as i'm only testing some basic plain loading
i have no clue how otfload locates files but maybe you need to add an entry to local remapper = { otf = "opentype fonts", ttf = "truetype fonts", ttc = "truetype fonts", cid = "cid maps", cidmap = "cid maps", -- fea = "font feature files", -- no longer supported pfb = "type1 fonts", -- needed for vector loading afm = "afm", enc = "enc files", lua = "tex", -- LIKE THIS } 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 -----------------------------------------------------------------
Am Sun, 10 Jun 2018 13:24:40 +0200 schrieb Hans Hagen:
i changed the parser for generic a bit so you need to check careful next beta as i'm only testing some basic plain loading
It broke ;-( luaotfload complained about a missing registersplit, then about a missing addspecifier, so I reinserted from the previous version (from UF to /UF) (around line 32865) local resolvefile=fontgoodies and fontgoodies.filenames and fontgoodies.filenames.resolve or function(s) return s end -- UF local splitter,splitspecifiers=nil,"" local P,C,S,Cc,Cs=lpeg.P,lpeg.C,lpeg.S,lpeg.Cc,lpeg.Cs local left=P("(") local right=P(")") local colon=P(":") local space=P(" ") local lbrace=P("{") local rbrace=P("}") definers.defaultlookup="file" local prefixpattern=P(false) local function addspecifier(symbol) splitspecifiers=splitspecifiers..symbol local method=S(splitspecifiers) local lookup=C(prefixpattern)*colon local sub=left*C(P(1-left-right-method)^1)*right local specification=C(method)*C(P(1)^1) local name=Cs((lbrace/"")*(1-rbrace)^1*(rbrace/"")+(1-sub-specification)^1) splitter=P((lookup+Cc(""))*name*(sub+Cc(""))*(specification+Cc(""))) end local function addlookup(str,default) prefixpattern=prefixpattern+P(str) end definers.addlookup=addlookup addlookup("file") addlookup("name") addlookup("spec") local function getspecification(str) return lpegmatch(splitter,str or "") end definers.getspecification=getspecification function definers.registersplit(symbol,action,verbosename) addspecifier(symbol) variants[symbol]=action if verbosename then variants[verbosename]=action end end -- /UF Then it complained about a missing upvalue getthreshold so I reinserted: local getthreshold --UF injections.threshold=0 getthreshold=function(font) local p=fontdata[font].parameters local f=p.factor local s=p.spacing local t=injections.threshold*(s and s.width or p.space or 0)-2 return t>0 and t or 0,f end --/UF Now it works again and also the "unknown option" warning is gone.
i have no clue how otfload locates files but maybe you need to add an entry to
local remapper = { otf = "opentype fonts", ttf = "truetype fonts", ttc = "truetype fonts", cid = "cid maps", cidmap = "cid maps", -- fea = "font feature files", -- no longer supported pfb = "type1 fonts", -- needed for vector loading afm = "afm", enc = "enc files", lua = "tex", -- LIKE THIS }
lua = "misc fonts", would be better (then one can put the fonts in fonts/misc. But it doesn't help with the main problem that luaotfload calls resolvers.findfile first for "basename + otf, tfm, ofm", then triggers a rebuild of the database and only then calls resolvers.findfile again with the fullname. Also I really want to avoid to patch the merged code. I'm regularly getting the newest version from context and try out if it still works and prefer if I can use them unchanged. -- Ulrike Fischer http://www.troubleshooting-tex.de/
Am Sun, 10 Jun 2018 13:24:40 +0200 schrieb Hans Hagen:
i changed the parser for generic a bit so you need to check careful next beta as i'm only testing some basic plain loading
I found something else that changed: The otf-handler registerpalette is gone, and so coloring of fonts like in the following answer no longer works: https://tex.stackexchange.com/a/387069/2388 (I don't have the time now to test it in the plain-tex version.) -- Ulrike Fischer http://www.troubleshooting-tex.de/
Am Sun, 10 Jun 2018 13:24:40 +0200 schrieb Hans Hagen:
i changed the parser for generic a bit so you need to check careful next beta as i'm only testing some basic plain loading
I found something else that changed:
The otf-handler registerpalette is gone, and so coloring of fonts like in the following answer no longer works:
https://tex.stackexchange.com/a/387069/2388
(I don't have the time now to test it in the plain-tex version.)
On 6/13/2018 1:55 PM, Ulrike Fischer wrote: probably the same ... i strip context specific sections in generic but need to keep the else branch then ... i'll fix it (but no upload today) 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 -----------------------------------------------------------------
participants (2)
-
Hans Hagen -
Ulrike Fischer