| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| | |
… 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.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Two not quite unrelated changes have to be accounted for:
* Finally, the source for Context MkII and MkIV are being kept in
separate trees, at least as far as the format is concerned. All
out scripts that pull code from upstream had to be adapted.
* New fontloader. This has been cooking for half a year maybe: Some
of our troubles with 2.6 were caused by separating out the revised
but highly experimental code from the self-contained fontloader,
despite Hans’ great efforts to make it seamless. Now that the new
fontloader is deemed mature enough, we have to accomodate the
switchover.
The fallout exceeds the bounds of Luaotfload proper: The Lualibs package
had to be extended as well, adding a rather tiny library from the
``util-*`` namespace. With the latest setup, a fontloader can indeed be
assembled automatically again. No testing has taken place yet, so it
might not even run.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The extraction code itself was taken from luatex-basics-prepare.tex. In
Context, this file generates “luatex-basics-chr.lua” a stripped down
version of char-def.lua. Just as our exisiting mkcharacters script.
Interesting that Hans chose a similar path to what we do ;) The code,
which requires some functionality from char-ini.lua, has thus been added
as a function to the script.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Larger changes by upstream are easier to comprehend if errors during
import are counted instead. The script will exit non-zero regardless if
such an error occurred, but otherwise attempt to import all the files.
|
| | |
| |
| |
| |
| | |
With revision 5624, the status library was overhauled. Among others we
lose the ``luatex_svn`` field which was rather useful for debugging :/
|
| | |
| |
| |
| | |
Now that we’re heading towards TL 2016, this seems necessary.
|
| |\|
| |
| | |
lookups, combos, fallbacks
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Building on the combination mechanism, this allows defining fallback
fonts of which all glyphs are pulled that aren’t currently part of the
base font. Example:
\input luaotfload.sty
\font \lm = file:lmroman10-regular.otf:mode=base
\font \cmu = file:cmunrm.otf:mode=base
\font \lmu = "combo: 1->\fontid\lm; 2->\fontid\cmu,fallback"
\lmu Eh bien, mon prince. Gênes et Lueques ne sont plus que des
apanages, des поместья, de la famille Buonaparte.
\bye
This allows setting Latin Modern text that contains Cyrillic letters.
Note that -- as with the other combinations -- only glyphs are
considered, no other properties of the fallback font. So besides the
occasional letter in a different script this functionality is probably
useless.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use arrows to emphasise what’s mapped. Allow whitespace to visually
separate items. Also allow optional grouping with parentheses.
Now it’s possible to define a combination as follows:
\font \f = "combo: 1 -> 42;
2 -> 1337, U+0042-U+0084;
3 -> (55, 0x54 * 0x45 * 0x58)"
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This gives more leeway to the notation, allowing font definitions to
become more readable:
\font \f = "combo: 1 / \fontid\one,
2 / \fontid\two / 0x41-0x5a,
3 / \fontid\three / 0x42,
4 / \fontid\three / 0x54 * 69 * U+58"
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Highly experimental at this point. The font request parser has been
extended to handle combinations of already defined fonts. Nothing else
has been implemented yet, so the request handler will simply error out
with a message.
|
| | |
| |
| |
| |
| |
| |
| | |
Address issue #322
The annotation says it all; reportedly this is fine with TL 2016,
though.
|
| | |
| |
| |
| | |
Spacing is off in the ``.5``, we didn’t account for markup.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This primarily affects the “anon” lookup. However, since we cannot any
longer determine the lookup success by crude means, the resolver
signature had to be modified to indicate success or failure via the
return value. This does no longer match the resolver implementation of
Context but the interface has become much cleaner.
|
| |\|
| |
| | |
fixes
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Address issue #318
This reverts the changes made to font-otn.lua with commit adc43c3c24..
Certain features related to directionality are not handled correctly
with the most recent fontloader. As a temporary measure, revert the
handling code in font-otn.lua and restore the values it references.
While this appears to suppress the issue, we’ll switch back to the
upstream code once we have an actual solution.
|
| | | |
|
| | |
| |
| |
| | |
See issue https://github.com/lualatex/luaotfload/issues/303
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\|
| |
| | |
fix tex ligatures
|
| | |
| |
| |
| |
| |
| | |
Closing #309
Many thanks for @simifilm for the report!
|
