update tests

[mbertucci47]

Updates some test files. @cfr42 Is it correct that the adforn characters become blank spaces? If everything looks good I think those packages could be moved to compatible.

[cfr42]

Updates some test files. @cfr42 Is it correct that the adforn characters become blank spaces? If everything looks good I think those packages could be moved to compatible.

Yes, I think that is what I did in the end with flourishes. By analogy with mapping of decorative drawn elements as artifact. Space seemed closer than anything else permissible. Whether that is what they should be, I don't know. I think @davidcarlisle suggested this. (There were conflicting suggestions, I think, but it is a while since I looked at it, so I might be misremembering.)

And, yes, adforn, adfbullets and adfarrows should be OK with LuaTeX even from TL2025 as they use fixtounicode, which contains a workaround which works for some type1 fonts, including these. If LuaTeX >= 1.24, the workaround isn't needed, but the package still defines \pdfglyphtounicode and flips the Lua toggle on. (If the format makes this default, which I hope it does, I will make this depend on the LaTeX version, I guess.)

[cfr42]

It might be worth noting in the comments that direct use of the fonts is NOT compatible with accessibility. To get mappings to Unicode, relevant .stys MUST be loaded. So if you use the fonts with pifont, say, rather than using adforn or whatever, nothing will get mapped to Unicode because, unlike those for Zapf Dingbats, for example, these mappings are not in any central database. This is true regardless of engine.

[mbertucci47]

@cfr42 I changed them to compatible and made a comment about needing to be loaded via the package.

[cfr42]

@cfr42 I changed them to compatible and made a comment about needing to be loaded via the package.

Thanks very much. This was on my todo list ... ;).

[FrankMittelbach]

It might be worth noting in the comments that direct use of the fonts is NOT compatible with accessibility. To get mappings to Unicode, relevant .stys MUST be loaded. So if you use the fonts with pifont, say, rather than using adforn or whatever, nothing will get mapped to Unicode because, unlike those for Zapf Dingbats, for example, these mappings are not in any central database. This is true regardless of engine.

I think it would be ok to put specific glyphtounicode settings that are only relevant to a specific family (ie tfm:... ones) in the corresponding .fd files for such families. That way they could also be used with pifont etc.

Unless somebody comes up with a good argument why this isn't a sensible idea, I guess we are going to document that as a possibility in fntguide.

[cfr42]

@FrankMittelbach

I think it would be ok to put specific glyphtounicode settings that are only relevant to a specific family (ie tfm:... ones) in the corresponding .fd files for such families. That way they could also be used with pifont etc.

Unless somebody comes up with a good argument why this isn't a sensible idea, I guess we are going to document that as a possibility in fntguide.

In theory, once @u-fischer's changes get into a release, this makes sense. But I'm not sure about doing that here? I doubt the .fd files should load a package ....