-
Notifications
You must be signed in to change notification settings - Fork 8
Wrong font picked up for optical size font #363
Comments
Hi, thanks for the report. ···<date: 2016-06-12, Sunday>···<from: Yan Zhou>···
Please wait for the next bugfix release; a number of issues
If this doesn’t vanish with the upcoming release, it’d be helpful
Names table, as usual. Almost all fonts are broken in this
Names even vary over different versions of the same font and are One way to address the issue would be to extend font selection
Nah, just use filenames directly, maybe in conjunction with a
That’s the most adequate means of setting up fonts for Latex that Best, |
Just to add, I tested my examples with Github master version before submitting the issue. I will try to find a free font example later Another way I can think of, and perhaps less complicated as allowing patching the table (which will be quite painful considering the index values are hashing values, they can change between updating even without change anything on the system) is to allow a configure file similar to the blacklist file
The first explicitly says Kepler regular belongs to table "r", the second exclude the corresponding font from any four of them. That third explicitly says it belongs to table "bi" and thus preventing it being included in "b". The last says we want to include it in both r and it tables. |
The new release is out, please check whether this improves your issue. |
Thanks for the update. I haven't got time to do more extensive testing. But the issue described still persists. And in some cases it is worse. For example, at the end of this comment is the contents of Kepler is a particularly difficult case, there are 4 widths, 5 weights, 4 sizes, 2 styles, in total 169 fonts in the family. My current workaround is to manual edit \setmainfont{Kepler Std} works smoothly. And if I need a specific style, say extended bold italics, I use I can't find a free font that has such a broad range of styles to "stress test" the package. I still think it is best if things are kept simple, work for most simple cases. And with an easy interface for dealing with these edges, such as the configuration file I proposed earlier. The Manually editing the database is certainly tedious. I wrote a script to automate the process, which is used everytime I run If you think the idea of a configuration file, which will be read in and put the fonts in it in the appropriate tables before automatically selected ones, I will see if I can create a patch and send a pull request. But before that, I need to get myself familiar with the source first and can't promise anything in the near future. In any case, -- Naming convensions: <Weight><Width><Shape><Size>
-- Weight
-- (Normal)
-- Light
-- Medium
-- Bold
-- Black
-- Width
-- (Regular)
-- Cn: Condensed
-- Scn: Semicondensed
-- Ext: Extended
-- Shape
-- (Upright)
-- It: Italic
-- Size
-- (Text)
-- Capt: Caption
-- Subh: Subhead
-- Disp: Display
["keplerstd"]={
["b"]={
{ 8, 8.9, 6, 2465 }, -- BoldExtItCapt
{ 8, 8.9, 6, 2474 }, -- BoldScnCapt
{ 8, 8.9, 6, 2477 }, -- BoldScnItCapt
{ 8, 8.9, 6, 2462 }, -- BoldExtCapt
{ 8, 8.9, 6, 2455 }, -- * BoldCapt
{ 11, 13.9, 8.9, 2464 }, -- BoldExtIt
{ 11, 13.9, 8.9, 2473 }, -- BoldScn
{ 11, 13.9, 8.9, 2476 }, -- BoldScnIt
{ 11, 13.9, 8.9, 2454 }, -- * Bold
{ 11, 13.9, 8.9, 2461 }, -- BoldExt
{ 18, 23, 13.9, 2459 }, -- BoldCnSubh
{ 18, 23, 13.9, 2481 }, -- * BoldSubh
{ 18, 23, 13.9, 2479 }, -- BoldScnItSubh
{ 18, 23, 13.9, 2468 }, -- BoldExtSubh
{ 18, 23, 13.9, 2458 }, -- BoldCnItSubh
{ 18, 23, 13.9, 2467 }, -- BoldExtItSubh
{ 18, 23, 13.9, 2480 }, -- BoldScnSubh
{ 72, 72, 23, 2478 }, -- BoldScnItDisp
{ 72, 72, 23, 2460 }, -- * BoldDisp
{ 72, 72, 23, 2466 }, -- BoldExtItDisp
{ 72, 72, 23, 2456 }, -- BoldCnDisp
{ 72, 72, 23, 2475 }, -- BoldScnDisp
{ 72, 72, 23, 2457 }, -- BoldCnItDisp
{ 72, 72, 23, 2463 }, -- BoldExtDisp
},
["bi"]={
{ 8, 8.9, 6, 2470 }, -- * BoldItCapt
{ 11, 13.9, 8.9, 2469 }, -- * BoldIt
{ 18, 23, 13.9, 2472 }, -- * BoldItSubh
{ 72, 72, 23, 2471 }, -- * BoldItDisp
},
["i"]={
{ 8, 8.9, 6, 2497 }, -- * ItCapt
{ 11, 13.9, 8.9, 2496 }, -- * Italic
{ 18, 23, 13.9, 2499 }, -- * ItSubh
{ 72, 72, 23, 2498 }, -- * ItDisp
},
["r"]={
{ 8, 8.9, 6, 2482 }, -- * Capt
{ 8, 8.9, 6, 2548 }, -- MediumScnCapt
{ 8, 8.9, 6, 2520 }, -- LightScnCapt
{ 11, 13.9, 8.9, 2556 }, -- * Regular
{ 11, 13.9, 8.9, 2519 }, -- LightScn
{ 11, 13.9, 8.9, 2547 }, -- MediumScn
{ 18, 23, 13.9, 2554 }, -- MediumScnSubh
{ 18, 23, 13.9, 2526 }, -- LightScnSubh
{ 18, 23, 13.9, 2593 }, -- * Subh
{ 72, 72, 23, 2521 }, -- LightScnDisp
{ 72, 72, 23, 2487 }, -- * Disp
{ 72, 72, 23, 2549 }, -- MediumScnDisp
},
}, |
Another reason for allowing easier patching of the families table is that, many fonts come with an extensive range of width and weights, which are meant to be used at different optical sizes. It is impossible for ["myriadpro"]={
["b"]={
{ 11, 0, 0, 2159 }, -- Bold
-- a few other entries
},
["bi"]={
{ 11, 0, 0, 2162 }, -- BoldIt
},
["i"]={
{ 11, 0, 0, 2169 }, -- It
},
["r"]={
{ 11, 0, 0, 2178 }, -- Condensed
-- some other entries
},
}, This particular example is produced on CentOS, while Mac OS X, with the same font collection, the choice was |
There is actually one free fonts with extensive optical ranges, the Computer/Latin Modern fonts. I rarely use it nowadays and overlooked it. After updating to the most recent release of ["latinmodernmono"]={
-- Missing italic table, lmmono10-italic
["r"]={
{ 8, 8.5, 4, 812 },
{ 9, 9.5, 8.5, 813 },
{ 10, 11, 9.5, 810 },
{ 12, 24, 11, 811 },
},
},
["latinmodernroman"]={
["b"]={
{ 5, 5.5, 3, 837 },
{ 6, 6.5, 5.5, 839 },
{ 7, 7.5, 6.5, 841 },
{ 8, 8.5, 7.5, 844 },
{ 9, 9.5, 8.5, 847 },
{ 10, 11, 9.5, 829 },
{ 12, 24, 11, 833 },
},
["bi"]={
{ 10, 20, 5, 830 },
},
-- Missing italic table, lmroman{7,8,9,10,12}-italic
-- Only lmroman10-italic will be used in documents
["r"]={
{ 5, 5.5, 3, 838 },
{ 6, 6.5, 5.5, 840 },
{ 7, 7.5, 6.5, 843 },
{ 8, 8.5, 7.5, 846 },
{ 9, 9.5, 8.5, 849 },
{ 10, 11, 9.5, 832 },
{ 12, 14, 11, 835 },
{ 17.2, 24, 14, 836 },
},
},
["latinmodernsans"]={
["b"]={
{ 10, 20, 5, 863 },
},
["bi"]={
{ 10, 20, 5, 864 },
},
-- Missing italic table, lmsans{8,9,10,12,17}-oblique
-- Only lmsans10-oblique will be used in documents
["r"]={
{ 8, 8.5, 4, 872 },
{ 9, 9.5, 8.5, 874 },
{ 10, 11, 9.5, 866 },
{ 12, 14, 11, 868 },
{ 17.2, 24, 14, 870 },
},
}, |
I checked in a current luaotfload the |
I just noticed that this is a duplicate with #356 . However I hope the details below are useful
I noticed that fontspec is picking up wrong fonts in some situations, when there are multiple optical sized fonts. I traced down the issues to
luaotfload
. And created the following minimal plain tex example,In the output, two out of the last three fonts was wrong. They should be CronosPro-BoldCaptIt, CronosPro-BoldIt, and CronosPro-BoldSubhIt
I included the selection for Arno Pro and up shape of Cronos Pro for comparision. It appears that,
luaotfload
is able to choose Arno Pro correclty, for both up shape, and bold italics. (italics, and bold also works fine)So I looked up the
luaotfload-names.lua.gz
file and here is a few thing I noticed that are different when it is choosing the right font and wrong ones (I also did some more expensive experiments with all Adobe optical fonts).BoldIt
, orBoldItalics
, orBoldItSubh
etc.BoldSubhIt
, instead ofBoldItSubh
.Further, it seems the problem is not with the the main package, instead of it is with
luaotfload-tool
Below is the entry for
cronospro
generated byluaotfload-tool
Some entries that should belong to the table "bi" is in "b" instead. Similary for the italic group. After manually fix this table to the following,
The test file at the beginning of this issue is working correctly.
I am not able to determine the where exactly did
luaotfload-tool
get it wrong. There are other related issues, such as seemly randomly chosenLight
orMedium
weights for Kepler Std, etc. I think even if we do find a fix for these issues, it is not future proof. The naming of fonts are just so inconsistent. Even within Adobe fonts, as we see in this issue, there are different conventions. In summary, I don't think this is an issue that worth the effort to fix.Instead I suggest a public interface for users to deal with these edge cases directly. For example, in
luaotfload-tool
, after generating the table, but before write it to the file, it will read a user supplied lua script if it exists, call a function, saypatch_name_table
within it if it exist, and pass the table to it. The user definedpatch_name_table
will allow the user to do whatever final touch they want.The text was updated successfully, but these errors were encountered: