Re: [NTG-context] font pathes with colons
On 6/13/2018 1:55 PM, Ulrike Fischer wrote: 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.) 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 - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] font pathes with colons
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/ ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] font pathes with colons
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/
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] font pathes with colons
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
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] font pathes with colons
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/
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] font pathes with colons
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
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] font pathes with colons
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/
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] font pathes with colons
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//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
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
[NTG-context] font pathes with colons
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//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/
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
