[lltx] luaotfload-database.lua

[Philipp Gesang]

Hi Reinhard!

···<Datum: Monday, 27. May 2013>···<Von: Reinhard Kotucha>···

> On 2013-05-26 at 11:10:08 +0200, Philipp Gesang wrote:
> 
>  > You could also replace the file resolver.
>  > 
>  >     fonts.definers.resolvers.file = function (spec)
>  >       --- rewrite spec.name here
>  >     end
> 
> Hi Philipp,
> spec.name contains the name without a path, so I suppose that the path
> is added somewhere else later.

The resolver replaces the file name along with other fields of
the spec. If it doesn’t resolve to a full path, then check_otf()
(see font-otf.lua) will do it at a later stage; if it can locate
the font, anyways. Sorry for the mislead.

Replacing the resolver is a bit crude in my eyes, so I added a
gimmick: the “my” lookup that lets you call your own resolver in
a “luaotfload.resolve_font” callback. Here’s a demo:

    https://bitbucket.org/phg/lua-la-tex-tests/src/9e3a0f/pln-lookup-callback-1.tex

It can’t solve your problem, though.

> Using the patch_font callback works fine.

That would depend on how the font is \dump’ed. Having never
looked at that code I can’t predict what might happen (Élie
might). But since the path information is lost it is possible
that this will fail with non-texmf fonts.

>  > > If somebody installs TL from tug.org, I suppose that he wants to
>  > > use the versions provided by TeX Live.  Or even newer versions in
>  > > own TEXMF trees.
>  > 
>  > Or those in ~/.fonts, which is *the* canonical directory to
>  > install your preferred fonts in.
>  
> I maintain a TeX Live system on a server, so the only way to make
> fonts accessible to all machines is to put them into a TEXMF tree.

>  > Since you are loading fonts by their filename and don’t care for
>  > system fonts, you probably have no need for a names database. We
>  > could make it optional, I guess, by installing a kpse-only file:
>  > resolver and omitting the others. This could be toggled by
>  > setting a flag in config.luaotfload.
> 
> Yes, making it configurable is certainly a good idea.

There is now a dedicated kpse: lookup that bypasses the database
entirely. Example:

    \input luaotfload.sty
    \font\foo = "kpse:Iwona-Regular.otf:+onum"
    \font\bar = "kpse:Iwona-Regular.otf:+smcp"

    {\foo baz {\bar whatever} xyzzy}\par
    \bye

>  > The texmf vs. system fonts matter could be made configurable as
>  > well, allowing the user to prioritize as they see fit. This would
>  > require either a dotfile or separate tables in the database for
>  > each of the search paths. Either way, it’s a more complex
>  > addition so it’ll probably require testing.
>  > 
>  > For a start, you can test with this branch:
>  > 
>  >     https://github.com/phi-gamma/luaotfload/commits/texmf-fonts
>  > 
>  > it restores the previous behavior of not indexing full paths for
>  > texmf fonts and also prefers them over system fonts.
> 
> It prefers texmf fonts but they are still specified with a full path.
> The latter has always been the case in the TL-2012 version.

This is caused by the fontloader and thus outside of our sphere
of influence.

Furthermore, luaotfload-tool now has an option --prefer-texmf
that prioritizes fonts in the tex tree. To achieve that, the
filename data needs to be reorganized a bit, so I incremented the
database version. Don’t forget to erase the font cache. For this
to work during a tex run you have to set the “prioritize” field
before loading luaotfload:

    \directlua{
      config                       = config or { }
      config.luaotfload            = config.luaotfload or { }
      config.luaotfload.prioritize = "texmf"
    }
    \input luaotfload.sty

All these additions are still experimental and require testing.

Best regards
Philipp




> 
> Regards,
>   Reinhard
> 
> -- 
> ----------------------------------------------------------------------------
> Reinhard Kotucha                                      Phone: +49-511-3373112
> Marschnerstr. 25
> D-30167 Hannover                              mailto:reinhard.kotucha at web.de
> ----------------------------------------------------------------------------
> Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
> ----------------------------------------------------------------------------
> 

-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://tug.org/pipermail/lualatex-dev/attachments/20130527/756998ac/attachment.bin>