| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
| |
Fix #338
Due to the new loader, certain tables were relocated inside the fontdata
structure. This would cause a crash with certain kinds of fonts, most
notably those for which TeX metrics exist.
Many thanks to @aminophen and @u-fischer for their help in tracking this
down.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Hans fixed a couple issues due to our reports. Also, brand new Lua based
PFB loader.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
The Lua fontloader doesn’t support these formats and they’re very low
priority. There is no “shortcut” like with the FF loader anymore which
would parse such files into the same data structures as {O,T}TF. Support
for postscript formats may come back at some point in the future if
there is demand.
|
| |
|
|
|
|
|
|
|
| |
Another take on https://github.com/lualatex/luaotfload/issues/334
The parsing issues we aim to prevent occur with spaces because Luatex
treats them as argument separators. Hence apply quoting only if
necessary. Also use the appropriate format string as a defense against
garbage inputs.
|
| | |
|
| |
|
|
|
|
|
| |
Fixes https://github.com/lualatex/luaotfload/issues/334
Old-style font definitions only need a font name, so the extra quotes
aren’t necessary to feed the \fontname string back into \font.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
The option has become redundant with the new loader so we might as well
get rid of it.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
No such warnings with the new loader. Instead we need to test for the
``fontname`` / ``fullname`` fields.
Thanks to @dohyunkim for reporting.
|
| |
|
|
|
| |
Only font indexing is affected by “use-fontforge”. The fontloader itself
will always use the new code.
|
| |
|
|
|
|
| |
The new Lua based loader consistently numbers subfonts from one, not
zero like the Fontforge one. We correct the value immediately before
passing a handled font request on to the loader.
|
| | |
|
| |
|
|
| |
D’oh! Too much debugging =)
|
| |
|
|
|
|
|
| |
Addresses #326
This is a hot-fix with non-official code. The actual fix will come
downstream later from Context as usual.
|
| | |
|
| | |
|
| |
|
|
|
| |
Note that this will explode on the current loader code due to a typo in
font-otr.lua. Patch submitted upstream, please be patient.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The tables emitted by the new font reader functions do not correspond to
their Fontforge counterparts. Thus, some of the display routines had to
be rewritten, in some cases like the names table this resulted in the
removal of a good deal of obsolete code.
|
| | |
|
| |
|
|
|
|
|
| |
… 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.
|
| |
|
|
| |
Fallout of the new character table loading routine.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After some discussion, Hans came up with these extensions to the new
reader. We get access to more items from the hideous “name” table. On
the one hand, this means more brokenness to endure and a less sane
matter to work with. But since our tracker was devoid of font-matching
related bug reports for some time, it’s the right move nonetheless.
In addition to the name table junk, the font loader now also includes
the “version” field in the output of “getinfo()”. It’s meaningless per
se, but it sure helps to distinguish historical bugs from the ones that
matter.
**UNTESTED**
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
Obviously, since Fontforge has been ditched, we need to adapt to the
slightly different data structures created by the Lua reader. For the
time being, we revise the code so it will not crash instantly due to the
lack of a missing ``pfminfo`` table.
Hans has been notified of our use of the ``capheight`` data and may
add that value grudgingly again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fontloader requires parts of the ``characters`` table to be present
at load time. This turns out to interfere with our custom of installing
the lazy loader for the table components only after the fontloader has
been injected. Since inserting the code at the appropriate place in the
loading chain would be tedious and unmaintainable due to the various
load options, we just preinstall the metatable onto an empty table prior
to loading the loader.
Some precautions had to be taken regarding the ``classifiers`` subhash
of the table that needs to be relocated from the data we received via
mkcharacters.
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
