| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | | |
|
| |\ \ |
|
| | |/ |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed in issue #398.
Ad futuram rei memoriam the gist of it:
- For the index, all values are scaled (decipoints * sp) / 10 *
(7227 / 7200).
- The ``bp`` case (the default, OT-standard), needs no conversion
because it matches how values are stored in the index.
- The ``pt`` case essentially reverts the bp→pt part of scaling
done for the database by scaling the asked size by the same
factor, i. e. by 7227 / 7200.
- The ``dd`` needs an extra 1238 / 1157.
Requesting a font at 10pt will then:
- ask for a size of 655360 for ``bp`` / default;
- ask for 657817 for ``pt``;
- ask for 703870 for ``dd``.
|
| |
|
| |
The conversion from reported design size etc., to "true `sp` value" is actually converting from `bp` to `pt`.
|
| |
|
|
|
|
| |
Fix #394
Due to an oversight, all files except AFM got scanned twice.
|
| | |
|
| |
|
|
|
| |
Store design sizes in sp in index. Lookups are performed using sp
so the design size factor can be applied at runtime.
|
| | |
|
| | |
|
| |
|
|
| |
Fix #389
|
| |
|
|
|
|
|
|
|
|
| |
Fix assignment of LM series fonts. Currently these are broken because of
borked typosub identifiers like “8oblique” that prevent exact name
matching and at the same time exclude matching the (usable) subfamily.
Introduce a heuristic based on the italic angle value that assigns
italic as a fallback in these cases.
Test: https://bitbucket.org/phg/lua-la-tex-tests/src/857c83ca98cb35153979a0613d3a742bfd93f834/lua/tla-names-3-lm.lua
|
| |
|
|
|
| |
The config option must go since the FF based code was removed already
some time ago.
|
| |
|
|
|
|
| |
The loader makes some assumptions about available lookup functions early
on. Since fonts-syn.lua only installed dummies for most of these, we
might as well do that too.
|
| |
|
|
|
|
|
|
|
|
|
| |
Reported by @dohyunkim: https://github.com/lualatex/luaotfload/pull/364#issuecomment-226059150
Under certain circumstances, update_names() was invoked with an empty
table instead of a correctly initialized one, breaking the assumptions
of the db populating code.
This commit also guards more strongly against this kind of oversight and
tidies up the db constructor.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Addresses #359 and #325
To avoid duplicate entries, paths have to be resolved before collecting
them. This necessitates loop detection of some sort, currently
implemented naively as a flat table containing the directories already
traversed.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Address issue #356
The DejaVu Family needs stricter handling of fallback choices so we take
the font’s avertised width into consideration. This used to be easier
with the old loader since it had some decent heuristics in place for the
more or less reliable “fontstyle_name”.
|
| |
|
|
|
|
|
|
| |
Remove all the FF stuff and the config option. The transition is
complete, no need to keep these things around any longer.
Since we won’t be going back to the FF loader we might as well dispose
of the junk identifiers and the translation layer as well.
|
| |
|
|
|
| |
The assumption that the AFM/PFB pair will reside in the same directory
together is wrong for TeX Live. Hence the new lookup against kpse.
|
| |
|
|
|
|
| |
@dohyunkim pointed out that due to the too broad criteria, secondary
style variants like “heavy”, “black” ended up getting picked over the
actual “bold”.
|
| |
|
|
|
|
|
| |
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.
|
