| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
When adapting to the new loader we repeated the mistake of classifying
“bold” faces by too broad criteria, thereby sabotaging the recognition
of large families from Adobe. Restore the old behavior by only treating
those faces as bold fallback that advertise and exact weight of 700.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fix #342
Due to the reassigned fontname fields, certain values designating styles
ended up being interpreted wrongly and members of the font families
ended up in the wrong table.
Thanks to @dohyunkim for spotting the issue.
|
|
|
|
|
|
|
| |
Fix #337
This amends the apparent failure of luaotfload-tool as reported by @eg9
and others.
|
|
|
|
|
|
|
|
|
|
| |
The current PFB loader, although it is indeed completely independent of
the FF libraries, is not yet feature complete. Only the loading of
vectors is supported which suffices for font rendering given the AFM
information.
According to Hans, we have decent chance of it growing into a
full-fledged reader for 1.0.
|
|
|
|
|
|
|
|
| |
This reverts commit c4c250414a83cc8c4ae99d286ed69a3763510609.
Partially, anyways: All mentions of the PFA format were stripped.
Since the new loader adds back in support for PFB-flavored PS fonts
without AFM we should support it from Luaotfload as well.
|
|
|
|
|
|
|
| |
Thanks to @dohyunkim for reminding me to be thorough!
At least in our own files. A patch has been sent upstream to apply the
same change to the generic loader.
|
|
|
|
|
| |
The “AFM” code stays since PFB accompanied by an AFM file is still
supported by the fontloader.
|
|
|
|
|
|
| |
This one hasn’t been touched for ages. The will be no compatibility
loader this year. For testing, creating a loader on the fly from the Git
repos is sufficient.
|
|
|
|
|
|
| |
TTC subfonts must be considered if there is at least one subfont.
Discovered and fixed by @dohyunkim; the fix for ``font-otr.lua`` goes
upstream.
|
|
|
|
|
|
|
| |
No such warnings with the new loader. Instead we need to test for the
``fontname`` / ``fullname`` fields.
Thanks to @dohyunkim for reporting.
|
|
|
|
| |
D’oh! Too much debugging =)
|
|
|
|
|
|
|
| |
… or perhaps more accurately, “megafamily”. For the time being we prefer
the “windows” versions of the fonts due to the higher quality of the
“typographic family” and “subfamily” fields. Another advantage of the
new loader over FF is that we’re even given that choice.
|
|
|
|
|
|
| |
This facility was added by Hans to accomodate our peculiar requirements:
There should be no fallback from prefmodifiers to familyname since that
removes valuable information about larger font sets like the Adobe ones.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The penalty for having font object closed automatically is huge: It
takes around nine seconds more to rebuild the font database: 58 s with
__gc, 49 s by closing manually. Even if it’s not the default, we
reintroduce the code for closing fonts manually to avoid that situation.
|
|
|
|
|
|
| |
There are some non-negligible differences in the reader output,
especially concerning font names. Until this is sorted out we need a
fast way to switch back to the old code for reference.
|
|
|
|
|
|
|
|
| |
This has been coming for some time: Upstream now provides full Opentype
reader capabilities. This allows Luatex to drop those horrible fontforge
libraries. Since the API is pretty similar, for Luaotfload it means
little change and a decent speed gain. Though we still need to
investigate whether the result is equivalent or at least acceptable.
|
|
|
|
|
| |
We again depend on the full Lualibs set for some time so our wrappers
are irrelevant as we can just use the similar once from there.
|
| |
|
|
|
|
|
|
|
|
| |
This introduces a forced lookup type “evl” that bypasses the other
methods. The specification is extended with the correct values including
a more meaningful hash string. As a result, the loader no longer
attempts to interpret the specification as a “file:” request but the
backend can still resolve the necessary files.
|
|
|
|
|
| |
We still had some 2014 values lingering around dark corners. In theory
this is all meaningless wrt. the Git repo.
|
|
|
|
|
| |
These were rendered unusable due to the suspended initialization.
Creating the directives mapping on the fly is just as good.
|
|
|
|
|
|
|
|
|
|
| |
This seems to help with the examples from #165 that rely on setting
``$OPENTYPEFONTS`` via the environment.
Referencing a non-existing value caused a branch to always pick Unix
path separators. The affair was pretty insidious since the paths we
received from kpse were sane so the behavior was only triggered with
manual overrides.
|
| |
|
| |
|
| |
|
|
|
|
| |
This makes the ``--find`` option to luaotfload-too work again.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Also clean up the local name of the logger for consistency with the rest
of the code base.
|
|
|
|
|
|
|
| |
Addresses issue #278: https://github.com/lualatex/luaotfload/issues/278
ATM only files whose full path is stored in the db are considered. Needs
checking whether this works for TEXMF fonts too.
|
| |
|
|
|
|
|
|
| |
Reported by /u/ThomasFehige on Github:
https://github.com/lualatex/luaotfload/issues/275#issuecomment-113515484
|
|
|
|
|
| |
The ``db.update-live`` option caused all db updates, even forced ones to
fail due to a missing check for the kind of run.
|
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/lualatex/luaotfload/issues/233
On non-POSIX systems, the Lua interpeter is compiled with a reduced set
of options accepted by ``os.date()`` [0].
[0] http://www.lua.org/source/5.2/loslib.c.html#LUA_STRFTIMEOPTIONS
|
|
|
|
|
| |
Also document the file lookup somewhat and rename it to
``font_file_lookup()``.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Good riddance. We’re now fully migrated to the new, dynamic
configuration subsystem with respect to cache paths.
|
| |
|
| |
|
| |
|