TTC index parsing is fragile

[wspr]

I don't have much to test this with, but on my Mac I'm seeing the following behaviour:

\ifdefined\directlua
  \input luaotfload.sty
  \font\1="/System/Library/Fonts/Optima.ttc(3)"\1  bold
\else
  \font\1="[/System/Library/Fonts/Optima.ttc:2]"\1 italic
\fi
\bye

Is this a font bug, or is it expected behaviour?

Since I believe TTC indexing is a new feature in luaotfload, would it be possible to change it to be consistent with XeTeX? Otherwise I either have to document awkwardly in the fontspec documentation, or make the correction internally in fontspec; neither is appealing to me :)

[wspr]

Oh! I just noticed that in this case the problem is fixed:

  \font\1="file:/System/Library/Fonts/Optima.ttc(2)"\1  italic

In that case, I'm guessing never mind? Perhaps still an edge case to correct.

[wspr]

Lastly (sorry!) — this is the problem I was actually trying to diagnose:

  \font\1="[/System/Library/Fonts/Optima.ttc(2)]"\1  italic

This just breaks with:

luaotfload | main : initialization completed in 0.199 seconds)...xmf-dist/tex/luatex/luaotf
load/fontloader-basics-gen.lua:112: bad argument #2 to 'find_file' (invalid opt
ion 'ttc(2)').

Again, is this intentional or a bug in the parsing code?

[phi-gamma]

Can you try the 2.8 release? Subfont handling changed so this might
solve your problem. If not, may I ask you to check whether you can
reproduce it with a freely distributable font? That’d help a lot. Thanks.

[wspr]

Sorry for the slow reply. This issue has come up again for me because I was advised recently to avoid the file: syntax in favour of [...]. Here's a plain version of the error I'm receiving with a font that's in TeX Live:

\ifx\directlua\undefined
  \font\1="[ASANA.TTC]"\1\fontname\font\par
  \font\2="[ASANA.TTC:0]"\2\fontname\font\par
  \font\3="[ASANA.TTC:1]"\3\fontname\font\par
\else
  \input luaotfload.sty
  \font\1="[ASANA.TTC]"\1\fontname\font\par
  \font\2="[ASANA.TTC(0)]"\2\fontname\font\par
  \font\3="[ASANA.TTC(1)]"\3\fontname\font\par
\fi
\bye

[phi-gamma]

2017-02-10 (Friday), notifications@github.com (Will Robertson):

Sorry for the slow reply. This issue has come up again for me because I was advised recently to avoid the `file:` syntax in favour of `[...]`. Here's a plain version of the error I'm receiving with a font that's in TeX Live: ``` \ifx\directlua\undefined \font\1="[ASANA.TTC]"\1\fontname\font\par \font\2="[ASANA.TTC:0]"\2\fontname\font\par \font\3="[ASANA.TTC:1]"\3\fontname\font\par

Is that how you define a subfont in Xetex?

\else \input luaotfload.sty \font\1="[ASANA.TTC]"\1\fontname\font\par \font\2="[ASANA.TTC(0)]"\2\fontname\font\par \font\3="[ASANA.TTC(1)]"\3\fontname\font\par

Luaotfload uses the bracket syntax to allow filenames and paths as-is so the parentheses are treated as part of the filename / path. I’ll extend the parser to accept this instead:

\font\3="[ASANA.TTC](1)"\3\fontname\font\par

and with extra arguments

\font\3="[ASANA.TTC](1):mode=node;+tlig"\3\fontname\font\par

for this weekend’s fix release. Thanks for the report, Philipp

[wspr]

Thanks Philipp — yep, that's the XeTeX syntax. Sorry that wasn't clear. The changes you propose look fine to me; whatever works best for you and your parser :-)

[adamliter]

Hello, I was wondering if there's a systematic way to identify which index selects what, and it looks like luaotfload-tool might use a 1-based index, whereas fontspec uses a 0-based index. For example, on my Mac, where the Gill Sans font is packed into a collection (/Library/Fonts/GillSans.ttc), luaotfload-tool --find='Gill Sans Semibold' -i returns:

...
           subfamily: SemiBold
        subfontindex: 5
...

But to actually select the semibold version via fontspec, I have to use an index of 4, not 5:

\newfontfamily\SemiBold[Ligatures=TeX,Extension=.ttc,UprightFeatures={FontIndex=4}]{GillSans}

Is this correct in the general case, or is there something that makes this an accident in the Gill Sans case? If it is systematically correct, is there any possibility of one tool changing to the other index so that it's consistent? Or, at the very least, could this offset information be added to the fontspec documentation, @wspr? Or is there a better way, other than using luaotfload-tool, to see which font index selects what? (I didn't have much luck with ttfdump, but I ultimately don't know much about font files ...)

Anyway, thanks to everyone for some great tools! 😸