Closed eclecticfluff closed 2 months ago
I can't duplicate this. Can you give more details about your setup and share your pdf and the log file from your tex run? And are you using the junicodevf.sty and junicodevf.lua from CTAN or the one in the Junicode 2.208 release? I'm still using TeXLive 2023 with fontspec 2.8a: I'll have to upgrade so I can test further.
Texlive 2024 and I have the same issue. Junicode 2.208 JunicodeVF 2.206 (sic) Fontspec 2.9e
I'm installing TeXLive 2024 now. Will report back.
I've been able to duplicate the issue now. I can say definitely that the junicodevf scripts are not writing that junk into the file—not directly, anyway. Instead, the script or the font or both are somehow triggering this behavior in fontspec. Beyond that, it's a compete mystery. I'll check the fontspec issues and open one if there's no relevant issue there.
Okay, I get it now. Hunt down the file junicodevf.sty and change "Junicode VF" in the \setmainfont
command to "JunicodeVF." That's all there is to it.
If you're not comfortable digging into your TeXLive installation to edit a file, grab junicodevf.sty
and junicodevf.lua
from Junicode's GitHub repo and put them in the directory with the document you're working on. LuaLaTeX will use those instead of the TeXLive copy.
When I'm ready for the next release I'll ask Junicode's CTAN maintainer to update the VF package.
This fix is now in release 2.209. As I mentioned, I'm going to ask the Junicode maintainer for CTAN to update the variable package.
Aaaaaand . . . the new version with the fix is now in CTAN, thanks to Fontissimus Maximus Bob Tennent.
I just switched to using the
junicodevf
package rather than loading the fonts myself withfontspec
and stumbled upon the following bug.I haven't tested extensively, but to my knowledge this does not occur with the regular
junicode
package or in thearticle
document class, but does still happen withjunicodevf
inscrbook
.For further context, I am on
junicodevf
version 2.208 andfontspec
2.9e.